diff --git a/.github/workflows/quick_build.yml b/.github/workflows/quick_build.yml new file mode 100644 index 0000000..7d51bfe --- /dev/null +++ b/.github/workflows/quick_build.yml @@ -0,0 +1,301 @@ +name: QuickBuild v4.6 20251010 + +on: + push: + branches: + - '*' + - '!gh-pages' + workflow_dispatch: + inputs: + environment: + type: string + default: DEV + required: true + +jobs: + test: + runs-on: ubuntu-latest + name: Quick Build + steps: + - name: Checkout project and transforms + uses: actions/checkout@v3 + with: + submodules: true + + - name: Install Build Packages +# run: "sudo apt-get update && sudo apt-get install -y xsltproc hunspell pandoc" + run: "sudo apt-get update && sudo apt-get install -y hunspell python3-lxml xsltproc" + + - name: Install Jing + run: wget -O - https://github.com/relaxng/jing-trang/releases/download/V20181222/jing-20181222.zip | jar -x + + - name: Set branch name + run: echo "action_branch=$(echo ${GITHUB_REF#refs/heads/})" >> $GITHUB_ENV + + - name: Set base URL + run: echo "action_projname=${PWD##*/}" >> $GITHUB_ENV + + - name: Quick Build + run: WARN_PATH="output/SanityChecksOutput.md" make + + - name: Build PP-Modules + run: | + for moddir in Modules/*/; do + if ls ${moddir}input/*.xml 1>/dev/null 2>&1; then + echo "Building module in ${moddir}..." + cd ${moddir} + WARN_PATH="output/SanityChecksOutput.md" make || true + cd $GITHUB_WORKSPACE + else + echo "No XML input in ${moddir}, skipping." + fi + done + + + - name: Branch Test + run: | + branchname=$(echo ${GITHUB_REF#refs/heads/}) + if [[ $branchname =~ [0-9] ]]; then + echo "action_is_release=YES" >> $GITHUB_ENV + else + echo "action_is_release=NO" >> $GITHUB_ENV + fi + + # PDFify + - name: PDFify + if: ${{ env.action_is_release == 'YES' }} + run: | + sudo apt install -y chromium + cd output + for aa in *.html; do + chromium --no-sandbox --headless --disable-gpu --no-pdf-header-footer --timeout=10000 \ + --print-to-pdf=${aa}.pdf \ + file://${PWD}/${aa} + done + + - id: validate + run: | + RNG_OUT="output/ValidationReport.txt" make validate || true + + - name: Set valerrors + run: echo "action_valerrors=$(wc -l output/ValidationReport.txt | { read first rest ; echo $first ; } )" >> $GITHUB_ENV + + - id: spellcheck + run: | + SPELL_OUT="output/SpellCheckReport.txt" make spellcheck + + - name: Set spellerrors + run: echo "action_spellerrors=$(wc -l output/SpellCheckReport.txt | { read first rest ; echo $first ; } )" >> $GITHUB_ENV + + - name: Get Transforms Date +# run: echo "action_tdate=2002222" >> $GITHUB_ENV + run: echo "action_tdate=$(cd transforms && git log -1 --format=%cs; cd ->/dev/null)" >> $GITHUB_ENV + + - name: Get DaisyDiff + run: | + wget -O- https://github.com/AndroidKitKat/ExecuteDaisy/archive/master.zip | jar -x + [ -d "output/images" ] || mkdir "output/images"; + cp -u -r ExecuteDaisy-master/js ExecuteDaisy-master/css output; + cp -u ExecuteDaisy-master/images/* output/images; + + + - name: Make tmp dir + run: mkdir tmp + + - name: diff + run: TMP=tmp make diff || true; + # Little diff depends on having a git history. + # The current checkout has depth=1 and has no history + #- name: little diff + # run: make little-diff || true + + - name: Outstanding TDs + id: tds + run: | + if [ "${{steps.extract_branch.outputs.branch}}" == "master" ] && + ls input/tds/*.xml ; then + echo "Master branch should not have TDs" >> output/TDValidationReport.txt + fi + # make effective + # PP_XML=output/effective.xml RNG_OUT=output/TDValidationReport.txt make validate || true + # IF STATEMENT HERE + # PP_XML=output/effective.xml PP_RELEASE_HTML=output/AppliedTDs.html make release + # java -jar ExecuteDaisy-master/*.jar output/*-release.html output/AppliedTDs.html --file=output/AppliedTDs-Diff.html + + - name: Set TD badge attributes + run: | + NUM=$(ls input/tds/*.xml | wc -l) + if [ $NUM == 0 ]; then + echo "action_tdcolor=gray" >> $GITHUB_ENV + echo "action_tdwarns=N/A" >> $GITHUB_ENV + echo "GOING THROUGH HERE $NUM" + else + echo "action_tdcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV + echo "action_tdwarns=$NUM:$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;})" >> $GITHUB_ENV + echo "THERE ARE TDs $NUM" + + fi + # Not sure what the point of this is + - name: Validate Effective + run: | + echo "action_effvalcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV + echo "action_effvalwarns=$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;} )" >> $GITHUB_ENV + + + - name: Prepare environment + run: | + # Generates a GitHub Workflow output named `lines` with a coverage value + echo "action_spellcolor=$(if [ 0 = ${{ env.action_spellerrors }} ]; then echo green; else echo red; fi)" >> $GITHUB_ENV + echo "action_valcolor=$(if [ 0 = ${{ env.action_valerrors }} ]; then echo green; else echo red; fi)" >> $GITHUB_ENV + echo "action_sanitystatus=$(if [ -s output/SanityChecksOutput.md ]; then echo some; else echo none; fi)" >> $GITHUB_ENV + echo "action_sanitycolor=$(if [ -s output/SanityChecksOutput.md ]; then echo red; else echo green; fi )" >> $GITHUB_ENV + + + + - name: Generate the spelling badge SVG image + uses: emibcn/badge-action@v2.0.2 + with: + label: 'Misspellings' + status: ${{ env.action_spellerrors }} + color: ${{ env.action_spellcolor }} + path: output/spell-badge.svg + + + + - name: Generate the validation badge SVG image + uses: emibcn/badge-action@v2.0.2 + with: + label: 'Validation' + status: ${{ env.action_valerrors }} + color: ${{ env.action_valcolor }} + path: output/validation.svg + + + - name: Generate the warnings badge + uses: emibcn/badge-action@v2.0.2 + with: + label: 'Warnings' + status: ${{ env.action_sanitystatus }} + color: ${{ env.action_sanitycolor }} + path: output/warnings.svg + + + - name: Generate the transforms badge + uses: emibcn/badge-action@v2.0.2 + with: + label: 'Transforms' + status: ${{ env.action_tdate }} + color: gray + path: output/transforms.svg + + - name: TD Badge + uses: emibcn/badge-action@v2.0.2 + with: + label: 'TDs' + status: ${{ env.action_tdwarns }} + color: ${{ env.action_tdcolor }} + path: output/tds.svg + + - name: Make Dashboard Snippet + run: | + rurl="https://raw.githubusercontent.com/appswcpp/${{env.action_projname}}/gh-pages/${{env.action_branch}}" + surl="https://appswcpp.github.io/${{env.action_projname}}/${{env.action_branch}}" + gurl="https://github.com/appswcpp/${{env.action_projname}}/blob/gh-pages/${{env.action_branch}}" + ( + echo '[cols="1,1,1,1,1,1,1,1"]' + echo '|===' + echo "8+|${{ env.action_projname }} " + echo "| https://github.com/appswcpp/${{env.action_projname}}/tree/${{env.action_branch}}[${{ env.action_branch }}] " + echo "a| $surl/${{env.action_projname}}-release.html[๐Ÿ“„]" + echo "a|[link=$gurl/ValidationReport.txt]" + echo "image::$rurl/validation.svg[Validation]" + echo "a|[link=$gurl/SanityChecksOutput.md]" + echo "image::$rurl/warnings.svg[SanityChecks]" + echo "a|[link=$gurl/SpellCheckReport.txt]" + echo "image::$rurl/spell-badge.svg[SpellCheck]" + echo "a|[link=$gurl/TDValidationReport.txt]" + echo "image::$rurl/tds.svg[TDs]" + echo "a|image::$rurl/transforms.svg[transforms,150]" + echo "a| [link=$gurl/HTMLs.adoc]" + echo "image::$rurl/html_count.svg[HTML Count]" + echo "[link=$gurl/PDFs.adoc]" + echo "image::$rurl/pdf_count.svg[PDF Count]" + echo '|===' + ) > output/Minidash.adoc + + + - name: HTML List + run: | + surl="https://appswcpp.github.io/${{env.action_projname}}/${{env.action_branch}}" + ( for aa in output/*.html ; do + echo "* $surl/${aa#*/}[${aa#*/}]" + done ) > output/HTMLs.adoc + HTML_COUNT=$(wc -l < output/HTMLs.adoc) + echo "action_html_count=$HTML_COUNT" >> $GITHUB_ENV + + - name: PDF List + run: | + surl="https://appswcpp.github.io/${{env.action_projname}}/${{env.action_branch}}" + cd output + (for aa in $(find . -name '*.pdf') ; do + echo "* $surl/${aa#*/}[${aa#*/}]" + done ) > PDFs.adoc + PDF_COUNT=$(wc -l < PDFs.adoc) + echo "action_pdf_count=$PDF_COUNT" >> $GITHUB_ENV + + + - name: HTML Badge + uses: emibcn/badge-action@v2.0.2 + with: + label: 'HTMLs' + status: ${{ env.action_html_count }} + color: gray + path: output/html_count.svg + + - name: PDF Badge + uses: emibcn/badge-action@v2.0.2 + with: + label: 'PDFs' + status: ${{ env.action_pdf_count }} + color: gray + path: output/pdf_count.svg + + + - name: Prepare checkout + run: | + mkdir gh-pages + + - uses: actions/checkout@v3 + with: + ref: gh-pages + path: gh-pages + + + - name: Move output to branch + run: | + rm -rf gh-pages/${{ env.action_branch }} + mv output gh-pages/${{ env.action_branch }} + for moddir in Modules/*/; do + modname=$(basename ${moddir}) + if [ -d "${moddir}output" ]; then + mkdir -p gh-pages/${{ env.action_branch }}/Modules/${modname} + cp -r ${moddir}output/* gh-pages/${{ env.action_branch }}/Modules/${modname}/ 2>/dev/null || true + fi + done + + - name: Make listing + run: | + cd gh-pages + (echo "Listing"; + date; + echo "
    "; + for aa in $(find . -name '*.*'); do + echo "
  1. $aa
    2. "; + done; + echo "
") > index.html + + - name: Deploy ๐Ÿš€ + uses: JamesIves/github-pages-deploy-action@v4 + with: + branch: gh-pages # The branch the action should deploy to. + folder: gh-pages # The folder the action should deploy. diff --git a/.github/workflows/quick_build_pdf.yml b/.github/workflows/quick_build_pdf.yml new file mode 100644 index 0000000..0d3b76c --- /dev/null +++ b/.github/workflows/quick_build_pdf.yml @@ -0,0 +1,277 @@ +name: QuickBuild v4.6pdf 20251010 +# Run only on demand to do quick build with both pdf and html output + +on: + workflow_dispatch: + inputs: + environment: + type: string + default: DEV + required: true + +jobs: + test: + runs-on: ubuntu-latest + name: Quick Build + steps: + - name: Checkout project and transforms + uses: actions/checkout@v3 + with: + submodules: true + + - name: Install Build Packages +# run: "sudo apt-get update && sudo apt-get install -y xsltproc hunspell pandoc" + run: "sudo apt-get update && sudo apt-get install -y hunspell python3-lxml xsltproc" + + - name: Install Jing + run: wget -O - https://github.com/relaxng/jing-trang/releases/download/V20181222/jing-20181222.zip | jar -x + + - name: Set branch name + run: echo "action_branch=$(echo ${GITHUB_REF#refs/heads/})" >> $GITHUB_ENV + + - name: Set base URL + run: echo "action_projname=${PWD##*/}" >> $GITHUB_ENV + + - name: Quick Build + run: WARN_PATH="output/SanityChecksOutput.md" make + + + - name: Branch Test + run: | + branchname=$(echo ${GITHUB_REF#refs/heads/}) + if [[ $branchname =~ [0-9] ]]; then + echo "action_is_release=YES" >> $GITHUB_ENV + else + echo "action_is_release=NO" >> $GITHUB_ENV + fi + + # PDFify + - name: PDFify + run: | + sudo apt install -y chromium + cd output + for aa in *.html; do + chromium --no-sandbox --headless --disable-gpu --no-pdf-header-footer --timeout=10000 \ + --print-to-pdf=${aa}.pdf \ + file://${PWD}/${aa} + done + + - id: validate + run: | + RNG_OUT="output/ValidationReport.txt" make validate || true + + - name: Set valerrors + run: echo "action_valerrors=$(wc -l output/ValidationReport.txt | { read first rest ; echo $first ; } )" >> $GITHUB_ENV + + - id: spellcheck + run: | + SPELL_OUT="output/SpellCheckReport.txt" make spellcheck + + - name: Set spellerrors + run: echo "action_spellerrors=$(wc -l output/SpellCheckReport.txt | { read first rest ; echo $first ; } )" >> $GITHUB_ENV + + - name: Get Transforms Date +# run: echo "action_tdate=2002222" >> $GITHUB_ENV + run: echo "action_tdate=$(cd transforms && git log -1 --format=%cs; cd ->/dev/null)" >> $GITHUB_ENV + +# - name: Get DaisyDiff +# run: | +# wget -O- https://github.com/AndroidKitKat/ExecuteDaisy/archive/master.zip | jar -x +# [ -d "output/images" ] || mkdir "output/images"; +# cp -u -r ExecuteDaisy-master/js ExecuteDaisy-master/css output; +# cp -u ExecuteDaisy-master/images/* output/images; + + + - name: Make tmp dir + run: mkdir tmp + +# - name: diff +# run: TMP=tmp make diff || true; + # Little diff depends on having a git history. + # The current checkout has depth=1 and has no history + #- name: little diff + # run: make little-diff || true + + - name: Outstanding TDs + id: tds + run: | + if [ "${{steps.extract_branch.outputs.branch}}" == "master" ] && + ls input/tds/*.xml ; then + echo "Master branch should not have TDs" >> output/TDValidationReport.txt + fi + # make effective + # PP_XML=output/effective.xml RNG_OUT=output/TDValidationReport.txt make validate || true + # IF STATEMENT HERE + # PP_XML=output/effective.xml PP_RELEASE_HTML=output/AppliedTDs.html make release + # java -jar ExecuteDaisy-master/*.jar output/*-release.html output/AppliedTDs.html --file=output/AppliedTDs-Diff.html + + - name: Set TD badge attributes + run: | + NUM=$(ls input/tds/*.xml | wc -l) + if [ $NUM == 0 ]; then + echo "action_tdcolor=gray" >> $GITHUB_ENV + echo "action_tdwarns=N/A" >> $GITHUB_ENV + echo "GOING THROUGH HERE $NUM" + else + echo "action_tdcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV + echo "action_tdwarns=$NUM:$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;})" >> $GITHUB_ENV + echo "THERE ARE TDs $NUM" + + fi + # Not sure what the point of this is + - name: Validate Effective + run: | + echo "action_effvalcolor=$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" >> $GITHUB_ENV + echo "action_effvalwarns=$(wc -l output/TDValidationReport.txt | { read first rest ; echo $first;} )" >> $GITHUB_ENV + + + - name: Prepare environment + run: | + # Generates a GitHub Workflow output named `lines` with a coverage value + echo "action_spellcolor=$(if [ 0 = ${{ env.action_spellerrors }} ]; then echo green; else echo red; fi)" >> $GITHUB_ENV + echo "action_valcolor=$(if [ 0 = ${{ env.action_valerrors }} ]; then echo green; else echo red; fi)" >> $GITHUB_ENV + echo "action_sanitystatus=$(if [ -s output/SanityChecksOutput.md ]; then echo some; else echo none; fi)" >> $GITHUB_ENV + echo "action_sanitycolor=$(if [ -s output/SanityChecksOutput.md ]; then echo red; else echo green; fi )" >> $GITHUB_ENV + + + + - name: Generate the spelling badge SVG image + uses: emibcn/badge-action@v2.0.2 + with: + label: 'Misspellings' + status: ${{ env.action_spellerrors }} + color: ${{ env.action_spellcolor }} + path: output/spell-badge.svg + + + + - name: Generate the validation badge SVG image + uses: emibcn/badge-action@v2.0.2 + with: + label: 'Validation' + status: ${{ env.action_valerrors }} + color: ${{ env.action_valcolor }} + path: output/validation.svg + + + - name: Generate the warnings badge + uses: emibcn/badge-action@v2.0.2 + with: + label: 'Warnings' + status: ${{ env.action_sanitystatus }} + color: ${{ env.action_sanitycolor }} + path: output/warnings.svg + + + - name: Generate the transforms badge + uses: emibcn/badge-action@v2.0.2 + with: + label: 'Transforms' + status: ${{ env.action_tdate }} + color: gray + path: output/transforms.svg + + - name: TD Badge + uses: emibcn/badge-action@v2.0.2 + with: + label: 'TDs' + status: ${{ env.action_tdwarns }} + color: ${{ env.action_tdcolor }} + path: output/tds.svg + + - name: Make Dashboard Snippet + run: | + rurl="https://raw.githubusercontent.com/appswcpp/${{env.action_projname}}/gh-pages/${{env.action_branch}}" + surl="https://appswcpp.github.io/${{env.action_projname}}/${{env.action_branch}}" + gurl="https://github.com/appswcpp/${{env.action_projname}}/blob/gh-pages/${{env.action_branch}}" + ( + echo '[cols="1,1,1,1,1,1,1,1"]' + echo '|===' + echo "8+|${{ env.action_projname }} " + echo "| https://github.com/appswcpp/${{env.action_projname}}/tree/${{env.action_branch}}[${{ env.action_branch }}] " + echo "a| $surl/${{env.action_projname}}-release.html[๐Ÿ“„]" + echo "a|[link=$gurl/ValidationReport.txt]" + echo "image::$rurl/validation.svg[Validation]" + echo "a|[link=$gurl/SanityChecksOutput.md]" + echo "image::$rurl/warnings.svg[SanityChecks]" + echo "a|[link=$gurl/SpellCheckReport.txt]" + echo "image::$rurl/spell-badge.svg[SpellCheck]" + echo "a|[link=$gurl/TDValidationReport.txt]" + echo "image::$rurl/tds.svg[TDs]" + echo "a|image::$rurl/transforms.svg[transforms,150]" + echo "a| [link=$gurl/HTMLs.adoc]" + echo "image::$rurl/html_count.svg[HTML Count]" + echo "[link=$gurl/PDFs.adoc]" + echo "image::$rurl/pdf_count.svg[PDF Count]" + echo '|===' + ) > output/Minidash.adoc + + + - name: HTML List + run: | + surl="https://appswcpp.github.io/${{env.action_projname}}/${{env.action_branch}}" + ( for aa in output/*.html ; do + echo "* $surl/${aa#*/}[${aa#*/}]" + done ) > output/HTMLs.adoc + HTML_COUNT=$(wc -l < output/HTMLs.adoc) + echo "action_html_count=$HTML_COUNT" >> $GITHUB_ENV + + - name: PDF List + run: | + surl="https://appswcpp.github.io/${{env.action_projname}}/${{env.action_branch}}" + cd output + (for aa in $(find . -name '*.pdf') ; do + echo "* $surl/${aa#*/}[${aa#*/}]" + done ) > PDFs.adoc + PDF_COUNT=$(wc -l < PDFs.adoc) + echo "action_pdf_count=$PDF_COUNT" >> $GITHUB_ENV + + + - name: HTML Badge + uses: emibcn/badge-action@v2.0.2 + with: + label: 'HTMLs' + status: ${{ env.action_html_count }} + color: gray + path: output/html_count.svg + + - name: PDF Badge + uses: emibcn/badge-action@v2.0.2 + with: + label: 'PDFs' + status: ${{ env.action_pdf_count }} + color: gray + path: output/pdf_count.svg + + + - name: Prepare checkout + run: | + mkdir gh-pages + + - uses: actions/checkout@v3 + with: + ref: gh-pages + path: gh-pages + + + - name: Move output to branch + run: | + rm -rf gh-pages/${{ env.action_branch }} + mv output gh-pages/${{ env.action_branch }} + + - name: Make listing + run: | + cd gh-pages + (echo "Listing"; + date; + echo "
    "; + for aa in $(find . -name '*.*'); do + echo "
  1. $aa
    2. "; + done; + echo "
") > index.html + + - name: Deploy ๐Ÿš€ + uses: JamesIves/github-pages-deploy-action@v4 + with: + branch: gh-pages # The branch the action should deploy to. + folder: gh-pages # The folder the action should deploy. diff --git a/cPP/v2/.github/workflows/validate.yml b/.github/workflows/validate.yml similarity index 100% rename from cPP/v2/.github/workflows/validate.yml rename to .github/workflows/validate.yml diff --git a/.gitignore b/.gitignore index 9bea433..002872c 100644 --- a/.gitignore +++ b/.gitignore @@ -1,2 +1,15 @@ - +output/*.* +output/css +output/js +*~ +input/*.html +input/schemas.xml +*.rnc +tmp +LocalUser.make +output/images/diff-*.gif .DS_Store +.venv-build/pyvenv.cfg +.venv-build/bin/python3.12 +.venv-build/bin/python3 +.venv-build/bin/python diff --git a/.gitmodules b/.gitmodules new file mode 100644 index 0000000..c6fee0c --- /dev/null +++ b/.gitmodules @@ -0,0 +1,3 @@ +[submodule "transforms"] + path = transforms + url = https://github.com/commoncriteria/transforms.git diff --git a/AppIT/AppIT_Process.adoc b/Archive/AppIT/AppIT_Process.adoc similarity index 100% rename from AppIT/AppIT_Process.adoc rename to Archive/AppIT/AppIT_Process.adoc diff --git a/AppIT/images/AppIT1.jpeg b/Archive/AppIT/images/AppIT1.jpeg similarity index 100% rename from AppIT/images/AppIT1.jpeg rename to Archive/AppIT/images/AppIT1.jpeg diff --git a/Archive/LICENSE b/Archive/LICENSE new file mode 100644 index 0000000..6fc560f --- /dev/null +++ b/Archive/LICENSE @@ -0,0 +1,21 @@ +MIT License + +Copyright (c) 2019 itc-wgtools + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. diff --git a/Modules/Agent/.asciidoctor/diagram/FCO_CPC_EXT.png.cache b/Archive/Modules/Agent/.asciidoctor/diagram/FCO_CPC_EXT.png.cache similarity index 100% rename from Modules/Agent/.asciidoctor/diagram/FCO_CPC_EXT.png.cache rename to Archive/Modules/Agent/.asciidoctor/diagram/FCO_CPC_EXT.png.cache diff --git a/Modules/Agent/SD-MOD-Agent.adoc b/Archive/Modules/Agent/SD-MOD-Agent.adoc similarity index 100% rename from Modules/Agent/SD-MOD-Agent.adoc rename to Archive/Modules/Agent/SD-MOD-Agent.adoc diff --git a/Archive/Modules/Agent/appSW_PP_Config_ServerAgent.adoc b/Archive/Modules/Agent/appSW_PP_Config_ServerAgent.adoc new file mode 100644 index 0000000..55f9f9f --- /dev/null +++ b/Archive/Modules/Agent/appSW_PP_Config_ServerAgent.adoc @@ -0,0 +1,342 @@ += PP-Configuration for Enterprise Server Applications and Agent/Application Component(s) +:showtitle: +:toc: +:table-caption: Table +:icons: font +:revnumber: 1.0e +:revdate: 2024-02-15 + +:iTC-longname: iTC for Application Software +:iTC-shortname: AppSW-iTC +:iTC-email: cm-itc-mailing-list@gmail.com +:iTC-website: https://appswcpp.github.io/ +:iTC-GitHub: https://github.com/appswcpp/repository/ + +:sectnums!: +== Acknowledgements + +This PP-Configuration was developed by the {iTC-longname} international Technical Community (iTC) also known as {iTC-shortname} with representatives from Industry, Government agencies, Common Criteria Test Laboratories, and members of academia. + +=== Revision History + +.Revision history +[%header,cols="1,2,4"] +|=== +|Version +|Date +|Description + +|1.0 +|2022-04-06 +|Initial Release + +|1.0e +|2024-02-15 +|Incorporated feedback received following initial release. + + +|=== + +:sectnums: +== Introduction + +=== PP-Configuration Overview +The purpose of a PP-Configuration is to combine Protection Profiles (PPs) and PP-Modules for various technology types into a single configuration that can be evaluated as a whole. + +This PP-Configuration is for enterprise server applications and their agent or application component(s). It provides the enforceable PP-Configuration path for distributed application software, including server-agent deployments, clustered server deployments, and microservices architectures composed of multiple application payload components. + +=== PP-Configuration Reference + +This PP-Configuration is identified as follows: + +* PP-Configuration for Enterprise Server Applications and Agent/Application Component(s), Version {revnumber}, {revdate} +* As a shorthand reference, it can be identified as "CFG_APP-Server-Agent_V{revnumber}"" + +=== PP-Configuration Components + +This PP-Configuration includes the following components: + +.PP-Configuration Components +[cols="1,3"] +|=== +|[base PP] +|cPP_APP_SW_V1.1 + +|[PP-Module 1] +|MOD_Server_v1.1 + +|[PP-Module 2] +|MOD_Agent_v1.1 + +|=== + +=== Distributed and Microservices TOE Architectures +For this PP-Configuration, a distributed TOE consists of multiple separately deployed application components that collectively provide the TOE security functionality. Each TOE component shall be identified in the ST and mapped to the base PP, Server Module, Agent Module, or a combination of those components, as applicable. + +For containerized or microservices TOEs, the TOE consists of the application payload components identified in the ST. The container orchestration platform, container runtime, operating system, service mesh infrastructure, ingress infrastructure, cluster networking, and platform-provided secret or configuration stores are part of the operational environment unless explicitly included in the TOE boundary. + +The ST shall provide an SFR allocation rationale that identifies whether each claimed requirement is satisfied by all TOE components, by applicable TOE components that perform the relevant function, by at least one TOE component, by the TOE as a whole, or by an allowed operational environment dependency. The ST shall describe all inter-component TOE communications and identify the mechanisms used to authorize and protect those communications. + +==== SFR Allocation for Distributed TOEs +For a distributed TOE, the SFRs are satisfied by the TOE as a whole; however, not every SFR is necessarily implemented by every TOE component. The ST author shall use the following allocation categories to identify how each SFR is satisfied by the distributed TOE. + +All Components:: +Every TOE component shall independently satisfy the requirement. + +Applicable Components:: +Every TOE component that performs the relevant function shall satisfy the requirement. The ST shall identify the components to which the requirement applies and justify why the requirement does not apply to other TOE components. + +At Least One Component:: +At least one TOE component shall satisfy the requirement on behalf of the TOE. The ST shall identify the component or components that satisfy the requirement and describe how this satisfies the TOE-level claim. + +TOE as a Whole:: +The requirement is satisfied by the collective behavior of the TOE components. The ST shall describe the TOE-level behavior and identify any component responsibilities necessary to satisfy the claim. + +Operational Environment Dependency:: +The TOE relies on the operational environment for the function, where allowed by the base cPP or PP-Module. The ST shall identify the environmental dependency and the guidance shall describe the required environmental configuration. + +The following table defines the expected allocation for the base cPP SFRs in a distributed TOE. + +.Base cPP SFR Allocation for Distributed TOEs +[cols="2,2,4",options="header"] +|=== +|SFR +|Allocation +|Distributed TOE guidance + +|FCS_CKM.1/AK +|Applicable Components +|Applies to each TOE component that invokes or implements asymmetric key generation. + +|FCS_CKM.1/SK +|Applicable Components +|Applies to each TOE component that generates symmetric keys. + +|FCS_CKM.2 +|Applicable Components +|Applies to each TOE component that performs key establishment. + +|FCS_CKM_EXT.1 +|Applicable Components +|Applies to each TOE component that invokes or implements key generation services. + +|FCS_COP.1/Hash +|Applicable Components +|Applies to each TOE component that performs hashing for a claimed function. + +|FCS_COP.1/KeyedHash +|Applicable Components +|Applies to each TOE component that performs keyed-hash functions for a claimed function. + +|FCS_COP.1/SigGen +|Applicable Components +|Applies to each TOE component that generates digital signatures. + +|FCS_COP.1/SigVer +|Applicable Components +|Applies to each TOE component that verifies digital signatures, including update verification if performed by that component. + +|FCS_COP.1/SKC +|Applicable Components +|Applies to each TOE component that performs encryption or decryption. + +|FCS_HTTPS_EXT.1 +|Applicable Components +|Applies to each TOE component that implements HTTPS as a client, server, or server with mutual authentication. + +|FCS_HTTPS_EXT.2 +|Applicable Components +|Applies to each TOE component that implements HTTPS with peer certificate authentication behavior covered by this requirement. + +|FCS_PBKDF_EXT.1 +|Applicable Components +|Applies to each TOE component that performs password conditioning. + +|FCS_RBG.1 +|Applicable Components +|Applies to each TOE component that implements RBG functionality. + +|FCS_RBG.2 +|Applicable Components +|Applies to each TOE component that implements RBG functionality using external seeding. + +|FCS_RBG.3 +|Applicable Components +|Applies to each TOE component that implements RBG functionality using a single internal noise source. + +|FCS_RBG.4 +|Applicable Components +|Applies to each TOE component that implements RBG functionality using multiple internal noise sources. + +|FCS_RBG.5 +|Applicable Components +|Applies to each TOE component that implements RBG functionality using combined noise sources. + +|FCS_RBG_EXT.1 +|Applicable Components +|Applies to each TOE component that invokes platform-provided RBG services, implements RBG functionality, or claims no RBG functionality. + +|FCS_SNI_EXT.1 +|Applicable Components +|Applies to each TOE component that creates or uses salts, nonces, or initialization vectors for claimed cryptographic functions. + +|FCS_STO_EXT.1 +|Applicable Components +|Applies to each TOE component that persistently stores credentials. + +|FDP_DAR_EXT.1 +|Applicable Components +|Applies to each TOE component that stores sensitive application data at rest. + +|FDP_DEC_EXT.1 +|All Components +|Each TOE component shall identify and restrict its access to platform resources and sensitive information repositories as required by the base cPP. + +|FDP_NET_EXT.1 +|All Components +|Each TOE component shall identify and restrict its inbound and outbound network communications. + +|FMT_CFG_EXT.1 +|All Components +|Each TOE component shall satisfy secure-by-default and file-permission requirements for its installed binaries, data, and default credentials. + +|FMT_MEC_EXT.1 +|Applicable Components +|Applies to each TOE component that stores or manages configuration options. + +|FMT_SMF.1 +|Applicable Components +|Applies to each TOE component that provides security management functions. At least one component shall be identified if management functions are claimed for the TOE. + +|FPR_ANO_EXT.1 +|Applicable Components +|Applies to each TOE component that transmits personally identifiable information. + +|FPT_AEX_EXT.1 +|All Components +|Each TOE component shall satisfy the anti-exploitation requirements applicable to its platform and implementation type. + +|FPT_API_EXT.1 +|All Components +|Each TOE component shall use only documented and supported platform APIs. + +|FPT_API_EXT.2 +|Applicable Components +|Applies to each TOE component that parses IANA MIME media types covered by the objective requirement. + +|FPT_FLS.1 +|Applicable Components +|Applies to each TOE component that must preserve a secure state for the selected failure conditions. + +|FPT_IDV_EXT.1 +|TOE as a Whole +|The TOE shall identify software versions. The ST shall identify how each separately versioned TOE component is represented in the TOE version information. + +|FPT_LIB_EXT.1 +|All Components +|Each TOE component shall identify its third-party libraries. + +|FPT_TST.1 +|Applicable Components +|Applies to each TOE component that performs TSF self-tests or integrity verification covered by the requirement. + +|FPT_TUD_EXT.1 +|TOE as a Whole +|The TOE shall provide trusted update support. The ST shall identify how each updateable TOE component is checked, delivered, installed, and versioned. + +|FPT_TUD_EXT.2 +|Applicable Components +|Applies to each TOE component or update package that performs installation or update integrity functions covered by this selection-based requirement. + +|FTP_DIT_EXT.1 +|Applicable Components +|Applies to each TOE component that transmits data or sensitive data to another trusted IT product or invokes platform-provided functionality for that protection. Inter-component TOE communications are addressed by the Server and Agent Module requirements in this PP-Configuration. +|=== + +The following table defines the expected allocation for the Server and Agent PP-Module SFRs in a distributed TOE. + +.Server and Agent Module SFR Allocation for Distributed TOEs +[cols="2,2,4",options="header"] +|=== +|SFR +|Allocation +|Distributed TOE guidance + +|FMT_MEC_EXT.1/Server +|Applicable Components +|Applies to each Server Application component that stores or manages server configuration data. + +|FMT_SMF.1/Server +|Applicable Components +|Applies to each Server Application component that provides management functions. The ST shall identify which component or components manage inter-component communications, enrollment, or policy. + +|FPT_AEX_EXT.2/Server +|All Server Components +|Each Server Application component shall be compatible with security features provided by its platform vendor. + +|FCO_CPC_EXT.1/Server +|Applicable Components +|Applies to each Server Application component that enables, disables, registers, or authorizes communication with another TOE component. + +|FIA_X509_EXT.1/ITT/Server +|Applicable Components +|Applies to each Server Application component that validates X.509 certificates for inter-TOE-part communication. + +|FPT_ITT.1/Server +|Applicable Components +|Applies to each Server Application component that transmits TSF data between separate parts of the TOE. + +|FCO_CPC_EXT.1/Agent +|Applicable Components +|Applies to each Agent Application component that is enabled, disabled, registered, authorized, or otherwise controlled for communication with another TOE component. + +|FPT_ITT.1/Agent +|Applicable Components +|Applies to each Agent Application component that transmits TSF data between separate parts of the TOE. + +|FIA_X509_EXT.1/ITT/Agent +|Applicable Components +|Applies to each Agent Application component that validates X.509 certificates for inter-TOE-part communication. +|=== + +If an operational environment component, such as a container orchestration platform, container runtime, service mesh infrastructure, ingress infrastructure, cluster networking, or platform-provided secret or configuration store, is relied upon to support a claimed SFR, the ST shall identify the dependency. The evaluator assesses the TOE's use of the dependency and the required configuration guidance, but the environmental component is not included in the TOE boundary unless explicitly claimed. + +If a TOE container receives credentials, keys, tokens, certificates, or other secrets from an operational environment mechanism, such as a platform secret store, mounted secret volume, injected environment variable, or external secrets provider, the ST shall identify the mechanism, the TOE components that consume the secrets, the purpose of each secret, and whether the TOE persists, transforms, caches, or re-exports the secret. If the TOE persists or manages the secret after receipt, the applicable base cPP requirements, including FCS_STO_EXT.1, FDP_DAR_EXT.1, FMT_MEC_EXT.1, and related cryptographic requirements, apply to the TOE component performing that function. + +== Conformance Claims + +=== CC Statement + +To be conformant to this PP-Configuration, an ST must demonstrate Exact Conformance, as defined by the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs. + +=== CC Conformance Claims + +This PP-Configuration, and its components specified in section 1.3, are conformant to Parts 2 (extended) and 3 (conformant) of Common Criteria Version 3.1, Release 5 [CC]. + +== SAR Statement + +The set of SARs specified for this PP-Configuration are taken from, and identical to, those specified in the base PP. + +=== Related Documents + +**Common Criteria**footnote:[For details see http://www.commoncriteriaportal.org/] + +.Common Criteria References +[cols="1,3",] +|=== +|[#CC1]#[CC1]# |Common Criteria for Information Technology Security Evaluation, + +Part 1: Introduction and General Model, + +CCMB-2017-04-001, Version 3.1 Revision 5, April 2017. +|[#CC2]#[CC2]# |Common Criteria for Information Technology Security Evaluation, + +Part 2: Security Functional Components, + +CCMB-2017-04-002, Version 3.1 Revision 5, April 2017. +|[#CC3]#[CC3]# |Common Criteria for Information Technology Security Evaluation, + +Part 3: Security Assurance Components, + +CCMB-2017-04-003, Version 3.1 Revision 5, April 2017. +|[#CEM]#[CEM]# |Common Methodology for Information Technology Security Evaluation, + +Evaluation Methodology, + +CCMB-2017-04-004, Version 3.1 Revision 5, April 2017. +|[#addenda]#[addenda]# |CC and CEM addenda, + +Exact Conformance, Selection-Based SFRs, Optional SFRs, + +Version 0.5, May 2017. +|=== diff --git a/Modules/Agent/cPP_MOD-Agent.adoc b/Archive/Modules/Agent/cPP_MOD-Agent.adoc similarity index 86% rename from Modules/Agent/cPP_MOD-Agent.adoc rename to Archive/Modules/Agent/cPP_MOD-Agent.adoc index 1dab93b..be8ee52 100644 --- a/Modules/Agent/cPP_MOD-Agent.adoc +++ b/Archive/Modules/Agent/cPP_MOD-Agent.adoc @@ -92,11 +92,20 @@ For more see the http://www.commoncriteriaportal.org/[Common Criteria Portal]. ==== Compliant Targets of Evaluation -This is a Collaborative Protection Profile (cPP) Module whose Target of Evaluation (TOE) is Enterprise Agent Applications. This PP-Module is compatible with the cPP for Application Software and collaborative PP-Module for Server Applications. +This is a Collaborative Protection Profile (cPP) Module whose Target of Evaluation (TOE) is Enterprise Agent Applications. This PP-Module is compatible with the cPP for Application Software and collaborative PP-Module for Server Applications. + +For purposes of a PP-Configuration, an Agent Application is any separately deployed TOE application component that communicates with another TOE component under the control, coordination, policy, enrollment, or trust relationship established by the TOE. This may include endpoint agents, worker services, peer services, microservice payloads, subordinate application services, or other application components that are identified as TOE parts in the ST. + +For containerized or microservices TOEs, the TOE consists of the application payload components identified in the ST. The container orchestration platform, container runtime, operating system, service mesh infrastructure, ingress infrastructure, cluster networking, and platform-provided secret or configuration stores are part of the operational environment unless explicitly included in the TOE boundary. === TOE Use Cases All use cases of Enterprise Agent applications defined in the {base-pp} are applicable to this PP-Module. +=== Distributed and Microservices TOE Configurations +This PP-Module may be used in a PP-Configuration with the PP-Module for Server Applications to evaluate distributed application software. Distributed application software includes server-agent deployments, clustered server deployments, and microservices architectures composed of multiple application payload components. + +The ST shall identify each Agent Application component, describe the role of each component, identify which claimed SFRs are implemented by each component, and describe all communications between Agent Application components and other TOE components. The ST shall also distinguish TOE components from operational environment components. If the TOE relies on operational environment components for execution, scheduling, networking, isolation, credential storage, configuration storage, time services, or protection of inter-component communications, the ST shall identify the dependency and the guidance shall describe the required environmental configuration. + == CC Conformance Claims As defined by the references <>, <> and <>, this PP-Module: @@ -178,7 +187,7 @@ The TSF shall implement a registration process in which TOE parts establish and ]. -*Application Note {counter:appnote}:* An Agent can communicate with a Server or another Agent. This SFR can be iterated if the registration method varies depending on what TOE parts are communicating. +*Application Note {counter:appnote}:* An Agent can communicate with a Server, another Agent, or another separately deployed TOE component identified in the ST. In a microservices architecture, this may include communication between application payload services. This SFR can be iterated if the registration method varies depending on what TOE parts are communicating. "No channel" is selected if the registration is performed via out-of-band manual means. *FCO_CPC_EXT.1.3/Agent* @@ -260,7 +269,7 @@ This is a new component within the FCO class used to define high-level constrain +---------------------------------------+ +-----+ .... -FCO_CPC_EXT.1/Agent Component Registration Channel Definition, requires the TSF to support a registration channel for joining together server and agent TOE parts, and to ensure that the availability of this channel is under the control of an Administrator. It also requires statement of the type of channel used (allowing specification of further lower-level security requirements by reference to other SFRs). +FCO_CPC_EXT.1/Agent Component Registration Channel Definition, requires the TSF to support a registration channel for joining together server and agent TOE parts or other distributed application TOE components, and to ensure that the availability of this channel is under the control of an Administrator. It also requires statement of the type of channel used (allowing specification of further lower-level security requirements by reference to other SFRs). *Management: FCO_CPC_EXT.1/Agent* @@ -301,4 +310,4 @@ Dependencies: No other components When this PP-Module is used to extend [cPP_APP_SW], the TOE type for the overall TOE is still a generic application. However, one of the functions of the device must be the ability for it to the capability to be managed by a server application. The TOE boundary is simply extended to include that functionality. === SFR Dependencies Analysis -The dependencies between SFRs implemented by the TOE are addressed as shown in the base PP. \ No newline at end of file +The dependencies between SFRs implemented by the TOE are addressed as shown in the base PP. diff --git a/Modules/Agent/images/FCO_CPC_EXT.png b/Archive/Modules/Agent/images/FCO_CPC_EXT.png similarity index 100% rename from Modules/Agent/images/FCO_CPC_EXT.png rename to Archive/Modules/Agent/images/FCO_CPC_EXT.png diff --git a/Modules/Agent/images/fpt_aex_ext_componentlevel.jpg b/Archive/Modules/Agent/images/fpt_aex_ext_componentlevel.jpg similarity index 100% rename from Modules/Agent/images/fpt_aex_ext_componentlevel.jpg rename to Archive/Modules/Agent/images/fpt_aex_ext_componentlevel.jpg diff --git a/Modules/Agent/images/tbd.jpg b/Archive/Modules/Agent/images/tbd.jpg similarity index 100% rename from Modules/Agent/images/tbd.jpg rename to Archive/Modules/Agent/images/tbd.jpg diff --git a/Modules/Server/.asciidoctor/diagram/FCO_CPC_EXT.png.cache b/Archive/Modules/Server/.asciidoctor/diagram/FCO_CPC_EXT.png.cache similarity index 100% rename from Modules/Server/.asciidoctor/diagram/FCO_CPC_EXT.png.cache rename to Archive/Modules/Server/.asciidoctor/diagram/FCO_CPC_EXT.png.cache diff --git a/Modules/Server/.asciidoctor/diagram/FMT_MEC_EXT.png.cache b/Archive/Modules/Server/.asciidoctor/diagram/FMT_MEC_EXT.png.cache similarity index 100% rename from Modules/Server/.asciidoctor/diagram/FMT_MEC_EXT.png.cache rename to Archive/Modules/Server/.asciidoctor/diagram/FMT_MEC_EXT.png.cache diff --git a/Modules/Server/.asciidoctor/diagram/FPT_AEX_EXT.png.cache b/Archive/Modules/Server/.asciidoctor/diagram/FPT_AEX_EXT.png.cache similarity index 100% rename from Modules/Server/.asciidoctor/diagram/FPT_AEX_EXT.png.cache rename to Archive/Modules/Server/.asciidoctor/diagram/FPT_AEX_EXT.png.cache diff --git a/Modules/Server/SD-MOD-Server.adoc b/Archive/Modules/Server/SD-MOD-Server.adoc similarity index 100% rename from Modules/Server/SD-MOD-Server.adoc rename to Archive/Modules/Server/SD-MOD-Server.adoc diff --git a/Modules/Server/appSW_PP_Config_Server.adoc b/Archive/Modules/Server/appSW_PP_Config_Server.adoc similarity index 100% rename from Modules/Server/appSW_PP_Config_Server.adoc rename to Archive/Modules/Server/appSW_PP_Config_Server.adoc diff --git a/Modules/Server/cPP_MOD-Server.adoc b/Archive/Modules/Server/cPP_MOD-Server.adoc similarity index 88% rename from Modules/Server/cPP_MOD-Server.adoc rename to Archive/Modules/Server/cPP_MOD-Server.adoc index 8fe618a..4599f74 100644 --- a/Modules/Server/cPP_MOD-Server.adoc +++ b/Archive/Modules/Server/cPP_MOD-Server.adoc @@ -92,11 +92,20 @@ For more see the http://www.commoncriteriaportal.org/[Common Criteria Portal]. ==== Compliant Targets of Evaluation -This is a Collaborative Protection Profile (cPP) Module whose Target of Evaluation (TOE) is Enterprise Server Applications. This PP-Module is compatible with the cPP for Application Software. +This is a Collaborative Protection Profile (cPP) Module whose Target of Evaluation (TOE) is Enterprise Server Applications. This PP-Module is compatible with the cPP for Application Software. + +For a distributed TOE, the Server Application is the TOE component, or set of TOE components, that provides management, coordination, policy, API-facing, or other server-side functionality for the TOE. In a microservices architecture, a Server Application component may be a service or application payload that coordinates, exposes, or controls TOE functionality. The container orchestration platform, container runtime, operating system, service mesh infrastructure, ingress infrastructure, cluster networking, and platform-provided secret or configuration stores are part of the operational environment unless explicitly included in the TOE boundary. === TOE Use Cases All use cases of Enterprise Server applications defined in the {base-pp} are applicable to this PP-Module. +=== Distributed and Microservices TOE Configurations +This PP-Module may be used in a PP-Configuration with the PP-Module for Agent Applications to evaluate distributed application software. Distributed application software includes server-agent deployments, clustered server deployments, and microservices architectures composed of multiple application payload components. + +For a distributed TOE, the ST shall identify each TOE component, describe the role of each TOE component, identify which components implement each claimed SFR, and describe all communications between TOE components. The ST shall also distinguish TOE components from operational environment components. Operational environment components may include container orchestration, container runtimes, operating systems, service mesh infrastructure, ingress infrastructure, cluster networking, platform-provided secret or configuration stores, and other infrastructure services not explicitly included in the TOE boundary. + +If the TOE relies on operational environment components for execution, scheduling, networking, isolation, credential storage, configuration storage, time services, or protection of inter-component communications, the ST shall identify the dependency and the guidance shall describe the required environmental configuration. + == CC Conformance Claims As defined by the references <>, <> and <>, this PP-Module: @@ -205,7 +214,7 @@ The TSF shall be capable of performing the following management functions: * configuration of communication with other trusted IT entities * [_selection:_ -** _configuration of communication with Agent according to FCO_CPC_EXT.1/Server and FPT_ITT.1/Server_ +** _configuration of communication with other TOE components according to FCO_CPC_EXT.1/Server and FPT_ITT.1/Server_ ** _allow/disallow the enrollment of a TOE agent by administrative function or policy,_ ** _query agent version,_ ** _provide update functionality to agent,_ @@ -215,7 +224,7 @@ The TSF shall be capable of performing the following management functions: ** _configure number of authentication attempts and failed authentication behavior,_ ** _[assignment: Other management functions]_] -*Application Note {counter:appnote}:* Functions that relate to management of agents is intended to be used in conjuction with the Agent module, however, it can be used with third party agents that aren't necessarily within the TOE boundary. +*Application Note {counter:appnote}:* Functions that relate to management of agents or other separately deployed TOE components are intended to be used in conjunction with the Agent module. The same functions may also be used with third-party entities that are in the operational environment and are not within the TOE boundary. === Protection of the TSF (FPT) @@ -231,7 +240,7 @@ This PP-Module does not define any additional assurance requirements above and b [appendix] == Selection-Based Requirements -These SFRs apply if and only if an Agent Module is included in the evaluation. +These SFRs apply when the TOE includes separately deployed TOE parts that communicate with one another as part of a PP-Configuration that includes the Agent Module. For microservices architectures, these SFRs apply to the communication relationships between Server Application components and Agent Application components as those components are identified in the ST. The ST author should iterate these SFRs as needed for different component pairs or communication mechanisms. === Communication (FCO) ==== FCO_CPC_EXT.1/Server @@ -419,7 +428,7 @@ This is a new component within the FCO class used to define high-level constrain +---------------------------------------+ +-----+ .... -FCO_CPC_EXT.1/Server Component Registration Channel Definition, requires the TSF to support a registration channel for joining together server and agent TOE parts, and to ensure that the availability of this channel is under the control of an Administrator. It also requires statement of the type of channel used (allowing specification of further lower-level security requirements by reference to other SFRs). +FCO_CPC_EXT.1/Server Component Registration Channel Definition, requires the TSF to support a registration channel for joining together server and agent TOE parts or other distributed application TOE components, and to ensure that the availability of this channel is under the control of an Administrator. It also requires statement of the type of channel used (allowing specification of further lower-level security requirements by reference to other SFRs). *Management: FCO_CPC_EXT.1/Server* @@ -459,4 +468,4 @@ Dependencies: No other components When this PP-Module is used to extend [cPP_APP_SW], the TOE type for the overall TOE is still a generic application. However, one of the functions of the device must be the ability for it to the capability to manage agent applications. The TOE boundary is simply extended to include that functionality. === SFR Dependencies Analysis -The dependencies between SFRs implemented by the TOE are addressed as shown in the base PP. \ No newline at end of file +The dependencies between SFRs implemented by the TOE are addressed as shown in the base PP. diff --git a/Modules/Server/images/FCO_CPC_EXT.png b/Archive/Modules/Server/images/FCO_CPC_EXT.png similarity index 100% rename from Modules/Server/images/FCO_CPC_EXT.png rename to Archive/Modules/Server/images/FCO_CPC_EXT.png diff --git a/Modules/Server/images/FMT_MEC_EXT.png b/Archive/Modules/Server/images/FMT_MEC_EXT.png similarity index 100% rename from Modules/Server/images/FMT_MEC_EXT.png rename to Archive/Modules/Server/images/FMT_MEC_EXT.png diff --git a/Modules/Server/images/FPT_AEX_EXT.png b/Archive/Modules/Server/images/FPT_AEX_EXT.png similarity index 100% rename from Modules/Server/images/FPT_AEX_EXT.png rename to Archive/Modules/Server/images/FPT_AEX_EXT.png diff --git a/Modules/Server/images/fpt_aex_ext_componentlevel.jpg b/Archive/Modules/Server/images/fpt_aex_ext_componentlevel.jpg similarity index 100% rename from Modules/Server/images/fpt_aex_ext_componentlevel.jpg rename to Archive/Modules/Server/images/fpt_aex_ext_componentlevel.jpg diff --git a/Modules/Server/images/tbd.jpg b/Archive/Modules/Server/images/tbd.jpg similarity index 100% rename from Modules/Server/images/tbd.jpg rename to Archive/Modules/Server/images/tbd.jpg diff --git a/README.adoc b/Archive/README.adoc similarity index 100% rename from README.adoc rename to Archive/README.adoc diff --git a/cPP/.asciidoctor/diagram/FCS_CKM_EXT.png.cache b/Archive/cPP/.asciidoctor/diagram/FCS_CKM_EXT.png.cache similarity index 100% rename from cPP/.asciidoctor/diagram/FCS_CKM_EXT.png.cache rename to Archive/cPP/.asciidoctor/diagram/FCS_CKM_EXT.png.cache diff --git a/cPP/.asciidoctor/diagram/FCS_HTTPS_EXT.png.cache b/Archive/cPP/.asciidoctor/diagram/FCS_HTTPS_EXT.png.cache similarity index 100% rename from cPP/.asciidoctor/diagram/FCS_HTTPS_EXT.png.cache rename to Archive/cPP/.asciidoctor/diagram/FCS_HTTPS_EXT.png.cache diff --git a/cPP/.asciidoctor/diagram/FCS_RBG_EXT.png.cache b/Archive/cPP/.asciidoctor/diagram/FCS_RBG_EXT.png.cache similarity index 100% rename from cPP/.asciidoctor/diagram/FCS_RBG_EXT.png.cache rename to Archive/cPP/.asciidoctor/diagram/FCS_RBG_EXT.png.cache diff --git a/cPP/.asciidoctor/diagram/FCS_STO_EXT.png.cache b/Archive/cPP/.asciidoctor/diagram/FCS_STO_EXT.png.cache similarity index 100% rename from cPP/.asciidoctor/diagram/FCS_STO_EXT.png.cache rename to Archive/cPP/.asciidoctor/diagram/FCS_STO_EXT.png.cache diff --git a/cPP/.asciidoctor/diagram/FDP_NET_EXT.png.cache b/Archive/cPP/.asciidoctor/diagram/FDP_NET_EXT.png.cache similarity index 100% rename from cPP/.asciidoctor/diagram/FDP_NET_EXT.png.cache rename to Archive/cPP/.asciidoctor/diagram/FDP_NET_EXT.png.cache diff --git a/cPP/.asciidoctor/diagram/FIA_EIP_EXT.png.cache b/Archive/cPP/.asciidoctor/diagram/FIA_EIP_EXT.png.cache similarity index 100% rename from cPP/.asciidoctor/diagram/FIA_EIP_EXT.png.cache rename to Archive/cPP/.asciidoctor/diagram/FIA_EIP_EXT.png.cache diff --git a/cPP/.asciidoctor/diagram/FIA_UAU_EXT.png.cache b/Archive/cPP/.asciidoctor/diagram/FIA_UAU_EXT.png.cache similarity index 100% rename from cPP/.asciidoctor/diagram/FIA_UAU_EXT.png.cache rename to Archive/cPP/.asciidoctor/diagram/FIA_UAU_EXT.png.cache diff --git a/cPP/.asciidoctor/diagram/FIA_UIA_EXT.png.cache b/Archive/cPP/.asciidoctor/diagram/FIA_UIA_EXT.png.cache similarity index 100% rename from cPP/.asciidoctor/diagram/FIA_UIA_EXT.png.cache rename to Archive/cPP/.asciidoctor/diagram/FIA_UIA_EXT.png.cache diff --git a/cPP/.asciidoctor/diagram/FIA_X509_EXT.png.cache b/Archive/cPP/.asciidoctor/diagram/FIA_X509_EXT.png.cache similarity index 100% rename from cPP/.asciidoctor/diagram/FIA_X509_EXT.png.cache rename to Archive/cPP/.asciidoctor/diagram/FIA_X509_EXT.png.cache diff --git a/cPP/.asciidoctor/diagram/FMT_CFG_EXT.png.cache b/Archive/cPP/.asciidoctor/diagram/FMT_CFG_EXT.png.cache similarity index 100% rename from cPP/.asciidoctor/diagram/FMT_CFG_EXT.png.cache rename to Archive/cPP/.asciidoctor/diagram/FMT_CFG_EXT.png.cache diff --git a/cPP/.asciidoctor/diagram/FPT_AEX_EXT.png.cache b/Archive/cPP/.asciidoctor/diagram/FPT_AEX_EXT.png.cache similarity index 100% rename from cPP/.asciidoctor/diagram/FPT_AEX_EXT.png.cache rename to Archive/cPP/.asciidoctor/diagram/FPT_AEX_EXT.png.cache diff --git a/cPP/.asciidoctor/diagram/FPT_TUD_EXT.png.cache b/Archive/cPP/.asciidoctor/diagram/FPT_TUD_EXT.png.cache similarity index 100% rename from cPP/.asciidoctor/diagram/FPT_TUD_EXT.png.cache rename to Archive/cPP/.asciidoctor/diagram/FPT_TUD_EXT.png.cache diff --git a/cPP/.asciidoctor/diagram/FTP_DIT_EXT.png.cache b/Archive/cPP/.asciidoctor/diagram/FTP_DIT_EXT.png.cache similarity index 100% rename from cPP/.asciidoctor/diagram/FTP_DIT_EXT.png.cache rename to Archive/cPP/.asciidoctor/diagram/FTP_DIT_EXT.png.cache diff --git a/cPP/AppSW cPP allowed-with list.docx b/Archive/cPP/AppSW cPP allowed-with list.docx similarity index 100% rename from cPP/AppSW cPP allowed-with list.docx rename to Archive/cPP/AppSW cPP allowed-with list.docx diff --git a/cPP/SD_APP_SW.adoc b/Archive/cPP/SD_APP_SW.adoc similarity index 100% rename from cPP/SD_APP_SW.adoc rename to Archive/cPP/SD_APP_SW.adoc diff --git a/cPP/cPP_APP_SW.adoc b/Archive/cPP/cPP_APP_SW.adoc similarity index 100% rename from cPP/cPP_APP_SW.adoc rename to Archive/cPP/cPP_APP_SW.adoc diff --git a/cPP/images/FCS_CKM_EXT.png b/Archive/cPP/images/FCS_CKM_EXT.png similarity index 100% rename from cPP/images/FCS_CKM_EXT.png rename to Archive/cPP/images/FCS_CKM_EXT.png diff --git a/cPP/images/FCS_HTTPS_EXT.png b/Archive/cPP/images/FCS_HTTPS_EXT.png similarity index 100% rename from cPP/images/FCS_HTTPS_EXT.png rename to Archive/cPP/images/FCS_HTTPS_EXT.png diff --git a/cPP/images/FCS_RBG_EXT.png b/Archive/cPP/images/FCS_RBG_EXT.png similarity index 100% rename from cPP/images/FCS_RBG_EXT.png rename to Archive/cPP/images/FCS_RBG_EXT.png diff --git a/cPP/images/FCS_STO_EXT.png b/Archive/cPP/images/FCS_STO_EXT.png similarity index 100% rename from cPP/images/FCS_STO_EXT.png rename to Archive/cPP/images/FCS_STO_EXT.png diff --git a/cPP/images/FDP_NET_EXT.png b/Archive/cPP/images/FDP_NET_EXT.png similarity index 100% rename from cPP/images/FDP_NET_EXT.png rename to Archive/cPP/images/FDP_NET_EXT.png diff --git a/cPP/images/FIA_EIP_EXT.png b/Archive/cPP/images/FIA_EIP_EXT.png similarity index 100% rename from cPP/images/FIA_EIP_EXT.png rename to Archive/cPP/images/FIA_EIP_EXT.png diff --git a/cPP/images/FIA_UAU_EXT.png b/Archive/cPP/images/FIA_UAU_EXT.png similarity index 100% rename from cPP/images/FIA_UAU_EXT.png rename to Archive/cPP/images/FIA_UAU_EXT.png diff --git a/cPP/images/FIA_UIA_EXT.png b/Archive/cPP/images/FIA_UIA_EXT.png similarity index 100% rename from cPP/images/FIA_UIA_EXT.png rename to Archive/cPP/images/FIA_UIA_EXT.png diff --git a/cPP/images/FIA_X509_EXT.png b/Archive/cPP/images/FIA_X509_EXT.png similarity index 100% rename from cPP/images/FIA_X509_EXT.png rename to Archive/cPP/images/FIA_X509_EXT.png diff --git a/cPP/images/FMT_CFG_EXT.png b/Archive/cPP/images/FMT_CFG_EXT.png similarity index 100% rename from cPP/images/FMT_CFG_EXT.png rename to Archive/cPP/images/FMT_CFG_EXT.png diff --git a/cPP/images/FPT_AEX_EXT.png b/Archive/cPP/images/FPT_AEX_EXT.png similarity index 100% rename from cPP/images/FPT_AEX_EXT.png rename to Archive/cPP/images/FPT_AEX_EXT.png diff --git a/cPP/images/FPT_TUD_EXT.png b/Archive/cPP/images/FPT_TUD_EXT.png similarity index 100% rename from cPP/images/FPT_TUD_EXT.png rename to Archive/cPP/images/FPT_TUD_EXT.png diff --git a/cPP/images/FTP_DIT_EXT.png b/Archive/cPP/images/FTP_DIT_EXT.png similarity index 100% rename from cPP/images/FTP_DIT_EXT.png rename to Archive/cPP/images/FTP_DIT_EXT.png diff --git a/cPP/images/ccLogo.png b/Archive/cPP/images/ccLogo.png similarity index 100% rename from cPP/images/ccLogo.png rename to Archive/cPP/images/ccLogo.png diff --git a/cPP/images/toe.png b/Archive/cPP/images/toe.png similarity index 100% rename from cPP/images/toe.png rename to Archive/cPP/images/toe.png diff --git a/cPP/images/toeruntime.png b/Archive/cPP/images/toeruntime.png similarity index 100% rename from cPP/images/toeruntime.png rename to Archive/cPP/images/toeruntime.png diff --git a/cPP/v2/.github/workflows/quick_build.yml b/Archive/cPP/v2/.github/workflows/quick_build.yml similarity index 100% rename from cPP/v2/.github/workflows/quick_build.yml rename to Archive/cPP/v2/.github/workflows/quick_build.yml diff --git a/cPP/v2/.github/workflows/quick_build_pdf.yml b/Archive/cPP/v2/.github/workflows/quick_build_pdf.yml similarity index 100% rename from cPP/v2/.github/workflows/quick_build_pdf.yml rename to Archive/cPP/v2/.github/workflows/quick_build_pdf.yml diff --git a/Archive/cPP/v2/.github/workflows/validate.yml b/Archive/cPP/v2/.github/workflows/validate.yml new file mode 100644 index 0000000..95e8d02 --- /dev/null +++ b/Archive/cPP/v2/.github/workflows/validate.yml @@ -0,0 +1,26 @@ +# This is a the Common Criteria build workflow that is triggered on push + +name: Validate + +# Controls when the action will run. Workflow runs when manually triggered using the UI +# or API. +on: [push, workflow_dispatch] + +# A workflow run is made up of one or more jobs that can run sequentially or in parallel +jobs: + build-project: + + # The type of runner that the job will run on + runs-on: ubuntu-latest + # Steps represent a sequence of tasks that will be executed as part of the job + steps: + - name: Checkout project and transforms + uses: actions/checkout@v4 + with: + submodules: true + + - name: Install Jing + run: wget -O - https://github.com/relaxng/jing-trang/releases/download/V20181222/jing-20181222.zip | jar -x + + - name: Schema Validation + run: JING_JAR=jing*/bin/jing.jar make validate diff --git a/cPP/v2/.gitignore b/Archive/cPP/v2/.gitignore similarity index 100% rename from cPP/v2/.gitignore rename to Archive/cPP/v2/.gitignore diff --git a/cPP/v2/.gitmodules b/Archive/cPP/v2/.gitmodules similarity index 100% rename from cPP/v2/.gitmodules rename to Archive/cPP/v2/.gitmodules diff --git a/cPP/v2/Dictionary.txt b/Archive/cPP/v2/Dictionary.txt similarity index 100% rename from cPP/v2/Dictionary.txt rename to Archive/cPP/v2/Dictionary.txt diff --git a/cPP/v2/LICENSE b/Archive/cPP/v2/LICENSE similarity index 100% rename from cPP/v2/LICENSE rename to Archive/cPP/v2/LICENSE diff --git a/cPP/v2/Makefile b/Archive/cPP/v2/Makefile similarity index 100% rename from cPP/v2/Makefile rename to Archive/cPP/v2/Makefile diff --git a/cPP/v2/README.md b/Archive/cPP/v2/README.md similarity index 100% rename from cPP/v2/README.md rename to Archive/cPP/v2/README.md diff --git a/cPP/v2/Readme.adoc b/Archive/cPP/v2/Readme.adoc similarity index 100% rename from cPP/v2/Readme.adoc rename to Archive/cPP/v2/Readme.adoc diff --git a/cPP/v2/input/.gitignore b/Archive/cPP/v2/input/.gitignore similarity index 100% rename from cPP/v2/input/.gitignore rename to Archive/cPP/v2/input/.gitignore diff --git a/cPP/v2/input/application.xml b/Archive/cPP/v2/input/application.xml similarity index 99% rename from cPP/v2/input/application.xml rename to Archive/cPP/v2/input/application.xml index 38799a6..dee09bf 100644 --- a/cPP/v2/input/application.xml +++ b/Archive/cPP/v2/input/application.xml @@ -191,6 +191,11 @@ +
+ A TOE may consist of multiple separately deployed application components that collectively provide the TOE security functionality. Examples include server-agent products, clustered application deployments, and microservices-based applications composed of multiple application payloads. If a TOE is distributed across multiple TOE components, the ST shall identify each TOE component, describe the role of each TOE component, identify which components implement each claimed SFR, describe all communications between TOE components, and distinguish TOE components from operational environment components. + For containerized or microservices TOEs, the TOE consists of the application payloads and TOE-provided application components identified in the ST. The container orchestration platform, container runtime, operating system, service mesh infrastructure, ingress infrastructure, cluster networking, and platform-provided secret or configuration stores are part of the operational environment unless explicitly included in the TOE boundary. The PP does not require these operational environment components to be included in the TOE boundary solely because the TOE depends on them for execution, scheduling, networking, isolation, credential storage, configuration storage, or time services. + When the TOE relies on operational environment components to provide services used by the TOE, the ST shall identify the dependency and the guidance shall describe the required environmental configuration. Inter-component communication between TOE parts shall be identified in the ST. Where the TOE claims conformance to a PP-Configuration that includes Server and Agent application modules, the ST shall use the module requirements to address authorization or registration of TOE components before communication is permitted and protection of security-relevant data transmitted between TOE components. The ST shall provide an SFR allocation rationale that identifies whether each claimed requirement is satisfied by all TOE components, by applicable TOE components that perform the relevant function, by at least one TOE component, by the TOE as a whole, or by an allowed operational environment dependency. +
This PP includes platform-specific EAs for the below-listed operating system platforms. For "bare-metal" applications, applications that run on other OS platforms, and applications that run in software-based execution environments, diff --git a/cPP/v2/input/cc.xml b/Archive/cPP/v2/input/cc.xml similarity index 100% rename from cPP/v2/input/cc.xml rename to Archive/cPP/v2/input/cc.xml diff --git a/cPP/v2/input/esr.xml b/Archive/cPP/v2/input/esr.xml similarity index 100% rename from cPP/v2/input/esr.xml rename to Archive/cPP/v2/input/esr.xml diff --git a/cPP/v2/input/tds/README.md b/Archive/cPP/v2/input/tds/README.md similarity index 100% rename from cPP/v2/input/tds/README.md rename to Archive/cPP/v2/input/tds/README.md diff --git a/cPP/v2/output/images/appdiagram.png b/Archive/cPP/v2/output/images/appdiagram.png similarity index 100% rename from cPP/v2/output/images/appdiagram.png rename to Archive/cPP/v2/output/images/appdiagram.png diff --git a/cPP/v2/output/images/cclogo.png b/Archive/cPP/v2/output/images/cclogo.png similarity index 100% rename from cPP/v2/output/images/cclogo.png rename to Archive/cPP/v2/output/images/cclogo.png diff --git a/cPP/v2/output/images/collapsed.png b/Archive/cPP/v2/output/images/collapsed.png similarity index 100% rename from cPP/v2/output/images/collapsed.png rename to Archive/cPP/v2/output/images/collapsed.png diff --git a/cPP/v2/output/images/expanded.png b/Archive/cPP/v2/output/images/expanded.png similarity index 100% rename from cPP/v2/output/images/expanded.png rename to Archive/cPP/v2/output/images/expanded.png diff --git a/cPP/v2/output/images/niaplogo.png b/Archive/cPP/v2/output/images/niaplogo.png similarity index 100% rename from cPP/v2/output/images/niaplogo.png rename to Archive/cPP/v2/output/images/niaplogo.png diff --git a/cPP/v2/output/images/niaplogodraft.png b/Archive/cPP/v2/output/images/niaplogodraft.png similarity index 100% rename from cPP/v2/output/images/niaplogodraft.png rename to Archive/cPP/v2/output/images/niaplogodraft.png diff --git a/cPP/v2/output/images/toe.png b/Archive/cPP/v2/output/images/toe.png similarity index 100% rename from cPP/v2/output/images/toe.png rename to Archive/cPP/v2/output/images/toe.png diff --git a/cPP/v2/output/images/toeruntime.png b/Archive/cPP/v2/output/images/toeruntime.png similarity index 100% rename from cPP/v2/output/images/toeruntime.png rename to Archive/cPP/v2/output/images/toeruntime.png diff --git a/cPP/v2/transforms/.gitignore b/Archive/cPP/v2/transforms/.gitignore similarity index 100% rename from cPP/v2/transforms/.gitignore rename to Archive/cPP/v2/transforms/.gitignore diff --git a/cPP/v2/transforms/ConfigAnnex.make b/Archive/cPP/v2/transforms/ConfigAnnex.make similarity index 100% rename from cPP/v2/transforms/ConfigAnnex.make rename to Archive/cPP/v2/transforms/ConfigAnnex.make diff --git a/cPP/v2/transforms/Helper.make b/Archive/cPP/v2/transforms/Helper.make similarity index 100% rename from cPP/v2/transforms/Helper.make rename to Archive/cPP/v2/transforms/Helper.make diff --git a/cPP/v2/transforms/LICENSE b/Archive/cPP/v2/transforms/LICENSE similarity index 100% rename from cPP/v2/transforms/LICENSE rename to Archive/cPP/v2/transforms/LICENSE diff --git a/cPP/v2/transforms/Makefile b/Archive/cPP/v2/transforms/Makefile similarity index 100% rename from cPP/v2/transforms/Makefile rename to Archive/cPP/v2/transforms/Makefile diff --git a/cPP/v2/transforms/README.md b/Archive/cPP/v2/transforms/README.md similarity index 100% rename from cPP/v2/transforms/README.md rename to Archive/cPP/v2/transforms/README.md diff --git a/cPP/v2/transforms/cPP.make b/Archive/cPP/v2/transforms/cPP.make similarity index 100% rename from cPP/v2/transforms/cPP.make rename to Archive/cPP/v2/transforms/cPP.make diff --git a/cPP/v2/transforms/dictionaries/CommonCriteria.txt b/Archive/cPP/v2/transforms/dictionaries/CommonCriteria.txt similarity index 100% rename from cPP/v2/transforms/dictionaries/CommonCriteria.txt rename to Archive/cPP/v2/transforms/dictionaries/CommonCriteria.txt diff --git a/cPP/v2/transforms/dictionaries/Computer.txt b/Archive/cPP/v2/transforms/dictionaries/Computer.txt similarity index 100% rename from cPP/v2/transforms/dictionaries/Computer.txt rename to Archive/cPP/v2/transforms/dictionaries/Computer.txt diff --git a/cPP/v2/transforms/dictionaries/Crypto.txt b/Archive/cPP/v2/transforms/dictionaries/Crypto.txt similarity index 100% rename from cPP/v2/transforms/dictionaries/Crypto.txt rename to Archive/cPP/v2/transforms/dictionaries/Crypto.txt diff --git a/cPP/v2/transforms/module/Module.make b/Archive/cPP/v2/transforms/module/Module.make similarity index 100% rename from cPP/v2/transforms/module/Module.make rename to Archive/cPP/v2/transforms/module/Module.make diff --git a/cPP/v2/transforms/package/Package.make b/Archive/cPP/v2/transforms/package/Package.make similarity index 100% rename from cPP/v2/transforms/package/Package.make rename to Archive/cPP/v2/transforms/package/Package.make diff --git a/cPP/v2/transforms/py/anchorize-periods.py b/Archive/cPP/v2/transforms/py/anchorize-periods.py similarity index 100% rename from cPP/v2/transforms/py/anchorize-periods.py rename to Archive/cPP/v2/transforms/py/anchorize-periods.py diff --git a/cPP/v2/transforms/py/bp-documentor.py b/Archive/cPP/v2/transforms/py/bp-documentor.py similarity index 100% rename from cPP/v2/transforms/py/bp-documentor.py rename to Archive/cPP/v2/transforms/py/bp-documentor.py diff --git a/cPP/v2/transforms/py/cc_apply_tds.py b/Archive/cPP/v2/transforms/py/cc_apply_tds.py similarity index 100% rename from cPP/v2/transforms/py/cc_apply_tds.py rename to Archive/cPP/v2/transforms/py/cc_apply_tds.py diff --git a/cPP/v2/transforms/py/get_spell_allowlist.py b/Archive/cPP/v2/transforms/py/get_spell_allowlist.py similarity index 100% rename from cPP/v2/transforms/py/get_spell_allowlist.py rename to Archive/cPP/v2/transforms/py/get_spell_allowlist.py diff --git a/cPP/v2/transforms/py/post-process.py b/Archive/cPP/v2/transforms/py/post-process.py similarity index 100% rename from cPP/v2/transforms/py/post-process.py rename to Archive/cPP/v2/transforms/py/post-process.py diff --git a/cPP/v2/transforms/py/retrieve-included-docs.py b/Archive/cPP/v2/transforms/py/retrieve-included-docs.py similarity index 100% rename from cPP/v2/transforms/py/retrieve-included-docs.py rename to Archive/cPP/v2/transforms/py/retrieve-included-docs.py diff --git a/cPP/v2/transforms/py/show_xpath.py b/Archive/cPP/v2/transforms/py/show_xpath.py similarity index 100% rename from cPP/v2/transforms/py/show_xpath.py rename to Archive/cPP/v2/transforms/py/show_xpath.py diff --git a/cPP/v2/transforms/schemas/CCModule.rng b/Archive/cPP/v2/transforms/schemas/CCModule.rng similarity index 100% rename from cPP/v2/transforms/schemas/CCModule.rng rename to Archive/cPP/v2/transforms/schemas/CCModule.rng diff --git a/cPP/v2/transforms/schemas/CCPackage.rng b/Archive/cPP/v2/transforms/schemas/CCPackage.rng similarity index 100% rename from cPP/v2/transforms/schemas/CCPackage.rng rename to Archive/cPP/v2/transforms/schemas/CCPackage.rng diff --git a/cPP/v2/transforms/schemas/CCProtectionProfile.rng b/Archive/cPP/v2/transforms/schemas/CCProtectionProfile.rng similarity index 100% rename from cPP/v2/transforms/schemas/CCProtectionProfile.rng rename to Archive/cPP/v2/transforms/schemas/CCProtectionProfile.rng diff --git a/cPP/v2/transforms/schemas/Commons.rng b/Archive/cPP/v2/transforms/schemas/Commons.rng similarity index 100% rename from cPP/v2/transforms/schemas/Commons.rng rename to Archive/cPP/v2/transforms/schemas/Commons.rng diff --git a/cPP/v2/transforms/schemas/ConfigAnnex.rng b/Archive/cPP/v2/transforms/schemas/ConfigAnnex.rng similarity index 100% rename from cPP/v2/transforms/schemas/ConfigAnnex.rng rename to Archive/cPP/v2/transforms/schemas/ConfigAnnex.rng diff --git a/cPP/v2/transforms/schemas/LaxProtectionProfile.rng b/Archive/cPP/v2/transforms/schemas/LaxProtectionProfile.rng similarity index 100% rename from cPP/v2/transforms/schemas/LaxProtectionProfile.rng rename to Archive/cPP/v2/transforms/schemas/LaxProtectionProfile.rng diff --git a/cPP/v2/transforms/schemas/Makefile b/Archive/cPP/v2/transforms/schemas/Makefile similarity index 100% rename from cPP/v2/transforms/schemas/Makefile rename to Archive/cPP/v2/transforms/schemas/Makefile diff --git a/cPP/v2/transforms/schemas/SecurityTarget.rng b/Archive/cPP/v2/transforms/schemas/SecurityTarget.rng similarity index 100% rename from cPP/v2/transforms/schemas/SecurityTarget.rng rename to Archive/cPP/v2/transforms/schemas/SecurityTarget.rng diff --git a/cPP/v2/transforms/schemas/Selection.rng b/Archive/cPP/v2/transforms/schemas/Selection.rng similarity index 100% rename from cPP/v2/transforms/schemas/Selection.rng rename to Archive/cPP/v2/transforms/schemas/Selection.rng diff --git a/cPP/v2/transforms/schemas/StrictCommons.rng b/Archive/cPP/v2/transforms/schemas/StrictCommons.rng similarity index 100% rename from cPP/v2/transforms/schemas/StrictCommons.rng rename to Archive/cPP/v2/transforms/schemas/StrictCommons.rng diff --git a/cPP/v2/transforms/schemas/TechnicalDecisions.rng b/Archive/cPP/v2/transforms/schemas/TechnicalDecisions.rng similarity index 100% rename from cPP/v2/transforms/schemas/TechnicalDecisions.rng rename to Archive/cPP/v2/transforms/schemas/TechnicalDecisions.rng diff --git a/cPP/v2/transforms/schemas/rng-to-html/bin/rng-resolve-includes.py b/Archive/cPP/v2/transforms/schemas/rng-to-html/bin/rng-resolve-includes.py similarity index 100% rename from cPP/v2/transforms/schemas/rng-to-html/bin/rng-resolve-includes.py rename to Archive/cPP/v2/transforms/schemas/rng-to-html/bin/rng-resolve-includes.py diff --git a/cPP/v2/transforms/schemas/rng-to-html/bin/rng-to-html b/Archive/cPP/v2/transforms/schemas/rng-to-html/bin/rng-to-html similarity index 100% rename from cPP/v2/transforms/schemas/rng-to-html/bin/rng-to-html rename to Archive/cPP/v2/transforms/schemas/rng-to-html/bin/rng-to-html diff --git a/cPP/v2/transforms/schemas/rng-to-html/lib/RngToHtml.xsl b/Archive/cPP/v2/transforms/schemas/rng-to-html/lib/RngToHtml.xsl similarity index 100% rename from cPP/v2/transforms/schemas/rng-to-html/lib/RngToHtml.xsl rename to Archive/cPP/v2/transforms/schemas/rng-to-html/lib/RngToHtml.xsl diff --git a/cPP/v2/transforms/xsl/SFRs.xml b/Archive/cPP/v2/transforms/xsl/SFRs.xml similarity index 100% rename from cPP/v2/transforms/xsl/SFRs.xml rename to Archive/cPP/v2/transforms/xsl/SFRs.xml diff --git a/cPP/v2/transforms/xsl/add-element-index-as-comments.xsl b/Archive/cPP/v2/transforms/xsl/add-element-index-as-comments.xsl similarity index 100% rename from cPP/v2/transforms/xsl/add-element-index-as-comments.xsl rename to Archive/cPP/v2/transforms/xsl/add-element-index-as-comments.xsl diff --git a/cPP/v2/transforms/xsl/audit.xsl b/Archive/cPP/v2/transforms/xsl/audit.xsl similarity index 100% rename from cPP/v2/transforms/xsl/audit.xsl rename to Archive/cPP/v2/transforms/xsl/audit.xsl diff --git a/cPP/v2/transforms/xsl/boilerplates.xml b/Archive/cPP/v2/transforms/xsl/boilerplates.xml similarity index 100% rename from cPP/v2/transforms/xsl/boilerplates.xml rename to Archive/cPP/v2/transforms/xsl/boilerplates.xml diff --git a/cPP/v2/transforms/xsl/boilerplates.xsl b/Archive/cPP/v2/transforms/xsl/boilerplates.xsl similarity index 100% rename from cPP/v2/transforms/xsl/boilerplates.xsl rename to Archive/cPP/v2/transforms/xsl/boilerplates.xsl diff --git a/cPP/v2/transforms/xsl/comma-splitter.xsl b/Archive/cPP/v2/transforms/xsl/comma-splitter.xsl similarity index 100% rename from cPP/v2/transforms/xsl/comma-splitter.xsl rename to Archive/cPP/v2/transforms/xsl/comma-splitter.xsl diff --git a/cPP/v2/transforms/xsl/configannex2html.xsl b/Archive/cPP/v2/transforms/xsl/configannex2html.xsl similarity index 100% rename from cPP/v2/transforms/xsl/configannex2html.xsl rename to Archive/cPP/v2/transforms/xsl/configannex2html.xsl diff --git a/cPP/v2/transforms/xsl/css-content.xsl b/Archive/cPP/v2/transforms/xsl/css-content.xsl similarity index 100% rename from cPP/v2/transforms/xsl/css-content.xsl rename to Archive/cPP/v2/transforms/xsl/css-content.xsl diff --git a/cPP/v2/transforms/xsl/debug.xsl b/Archive/cPP/v2/transforms/xsl/debug.xsl similarity index 100% rename from cPP/v2/transforms/xsl/debug.xsl rename to Archive/cPP/v2/transforms/xsl/debug.xsl diff --git a/cPP/v2/transforms/xsl/esr2html.xsl b/Archive/cPP/v2/transforms/xsl/esr2html.xsl similarity index 100% rename from cPP/v2/transforms/xsl/esr2html.xsl rename to Archive/cPP/v2/transforms/xsl/esr2html.xsl diff --git a/cPP/v2/transforms/xsl/ext-comp-defs.xsl b/Archive/cPP/v2/transforms/xsl/ext-comp-defs.xsl similarity index 100% rename from cPP/v2/transforms/xsl/ext-comp-defs.xsl rename to Archive/cPP/v2/transforms/xsl/ext-comp-defs.xsl diff --git a/cPP/v2/transforms/xsl/functions.xsl b/Archive/cPP/v2/transforms/xsl/functions.xsl similarity index 100% rename from cPP/v2/transforms/xsl/functions.xsl rename to Archive/cPP/v2/transforms/xsl/functions.xsl diff --git a/cPP/v2/transforms/xsl/js-content.xsl b/Archive/cPP/v2/transforms/xsl/js-content.xsl similarity index 100% rename from cPP/v2/transforms/xsl/js-content.xsl rename to Archive/cPP/v2/transforms/xsl/js-content.xsl diff --git a/cPP/v2/transforms/xsl/make-ref.xsl b/Archive/cPP/v2/transforms/xsl/make-ref.xsl similarity index 100% rename from cPP/v2/transforms/xsl/make-ref.xsl rename to Archive/cPP/v2/transforms/xsl/make-ref.xsl diff --git a/cPP/v2/transforms/xsl/module-commons.xsl b/Archive/cPP/v2/transforms/xsl/module-commons.xsl similarity index 100% rename from cPP/v2/transforms/xsl/module-commons.xsl rename to Archive/cPP/v2/transforms/xsl/module-commons.xsl diff --git a/cPP/v2/transforms/xsl/module2html.xsl b/Archive/cPP/v2/transforms/xsl/module2html.xsl similarity index 100% rename from cPP/v2/transforms/xsl/module2html.xsl rename to Archive/cPP/v2/transforms/xsl/module2html.xsl diff --git a/cPP/v2/transforms/xsl/module2sd.xsl b/Archive/cPP/v2/transforms/xsl/module2sd.xsl similarity index 100% rename from cPP/v2/transforms/xsl/module2sd.xsl rename to Archive/cPP/v2/transforms/xsl/module2sd.xsl diff --git a/cPP/v2/transforms/xsl/pp2html.xsl b/Archive/cPP/v2/transforms/xsl/pp2html.xsl similarity index 100% rename from cPP/v2/transforms/xsl/pp2html.xsl rename to Archive/cPP/v2/transforms/xsl/pp2html.xsl diff --git a/cPP/v2/transforms/xsl/pp2simplified.xsl b/Archive/cPP/v2/transforms/xsl/pp2simplified.xsl similarity index 100% rename from cPP/v2/transforms/xsl/pp2simplified.xsl rename to Archive/cPP/v2/transforms/xsl/pp2simplified.xsl diff --git a/cPP/v2/transforms/xsl/pp2table.xsl b/Archive/cPP/v2/transforms/xsl/pp2table.xsl similarity index 100% rename from cPP/v2/transforms/xsl/pp2table.xsl rename to Archive/cPP/v2/transforms/xsl/pp2table.xsl diff --git a/cPP/v2/transforms/xsl/ppcommons.xsl b/Archive/cPP/v2/transforms/xsl/ppcommons.xsl similarity index 100% rename from cPP/v2/transforms/xsl/ppcommons.xsl rename to Archive/cPP/v2/transforms/xsl/ppcommons.xsl diff --git a/cPP/v2/transforms/xsl/sanity_checks.xsl b/Archive/cPP/v2/transforms/xsl/sanity_checks.xsl similarity index 100% rename from cPP/v2/transforms/xsl/sanity_checks.xsl rename to Archive/cPP/v2/transforms/xsl/sanity_checks.xsl diff --git a/cPP/v2/transforms/xsl/use-case.xsl b/Archive/cPP/v2/transforms/xsl/use-case.xsl similarity index 100% rename from cPP/v2/transforms/xsl/use-case.xsl rename to Archive/cPP/v2/transforms/xsl/use-case.xsl diff --git a/Dictionary.txt b/Dictionary.txt new file mode 100644 index 0000000..d97de56 --- /dev/null +++ b/Dictionary.txt @@ -0,0 +1,178 @@ +10C +11C +131A +1C +1D +1E +2C +2D +2E +38A +38C +38D +38E +3C +3E +4C +56A +56B +57A +5C +6C +7C +8C +90A +90B +9C +AAD +ANO +ASE +AndroidManifest +AppArmor +AppContainer +AppPP +ApplicationSettings +AppxManifest +Authenticode +BCryptGenRandom +BinScope +BinSkim +BitLocker +CAVP +CC2022 +CCEVS +CCTL +CEM +CFG +CNSA +CoreOS +CryptGenRandom +DataStore +DCCP +DoD +EAF +ECB +EFS +EKU +enquiries +EXE +eXtended +evaluatorโ€™s +Electrotechnical +FIA +ffdhe +ffdhe3072 +FPR +FPT +FSP +H5 +H10 +H15 +H25 +href +IAF +IDV +ISV +IUT +IsolatedStorage +IsolatedStorageSettings +KAT +KATs +KDF +KeyStores +Latice +LMS +M24 +M32 +MACTag +MACed +MACs +MACtag +Merkle +Micali +MEC +MEDIALIB +MacKey +MacTag +NSAllowsArbitraryLoads +NSExceptionAllowsInsecureHTTPLoads +NVLAP +NXCheck +o365 +OSP +OSPs +OtherInfo +partiesโ€™ +PBKDF +PBKDF2 +PreferenceActivity +PRF +PROT +PRT +PTR +ProcMon +ProtectData +QWORD +RBGs +RNGCryptoServiceProvider +RandomNumberGenerator +RangeChecking +RtlGenRandom +SCAP +SELinux +SHAVS +SKC +SMF +SP800 +STO +Sig +Silverlight +SharedPreferences +SoftwareIdentity +Solaris +Stateful +SysInternals +syslog +TDs +TSU +TUD +VMMap +VVoIP +Validator +WMAppManifest +X9 +XMSS +aspx +caSigning +cleartext +connectionless +decompilation +decompile +decompiled +decompiler +dtrace +exe +exploitations +iPhones +icacls +invocable +keyrings +macOS +microarchitecture +mmap +mov +mprotect +namespace +plist +rcx +rsp +sdk +strace +supersets +swidtag +uninstallation +v1 +validator +virtualized +xml +FFC diff --git a/LICENSE b/LICENSE index 6fc560f..a84c395 100644 --- a/LICENSE +++ b/LICENSE @@ -1,21 +1,25 @@ -MIT License +This is free and unencumbered software released into the public domain. -Copyright (c) 2019 itc-wgtools +Anyone is free to copy, modify, publish, use, compile, sell, or +distribute this software, either in source code form or as a compiled +binary, for any purpose, commercial or non-commercial, and by any +means. -Permission is hereby granted, free of charge, to any person obtaining a copy -of this software and associated documentation files (the "Software"), to deal -in the Software without restriction, including without limitation the rights -to use, copy, modify, merge, publish, distribute, sublicense, and/or sell -copies of the Software, and to permit persons to whom the Software is -furnished to do so, subject to the following conditions: +In jurisdictions that recognize copyright laws, the author or authors +of this software dedicate any and all copyright interest in the +software to the public domain. We make this dedication for the benefit +of the public at large and to the detriment of our heirs and +successors. We intend this dedication to be an overt act of +relinquishment in perpetuity of all present and future rights to this +software under copyright law. -The above copyright notice and this permission notice shall be included in all -copies or substantial portions of the Software. +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, +EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. +IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR +OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, +ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR +OTHER DEALINGS IN THE SOFTWARE. + +For more information, please refer to -THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR -IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, -FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE -AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER -LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, -OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE -SOFTWARE. diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..180dc98 --- /dev/null +++ b/Makefile @@ -0,0 +1,14 @@ +BASE=application +DIFF_TAGS=v1.4 +TRANS?=transforms + +# Let user's include their own makefiles (if they exist) +-include User.make +-include ~/commoncriteria/User.make +include $(TRANS)/Helper.make + +#APP_RECIPROCITY_WORKSHEET=$(OUT)/application-vetting-report-sample.html +#all: $(APP_RECIPROCITY_WORKSHEET) +#$(APP_RECIPROCITY_WORKSHEET): schema/results2vettingreport.xsl schema/results-example.xml +# xsltproc -o $(APP_RECIPROCITY_WORKSHEET) schema/results2vettingreport.xsl schema/results-example.xml + diff --git a/Modules/Agent/.gitignore b/Modules/Agent/.gitignore new file mode 100644 index 0000000..44c2625 --- /dev/null +++ b/Modules/Agent/.gitignore @@ -0,0 +1,10 @@ +output/*.* +output/css +output/js +*~ +input/*.html +input/schemas.xml +*.rnc +tmp +LocalUser.make +output/images/diff-*.gif diff --git a/Modules/Agent/Dictionary.txt b/Modules/Agent/Dictionary.txt new file mode 100644 index 0000000..b93e11e --- /dev/null +++ b/Modules/Agent/Dictionary.txt @@ -0,0 +1 @@ +Agent diff --git a/Modules/Agent/Makefile b/Modules/Agent/Makefile new file mode 100644 index 0000000..e58b690 --- /dev/null +++ b/Modules/Agent/Makefile @@ -0,0 +1,6 @@ +TRANS?=../../transforms + +# Let user's include their own makefiles (if they exist) +-include User.make +-include ~/commoncriteria/User.make +include $(TRANS)/module/Module.make diff --git a/Modules/Agent/appSW_PP_Config_ServerAgent.adoc b/Modules/Agent/appSW_PP_Config_ServerAgent.adoc deleted file mode 100644 index 0220cfc..0000000 --- a/Modules/Agent/appSW_PP_Config_ServerAgent.adoc +++ /dev/null @@ -1,109 +0,0 @@ -= PP-Configuration for Enterprise Server Applications and Client Agent(s) -:showtitle: -:toc: -:table-caption: Table -:icons: font -:revnumber: 1.0e -:revdate: 2024-02-15 - -:iTC-longname: iTC for Application Software -:iTC-shortname: AppSW-iTC -:iTC-email: cm-itc-mailing-list@gmail.com -:iTC-website: https://appswcpp.github.io/ -:iTC-GitHub: https://github.com/appswcpp/repository/ - -:sectnums!: -== Acknowledgements - -This PP-Configuration was developed by the {iTC-longname} international Technical Community (iTC) also known as {iTC-shortname} with representatives from Industry, Government agencies, Common Criteria Test Laboratories, and members of academia. - -=== Revision History - -.Revision history -[%header,cols="1,2,4"] -|=== -|Version -|Date -|Description - -|1.0 -|2022-04-06 -|Initial Release - -|1.0e -|2024-02-15 -|Incorporated feedback received following initial release. - - -|=== - -:sectnums: -== Introduction - -=== PP-Configuration Overview -The purpose of a PP-Configuration is to combine Protection Profiles (PPs) and PP-Modules for various technology types into a single configuration that can be evaluated as a whole. - -This PP-Configuration is for enterprise server applications and their client agent(s). - -=== PP-Configuration Reference - -This PP-Configuration is identified as follows: - -* PP-Configuration for Enterprise Server Applications and Client Agent(s), Version {revnumber}, {revdate} -* As a shorthand reference, it can be identified as "CFG_APP-Server-Agent_V{revnumber}"" - -=== PP-Configuration Components - -This PP-Configuration includes the following components: - -.PP-Configuration Components -[cols="1,3"] -|=== -|[base PP] -|cPP_APP_SW_V1.1 - -|[PP-Module 1] -|MOD_Server_v1.1 - -|[PP-Module 2] -|MOD_Agent_v1.1 - -|=== - -== Conformance Claims - -=== CC Statement - -To be conformant to this PP-Configuration, an ST must demonstrate Exact Conformance, as defined by the CC and CEM addenda for Exact Conformance, Selection-Based SFRs, and Optional SFRs. - -=== CC Conformance Claims - -This PP-Configuration, and its components specified in section 1.3, are conformant to Parts 2 (extended) and 3 (conformant) of Common Criteria Version 3.1, Release 5 [CC]. - -== SAR Statement - -The set of SARs specified for this PP-Configuration are taken from, and identical to, those specified in the base PP. - -=== Related Documents - -**Common Criteria**footnote:[For details see http://www.commoncriteriaportal.org/] - -.Common Criteria References -[cols="1,3",] -|=== -|[#CC1]#[CC1]# |Common Criteria for Information Technology Security Evaluation, + -Part 1: Introduction and General Model, + -CCMB-2017-04-001, Version 3.1 Revision 5, April 2017. -|[#CC2]#[CC2]# |Common Criteria for Information Technology Security Evaluation, + -Part 2: Security Functional Components, + -CCMB-2017-04-002, Version 3.1 Revision 5, April 2017. -|[#CC3]#[CC3]# |Common Criteria for Information Technology Security Evaluation, + -Part 3: Security Assurance Components, + -CCMB-2017-04-003, Version 3.1 Revision 5, April 2017. -|[#CEM]#[CEM]# |Common Methodology for Information Technology Security Evaluation, + -Evaluation Methodology, + -CCMB-2017-04-004, Version 3.1 Revision 5, April 2017. -|[#addenda]#[addenda]# |CC and CEM addenda, + -Exact Conformance, Selection-Based SFRs, Optional SFRs, + -Version 0.5, May 2017. -|=== diff --git a/Modules/Agent/input/.gitignore b/Modules/Agent/input/.gitignore new file mode 100644 index 0000000..329ef01 --- /dev/null +++ b/Modules/Agent/input/.gitignore @@ -0,0 +1,2 @@ +*.html +schemas.xml diff --git a/Modules/Agent/input/tds/README.md b/Modules/Agent/input/tds/README.md new file mode 100644 index 0000000..9d19f35 --- /dev/null +++ b/Modules/Agent/input/tds/README.md @@ -0,0 +1,4 @@ +# Technical Decisions + +Place TD XML files in this directory for the Agent PP-Module. +On the main development branch, TDs should be incorporated into the module XML directly. diff --git a/Modules/Agent/output/images/cclogo.png b/Modules/Agent/output/images/cclogo.png new file mode 100644 index 0000000..8464869 Binary files /dev/null and b/Modules/Agent/output/images/cclogo.png differ diff --git a/Modules/Agent/output/images/niaplogo.png b/Modules/Agent/output/images/niaplogo.png new file mode 100644 index 0000000..2de1b05 Binary files /dev/null and b/Modules/Agent/output/images/niaplogo.png differ diff --git a/Modules/Server/.gitignore b/Modules/Server/.gitignore new file mode 100644 index 0000000..44c2625 --- /dev/null +++ b/Modules/Server/.gitignore @@ -0,0 +1,10 @@ +output/*.* +output/css +output/js +*~ +input/*.html +input/schemas.xml +*.rnc +tmp +LocalUser.make +output/images/diff-*.gif diff --git a/Modules/Server/Dictionary.txt b/Modules/Server/Dictionary.txt new file mode 100644 index 0000000..8d31306 --- /dev/null +++ b/Modules/Server/Dictionary.txt @@ -0,0 +1 @@ +Server diff --git a/Modules/Server/Makefile b/Modules/Server/Makefile new file mode 100644 index 0000000..e58b690 --- /dev/null +++ b/Modules/Server/Makefile @@ -0,0 +1,6 @@ +TRANS?=../../transforms + +# Let user's include their own makefiles (if they exist) +-include User.make +-include ~/commoncriteria/User.make +include $(TRANS)/module/Module.make diff --git a/Modules/Server/input/.gitignore b/Modules/Server/input/.gitignore new file mode 100644 index 0000000..329ef01 --- /dev/null +++ b/Modules/Server/input/.gitignore @@ -0,0 +1,2 @@ +*.html +schemas.xml diff --git a/Modules/Server/input/tds/README.md b/Modules/Server/input/tds/README.md new file mode 100644 index 0000000..5701d72 --- /dev/null +++ b/Modules/Server/input/tds/README.md @@ -0,0 +1,4 @@ +# Technical Decisions + +Place TD XML files in this directory for the Server PP-Module. +On the main development branch, TDs should be incorporated into the module XML directly. diff --git a/Modules/Server/output/images/cclogo.png b/Modules/Server/output/images/cclogo.png new file mode 100644 index 0000000..8464869 Binary files /dev/null and b/Modules/Server/output/images/cclogo.png differ diff --git a/Modules/Server/output/images/niaplogo.png b/Modules/Server/output/images/niaplogo.png new file mode 100644 index 0000000..2de1b05 Binary files /dev/null and b/Modules/Server/output/images/niaplogo.png differ diff --git a/README.md b/README.md new file mode 100644 index 0000000..abf07a3 --- /dev/null +++ b/README.md @@ -0,0 +1,62 @@ +# collaborative Protection Profile for Application Software + +[![Build](https://github.com/appswcpp/repository/actions/workflows/quick_build.yml/badge.svg)](https://github.com/appswcpp/repository/actions/workflows/quick_build.yml) +[![GitHub issues](https://img.shields.io/github/issues/appswcpp/repository.svg?maxAge=2592000)](https://github.com/appswcpp/repository/issues) + +This repository hosts the collaborative Protection Profile (cPP) for Application Software, maintained by the Application Software international Technical Community (AppSW-iTC). + +## Draft Version + +- [collaborative Protection Profile for Application Software](https://appswcpp.github.io/repository/Version-2/application-release.html) (HTML) + +## Archived Versions + +The previous version (v1.0e) of the cPP, Supporting Document, and PP-Modules (Agent and Server) are available in the [Archive](Archive/) directory. + +## PP-Modules + +The following PP-Modules extend the base cPP: + +- **Agent** โ€” PP-Module for Application Software Agent (`Modules/Agent/`) + - [PP-Module for Agent](https://appswcpp.github.io/repository/Version-2/Modules/Agent/Agent-release.html) (HTML) + - [SD for Agent](https://appswcpp.github.io/repository/Version-2/Modules/Agent/Agent-sd.html) (HTML) +- **Server** โ€” PP-Module for Application Software Server (`Modules/Server/`) + - [PP-Module for Server](https://appswcpp.github.io/repository/Version-2/Modules/Server/Server-release.html) (HTML) + - [SD for Server](https://appswcpp.github.io/repository/Version-2/Modules/Server/Server-sd.html) (HTML) + +## Quickstart + +Clone with the transforms submodule: + +``` +git clone --recursive git@github.com:appswcpp/repository.git +``` + +Update the transforms submodule: + +``` +git submodule update --remote transforms +git add transforms +git commit +``` + +## Repository Content + +| Directory | Description | +|-----------|-------------| +| `input/` | Source XML content that gets transformed to HTML | +| `output/` | Generated HTML output | +| `transforms/` | Shared Common Criteria build transforms (submodule) | +| `Modules/` | PP-Module directories (Agent, Server) | +| `Archive/` | Previous version (v1.0e) of the cPP, SD, and PP-Modules | +| `.templates/` | Document authoring templates | + +## Links + +- [AppSW-iTC Website](https://appswcpp.github.io/) +- [National Information Assurance Partnership (NIAP)](https://www.niap-ccevs.org/) +- [Common Criteria Portal](https://www.commoncriteriaportal.org/) + +## License + +See [LICENSE](LICENSE) diff --git a/Readme.adoc b/Readme.adoc new file mode 100644 index 0000000..1f2af98 --- /dev/null +++ b/Readme.adoc @@ -0,0 +1,107 @@ +== collaborative Protection Profile for Application Software + +[cols="1,1,1,1,1,1,1,1"] +|=== +8+|repository +| https://github.com/appswcpp/repository/tree/Version-2[Version-2] +a| https://appswcpp.github.io/repository/Version-2/application-release.html[๐Ÿ“„] +a|[link=https://github.com/appswcpp/repository/blob/gh-pages/Version-2/ValidationReport.txt] +image::https://raw.githubusercontent.com/appswcpp/repository/gh-pages/Version-2/validation.svg[Validation] +a|[link=https://github.com/appswcpp/repository/blob/gh-pages/Version-2/SanityChecksOutput.md] +image::https://raw.githubusercontent.com/appswcpp/repository/gh-pages/Version-2/warnings.svg[SanityChecks] +a|[link=https://github.com/appswcpp/repository/blob/gh-pages/Version-2/SpellCheckReport.txt] +image::https://raw.githubusercontent.com/appswcpp/repository/gh-pages/Version-2/spell-badge.svg[SpellCheck] +a|[link=https://github.com/appswcpp/repository/blob/gh-pages/Version-2/TDValidationReport.txt] +image::https://raw.githubusercontent.com/appswcpp/repository/gh-pages/Version-2/tds.svg[TDs] +a|image::https://raw.githubusercontent.com/appswcpp/repository/gh-pages/Version-2/transforms.svg[transforms,150] +a| [link=https://github.com/appswcpp/repository/blob/gh-pages/Version-2/HTMLs.adoc] +image::https://raw.githubusercontent.com/appswcpp/repository/gh-pages/Version-2/html_count.svg[HTML Count] +[link=https://github.com/appswcpp/repository/blob/gh-pages/Version-2/PDFs.adoc] +image::https://raw.githubusercontent.com/appswcpp/repository/gh-pages/Version-2/pdf_count.svg[PDF Count] +|=== + +https://github.com/appswcpp/repository/issues[image:https://img.shields.io/github/issues/appswcpp/repository.svg?maxAge=2592000[GitHub +issues Open]] + +This repository hosts the draft version of the collaborative Protection Profile for +Application Software developed by the AppSW-iTC. This +repository is used to facilitate collaboration and development on the +draft document. See the link:#Release-Version[release] section if you +are looking for the officially released version for evaluations. + +=== Draft Version + +* https://appswcpp.github.io/repository/Version-2/application-release.html[collaborative +Protection Profile for Application Software] (html) + +=== PP-Modules + +==== Agent PP-Module +* https://appswcpp.github.io/repository/Version-2/Modules/Agent/Agent-release.html[PP-Module for Application Software Agent] (html) +* https://appswcpp.github.io/repository/Version-2/Modules/Agent/Agent-sd.html[Supporting Document for Agent PP-Module] (html) + +==== Server PP-Module +* https://appswcpp.github.io/repository/Version-2/Modules/Server/Server-release.html[PP-Module for Application Software Server] (html) +* https://appswcpp.github.io/repository/Version-2/Modules/Server/Server-sd.html[Supporting Document for Server PP-Module] (html) + +=== Previous Versions (Archived) + +The previous version (v1.0e) of the cPP, Supporting Document, and PP-Modules +(Agent and Server) are available in the link:Archive/[Archive] directory. + +=== Contributing + +If you are interested in contributing directly to future versions of +this collaborative Protection Profile, please consider joining the +AppSW-iTC. Visit https://appswcpp.github.io/ for more information. + +=== Feedback + +Questions, comments, and fixes can be submitted to the +https://github.com/appswcpp/repository/issues[repository issue +tracker] + +=== Quickstart + +To clone this project along with its _transforms_ submodule run: + +.... + git clone --recursive git@github.com:appswcpp/repository.git +.... + +To pull updates from the upstream _transforms_ submodule and commit them +run: + +.... + git submodule update --remote transforms + git add transforms + git commit +.... + +==== Development Info + +* https://github.com/commoncriteria/transforms/wiki/Working-with-Transforms-as-a-Submodule[Help +working with Transforms Submodule] + +=== Repository Content + +* input - Contains the `meat' of the project. It's the input content (in +XML form) that gets transformed to readable html. +* output - The output directory where the html is placed after +transformation. +* output/images - The directory where images are stored +* transforms - Points to the transform subproject which is really a +repository for resources shared amongst many Common Criteria projects. +* Archive - Contains the previous version (v1.0e) of the cPP, SD, and PP-Modules. +* Modules - PP-Module directories (Agent, Server) for future XML-based builds. + +=== Links + +* https://appswcpp.github.io/[AppSW-iTC Website] +* https://www.niap-ccevs.org/[National Information Assurance Partnership +(NIAP)] +* https://www.commoncriteriaportal.org/[Common Criteria Portal] + +=== License + +See link:./LICENSE[License] diff --git a/draft_review/2026-05-13_iTC_review/PP-Configuration-Server-Agent-v2.0-draft-review.pdf b/draft_review/2026-05-13_iTC_review/PP-Configuration-Server-Agent-v2.0-draft-review.pdf new file mode 100644 index 0000000..132e783 Binary files /dev/null and b/draft_review/2026-05-13_iTC_review/PP-Configuration-Server-Agent-v2.0-draft-review.pdf differ diff --git a/draft_review/2026-05-13_iTC_review/PP-Configuration-Server-v2.0-draft-review.pdf b/draft_review/2026-05-13_iTC_review/PP-Configuration-Server-v2.0-draft-review.pdf new file mode 100644 index 0000000..add015e Binary files /dev/null and b/draft_review/2026-05-13_iTC_review/PP-Configuration-Server-v2.0-draft-review.pdf differ diff --git a/draft_review/2026-05-13_iTC_review/PP-Module-Agent-v2.0-draft-review.pdf b/draft_review/2026-05-13_iTC_review/PP-Module-Agent-v2.0-draft-review.pdf new file mode 100644 index 0000000..9687db1 Binary files /dev/null and b/draft_review/2026-05-13_iTC_review/PP-Module-Agent-v2.0-draft-review.pdf differ diff --git a/draft_review/2026-05-13_iTC_review/PP-Module-Server-v2.0-draft-review.pdf b/draft_review/2026-05-13_iTC_review/PP-Module-Server-v2.0-draft-review.pdf new file mode 100644 index 0000000..5037115 Binary files /dev/null and b/draft_review/2026-05-13_iTC_review/PP-Module-Server-v2.0-draft-review.pdf differ diff --git a/draft_review/2026-05-13_iTC_review/cPP-Application-Software-v2.0-draft-review.pdf b/draft_review/2026-05-13_iTC_review/cPP-Application-Software-v2.0-draft-review.pdf new file mode 100644 index 0000000..03a7e92 Binary files /dev/null and b/draft_review/2026-05-13_iTC_review/cPP-Application-Software-v2.0-draft-review.pdf differ diff --git a/input/.gitignore b/input/.gitignore new file mode 100644 index 0000000..a7d52fd --- /dev/null +++ b/input/.gitignore @@ -0,0 +1,3 @@ +# files not to track in git +.DS_Store +schemas.xml diff --git a/input/application.xml b/input/application.xml new file mode 100644 index 0000000..1f8a0bb --- /dev/null +++ b/input/application.xml @@ -0,0 +1,2271 @@ + + + + + + + Collaborative Protection Profile for Application Software + 2.0 + Application Software International Technical Community (AppSW-iTC) + 2025-06-16 + application; software + + + + + v 1.0 + 2014-10-20 + Initial release + + + v 1.1 + 2014-11-05 + Addition to TLS cipher suite selections + + + v 1.2 + 2016-04-22 + Added server-side TLS requirements (selection-based)Multiple clarification based on NIAP TRRT inquiriesRefactored FDP_DEC_EXT.1 into separate components + + + v 1.3 + 2019-03-01 + Incorporated available Technical DecisionsRefactored FPT_TUDAdded a selection to FTP_DITMoved SWID Tags requirementLeveraged TLS PackageAdded equivalency section + + + v 1.4 + 2021-10-07 + Incorporated applicable Technical DecisionsUpdated to TLS FP + 2.1Incorporated SSH FP 2.0 + + + v 2.0 + 2025-06-16 + Rebaselined from the NIAP Protection Profile for Application Software, Version 2.0, as the source baseline rather than revising the prior collaborative Protection Profile for Application Software Version 1.4Converted to collaborative Protection Profile maintained by the Application Software International Technical Community (AppSW-iTC)CC:2022 conversionUpdating for TLS FP, SSH FP, and X.509 FPTDs and GitHub IssuesCNSA 2.0 updatesALC FLR Updates + + + + + https://github.com/commoncriteria/ssh + release-2.0 + + https://commoncriteria.github.io/ssh/release-2.0/ssh-release.html + + + + + https://github.com/commoncriteria/tls + release-2.1 + + https://commoncriteria.github.io/tls/release-2.1/tls-release.html + + + + + + + + https://github.com/commoncriteria/x509 + release-1.0 + + https://commoncriteria.github.io/x509/release-1.0/x509-release.html + + + + https://github.com/commoncriteria/vpnclient + release-3.0 + + https://commoncriteria.github.io/vpnclient/master/vpnclient.html + + + + + + + The scope of this Protection Profile (PP) is to describe the security functionality of application software in terms of and to define functional and assurance requirements for such software. In recent years, software attacks have shifted from targeting operating systems to targeting applications. This has been the natural response to improvements in operating system security and development processes. As a result, it is paramount that the security of applications be improved to reduce the risk of compromise. + + An anti-exploitation feature which loads memory mappings into unpredictable locations. ASLR makes it more difficult for an attacker to redirect control to code that they have introduced into the address space of an application process. + Software that runs on a platform and performs tasks on behalf of the user or owner of the platform, as well as its supporting documentation. The terms TOE and application are interchangeable in this document. + A specification of routines, data structures, object classes, and variables that allows an application to make use of services provided by another software component, such as a library. APIs are often provided for a set of libraries included with the platform. + Data that establishes the identity of a user, e.g. a cryptographic key or password. + An anti-exploitation feature of modern operating systems executing on modern computer hardware, which enforces a non-execute permission on pages of memory. DEP prevents pages of memory from containing both data and instructions, which makes it more difficult for an attacker to introduce and execute code. + An entity that writes application software. For the purposes of this document, vendors and developers are the same. + Software transmitted from a remote system for execution within a limited execution environment on the local system. Typically, there is no persistent installation and execution begins without the user's consent or even notification. Examples of mobile code technologies include JavaScript, Java applets, Adobe Flash, and Microsoft Silverlight. + Software that manages hardware resources and provides services for applications. + Any information about an individual maintained by an agency, including, but not limited to, education, financial transactions, medical history, and criminal or employment history and information which can be used to distinguish or trace an individual's identity, such as their name, social security number, date and place of birth, motherโ€™s maiden name, biometric records, etc., including any other personal information which is linked or linkable to an individual. + The environment in which application software runs. The platform can be an operating system, hardware environment, a software based execution environment, or some combination of these. These types of platforms may also run atop other platforms. + Sensitive data may include all user or enterprise data or may be specific application data such as emails, messaging, documents, calendar items, and contacts. Sensitive data must minimally include PII, credentials, and keys. Sensitive data shall be identified in the applicationโ€™s TSS by the ST author. + An anti-exploitation feature that places a value on the stack at the start of a function call, and checks that the value is the same at the end of the function call. This is also referred to as Stack Guard, or Stack Canaries. + An entity that sells application software. For purposes of this document, vendors and developers are the same. Vendors are responsible for maintaining and updating application software. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ The requirements in this document apply to application software which runs on any type of platform. Some application types are covered by more specific PPs, which may be expressed as PP-Modules of this PP. Such applications are subject to the requirements of both this PP and the PP-Module that addresses their special functionality. PPs for some particularly specialized applications may not be expressed as PP-Modules at this time, though the requirements in this document should be seen as objectives for those highly specialized applications.Although the requirements in this document apply to a wide range of application software, consult guidance from the relevant national schemes to determine when formal Common Criteria evaluation is expected for a particular type of application. This may vary depending upon the nature of the security functionality of the application. + The application, which consists of the software provided by its vendor, is installed onto the platform(s) it operates on. It executes on the platform, which may be an operating system (), hardware environment, a software based execution environment, or some combination of these (). Those platforms may themselves run within other environments, such as virtual machines or operating systems, that completely abstract away the underlying hardware from the application. The TOE is not accountable for security functionality that is implemented by platform layers that are abstracted away. Some evaluation activities are specific to the particular platform on which the application runs, in order to provide precision and repeatability. The only platforms currently recognized by this PP are those specified in SFR Evaluation Activities. To test on a platform for which there are no EAs, an interested party may contact the AppSW-iTC with proposed EAs. The AppSW-iTC will determine if the proposed platform is appropriate for the cPP and accept, reject, or develop EAs as necessary in coordination with the technical community.Applications include a diverse range of software such as office suites, thin clients, PDF readers, downloadable smartphone apps, and apps running in a cloud container. The TOE includes any software in the application installation package, even those pieces that may extend or modify the functionality of the underlying platform, such as kernel drivers. Many platforms come bundled with applications such as web browsers, email clients and media players and these too should be considered subject to the requirements defined in this document although the expectation of formal Common Criteria evaluation depends upon the national scheme. BIOS and other firmware, the operating system kernel, and other systems software (and drivers) provided as part of the platform are outside the scope of this document.
+
+ + + Requirements in this PP are designed to address the security problem in the following use cases. These use cases are intentionally very broad, as many specific use cases exist for application software. Many applications may be used in combinations of these broad use cases, and evaluation against PP-Modules of this PP, when available, may be most appropriate for some application types. + + + + The application allows a user to create content, saving it to either local or + remote storage. Example content includes text documents, presentations, and images. + + + + The application allows a user to consume content, retrieving it from either + local or remote storage. Example content includes web pages and video. + + + The application allows for communication interactively or + non-interactively with other users or applications over a communications channel. + Example communications include instant messages, email, and voice. + + + + +
+ A TOE may consist of multiple separately deployed application components that collectively provide the TOE security functionality. Examples include server-agent products, clustered application deployments, and microservices-based applications composed of multiple application payloads. If a TOE is distributed across multiple TOE components, the ST shall identify each TOE component, describe the role of each TOE component, identify which components implement each claimed SFR, describe all communications between TOE components, and distinguish TOE components from operational environment components. + For containerized or microservices TOEs, the TOE consists of the application payloads and TOE-provided application components identified in the ST. The container orchestration platform, container runtime, operating system, service mesh infrastructure, ingress infrastructure, cluster networking, and platform-provided secret or configuration stores are part of the operational environment unless explicitly included in the TOE boundary. The PP does not require these operational environment components to be included in the TOE boundary solely because the TOE depends on them for execution, scheduling, networking, isolation, credential storage, configuration storage, or time services. + When the TOE relies on operational environment components to provide services used by the TOE, the ST shall identify the dependency and the guidance shall describe the required environmental configuration. Inter-component communication between TOE parts shall be identified in the ST. Where the TOE claims conformance to a PP-Configuration that includes Server and Agent application modules, the ST shall use the module requirements to address authorization or registration of TOE components before communication is permitted and protection of security-relevant data transmitted between TOE components. The ST shall provide an SFR allocation rationale that identifies whether each claimed requirement is satisfied by all TOE components, by applicable TOE components that perform the relevant function, by at least one TOE component, by the TOE as a whole, or by an allowed operational environment dependency. +
+
+ This PP includes platform-specific EAs for the below-listed operating system platforms. For "bare-metal" applications, + applications that run on other OS platforms, and applications that run in software-based execution environments, + contact the Technical Community for guidance. + + Android: Mobile operating systems based on Google Android + Microsoft Windows: Microsoft Windows operating systems + Apple iOS and iPadOS: Apple's mobile operating system for iPhones and iPads + Linux: Linux-based operating systems other than Android + Oracle Solaris: Oracle's enterprise operating system + Apple macOS: Apple's operating system for Mac devices +
+ + + + exact + extended + extended + + + Protection Profile for Mobile Device Management, Version 5.0 + PP-Module for Email Clients, Version 1.0 + PP-Module for Endpoint Detection and Response (EDR), Version 2.0 + PP-Module for File Encryption, Version 2.0 + PP-Module for File Encryption Enterprise Management, Version 2.0 + PP-Module for Application Software Agent, Version 2.0 + PP-Module for Application Software Server, Version 2.0 + PP-Module for Host Agent, Version 2.0 + PP-Module for Redaction Tools, Version 1.0 + PP-Module for Voice and Video over IP (VVoIP), Version 2.0 + PP-Module for VPN Client, Version 3.0 + PP-Module for Web Browsers, Version 1.0 + + + Functional Package for Secure Shell Version 2.0 + Functional Package for Transport Layer Security Version 2.1 + Functional Package for X.509 Version 1.0 + + + + + + + The security problem is described in terms of the threats that the TOE is expected to address, assumptions about the operational environment, and any organizational security policies that the TOE is expected to enforce. + + + An attacker can act through unprivileged software on the same computing platform on which the application executes. Attackers may provide maliciously formatted input to the application in the form of files or other local communications.FCS_CKM_EXT.1The PP includes FCS_CKM_EXT.1 to specify that the TSF may rely on platform-provided key generation services.FCS_RBG_EXT.1The PP includes FCS_RBG_EXT.1 to specify that the TSF may rely on platform-provided random bit generation services.FCS_STO_EXT.1The PP includes FCS_STO_EXT.1 to specify that the TSF may rely on platform-provided credential storage services.FDP_DAR_EXT.1The PP includes FDP_DAR_EXT.1 to specify that the TSF may rely on platform-provided data-at-rest protection services.FDP_DEC_EXT.1The PP includes FDP_DEC_EXT.1 to limit access to platform hardware resources, which limits the methods by which an attacker can attempt to locally compromise the integrity of the TOE.FMT_CFG_EXT.1The PP includes FMT_CFG_EXT.1 for the TSP to limit unauthorized access to itself by preventing the use of default authentication credentials and by ensuring that the TOE uses appropriately restrictive platform permissions on its binaries and dataFMT_MEC_EXT.1The PP includes FMT_MEC_EXT.1 to ensure that the TOE can use platform services to store and set configuration options.FPT_AEX_EXT.1The PP includes FPT_AEX_EXT.1 to add complexity to the task of compromising systems by ensuring that the TOE implements various platform security features and can operate on a platform that is configured securely.FPT_API_EXT.1The PP includes FPT_API_EXT.1 to require the TOE to leverage platform functionality by using only documented and supported APIs.FPT_LIB_EXT.1The PP includes FPT_LIB_EXT.1 to ensure that the TOE does not include any unnecessary or unexpected third-party libraries which could present a privacy threat or vulnerability.FPT_TUD_EXT.1The PP includes FPT_TUD_EXT.1 to ensure that the TOE can be patched and that any updates to the TOE have appropriate integrity protection.FPT_API_EXT.2 (Objective)The PP includes FPT_API_EXT.2 to permit the TOE to use platform-provided libraries for parsing IANA MIME media formats.FCS_CKM.1/AK (Selection-based)The PP includes FCS_CKM.1/AK to specify that the TSF may rely on platform-provided asymmetric key generation services.FCS_CKM.2 (Selection-based)The PP includes FCS_CKM.2 to specify that the TSF may rely on platform-provided key establishment services.FPT_TUD_EXT.2 (Selection-based)The PP includes FPT_TUD_EXT.2 to ensure that TOE updates are packaged in a certain format, provide certain integrity protections, and remove residual data.An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may engage in communications with the application software or alter communications between the application software and other endpoints in order to compromise it.FCS_CKM_EXT.1The PP includes FCS_CKM_EXT.1 to specify whether the TOE or the platform is responsible for generation of any asymmetric keys that may be used for establishing trusted communications.FCS_RBG_EXT.1The PP includes FCS_RBG_EXT.1 to define whether the random bit generation services used in establishing trusted communications are implemented by the TSF or by the platform.FDP_DEC_EXT.1The PP includes FDP_DEC_EXT.1 to limit access to platform hardware resources, which limits the methods by which an attacker can attempt to remotely compromise the integrity of the TOE.FDP_NET_EXT.1The PP includes FDP_NET_EXT.1 to define the TOEโ€™s usage of network communications, which may include the transmission or receipt of data over a trusted channel.FMT_CFG_EXT.1The PP includes FMT_CFG_EXT.1 for the TSP to limit unauthorized access to itself by preventing the use of default authentication credentials and by ensuring that the TOE uses appropriately restrictive platform permissions on its binaries and dataFMT_SMF.1The PP includes FMT_SMF.1 to define the security-relevant management functions that are supported by the TOE, which may include configuration of network behavior.FPR_ANO_EXT.1The PP includes FPR_ANO_EXT.1 to define how the TSF provides control to the user regarding the disclosure of any PII.FPT_AEX_EXT.1The PP includes FPT_AEX_EXT.1 to add complexity to the task of compromising systems by ensuring that the TOE implements various platform security features and can operate on a platform that is configured securely.FPT_TUD_EXT.1The PP includes FPT_TUD_EXT.1 to ensure that updates to the TOE have integrity protection and cannot be altered via network attack.FTP_DIT_EXT.1The PP includes FTP_DIT_EXT.1 to define the trusted channels used to protect data in transit, the data that is protected, and whether the trusted channels are implemented by the TSF or the platform.FPT_IDV_EXT.1 (Objective)The PP includes FPT_IDV_EXT.1 to provide a mechanism to identify the TOE version so that it can be determined whether a vulnerability is present on the system based on the installed version.FCS_CKM.1/AK (Selection-based)The PP includes FCS_CKM.1/AK to define whether the TSF or the platform generates asymmetric keys that are used in support of trusted communications.FCS_CKM.1/SK (Selection-based)The PP includes FCS_CKM.1/SK to define the mechanism used to generate symmetric keys when the TOE performs this function.FCS_CKM.2 (Selection-based)The PP includes FCS_CKM.2 to define whether the TSF or the platform performs key establishment for trusted communications.FCS_COP.1/Hash (Selection-based)The PP includes FCS_COP.1/Hash to define the hash algorithms used in support of trusted communications.FCS_COP.1/KeyedHash (Selection-based)The PP includes FCS_COP.1/KeyedHash to define the HMAC algorithms used in support of trusted communications.FCS_COP.1/SigGen (Selection-based)The PP includes FCS_COP.1/SigGen to define the digital signature algorithms used in support of trusted communications.FCS_COP.1/SigVer (Selection-based)The PP includes FCS_COP.1/SigVer to define the digital signature algorithms used in support of trusted communications and trusted updates.FCS_COP.1/SKC (Selection-based)The PP includes FCS_COP.1/SKC to define the symmetric encryption algorithms used in support of trusted communications.FCS_HTTPS_EXT.1 (Selection-based)The PP includes FCS_HTTPS_EXT.1 to define the TOEโ€™s support for the HTTPS trusted communications protocol.FCS_HTTPS_EXT.2 (Selection-based)The PP includes FCS_HTTPS_EXT.2 to define the TOEโ€™s handling of X.509 certificates in the context of HTTPS communications.FCS_RBG.1 (Selection-based)The PP includes FCS_RBG.1 to define the DRBG algorithms used in support of trusted communications.FCS_RBG.2 (Selection-based)The PP includes FCS_RBG.2 to define how entropy is obtained for secure DRBG seeding.FCS_RBG.3 (Selection-based)The PP includes FCS_RBG.3 to define how entropy is obtained for secure DRBG seeding.FCS_RBG.4 (Selection-based)The PP includes FCS_RBG.4 to define how entropy is obtained for secure DRBG seeding.FCS_RBG.5 (Selection-based)The PP includes FCS_RBG.5 to define how entropy is obtained for secure DRBG seeding.FCS_SNI_EXT.1 (Selection-based)The PP includes FCS_SNI_EXT.1 to define the proper salt, nonce, and initialization vector usage to ensure proper cryptographic operation.FPT_FLS.1 (Selection-based)The PP includes FPT_FLS.1 to ensure that the TSF will not operate when it is in a state where it is unable to generate secure random numbers.FPT_TST.1 (Selection-based)The PP includes FPT_TST.1 to ensure that the TSF can determine whether or not it is capable of generating secure random numbers.FPT_TUD_EXT.2 (Selection-based)The PP includes FPT_TUD_EXT.2 to define specific integrity protections for certain types of updates.An attacker is positioned on a communications channel or elsewhere on the network infrastructure. Attackers may monitor and gain access to data exchanged between the application and other endpoints.FCS_CKM_EXT.1The PP includes FCS_CKM_EXT.1 to specify whether the TOE or the platform is responsible for generation of any asymmetric keys that may be used for establishing trusted communications.FCS_RBG_EXT.1The PP includes FCS_RBG_EXT.1 to define whether the random bit generation services used in establishing trusted communications are implemented by the TSF or by the platform.FCS_STO_EXT.1The PP includes FCS_STO_EXT.1 to specify that the TSF may rely on platform-provided credential storage services.FDP_DAR_EXT.1The PP includes FDP_DAR_EXT.1 to specify that the TSF may rely on platform-provided data-at-rest protection services.FDP_NET_EXT.1The PP includes FDP_NET_EXT.1 to define the TOEโ€™s usage of network communications, which may include the transmission or receipt of data over a trusted channel.FMT_MEC_EXT.1The PP includes FMT_MEC_EXT.1 to ensure that the TOE can use platform services to store and set configuration options.FMT_SMF.1The PP includes FMT_SMF.1 to define the security-relevant management functions that are supported by the TOE.FPR_ANO_EXT.1The PP includes FPR_ANO_EXT.1 to define how the TSF provides control to the user regarding the disclosure of any PII.FPT_API_EXT.1The PP includes FPT_API_EXT.1 to require the TOE to leverage platform functionality by using only documented and supported APIs.FPT_LIB_EXT.1The PP includes FPT_LIB_EXT.1 to ensure that the TOE does not include any unnecessary or unexpected third-party libraries which could present a privacy threat or vulnerability.FTP_DIT_EXT.1The PP includes FTP_DIT_EXT.1 to define the trusted channels used to protect data in transit, the data that is protected, and whether the trusted channels are implemented by the TSF or the platform.FPT_API_EXT.2 (Objective)The PP includes FPT_API_EXT.2 to permit the TOE to use platform-provided libraries for parsing IANA MIME media formats.FPT_IDV_EXT.1 (Objective)The PP includes FPT_IDV_EXT.1 to provide a mechanism to identify the TOE version so that it can be determined whether a vulnerability is present on the system based on the installed version.FCS_CKM.1/AK (Selection-based)The PP includes FCS_CKM.1/AK to define whether the TSF or the platform generates asymmetric keys that are used in support of trusted communications.FCS_CKM.1/SK (Selection-based)The PP includes FCS_CKM.1/SK to define the mechanism used to generate symmetric keys when the TOE performs this function.FCS_CKM.2 (Selection-based)The PP includes FCS_CKM.2 to define whether the TSF or the platform performs key establishment for trusted communications.FCS_COP.1/Hash (Selection-based)The PP includes FCS_COP.1/Hash to define the hash algorithms used in support of trusted communications.FCS_COP.1/KeyedHash (Selection-based)The PP includes FCS_COP.1/KeyedHash to define the HMAC algorithms used in support of trusted communications.FCS_COP.1/SigVer (Selection-based)The PP includes FCS_COP.1/SigVer to define the mechanism used to verify TOE updates if the TOE implements this functionality rather than the underlying platform.FCS_COP.1/SKC (Selection-based)The PP includes FCS_COP.1/SKC to define the symmetric encryption algorithms used in support of trusted communications.FCS_HTTPS_EXT.1 (Selection-based)The PP includes FCS_HTTPS_EXT.1 to define the TOEโ€™s support for the HTTPS trusted communications protocol.FCS_HTTPS_EXT.2 (Selection-based)The PP includes FCS_HTTPS_EXT.2 to define the TOEโ€™s handling of X.509 certificates in the context of HTTPS communications.FCS_RBG.1 (Selection-based)The PP includes FCS_RBG.1 to define the DRBG algorithms used in support of trusted communications.FCS_RBG.2 (Selection-based)The PP includes FCS_RBG.2 to define how entropy is obtained for secure DRBG seeding.FCS_RBG.3 (Selection-based)The PP includes FCS_RBG.3 to define how entropy is obtained for secure DRBG seeding.FCS_RBG.4 (Selection-based)The PP includes FCS_RBG.4 to define how entropy is obtained for secure DRBG seeding.FCS_RBG.5 (Selection-based)The PP includes FCS_RBG.5 to define how entropy is obtained for secure DRBG seeding.FPT_FLS.1 (Selection-based)The PP includes FPT_FLS.1 to ensure that the TSF will not operate when it is in a state where it is unable to generate secure random numbers.FPT_TST.1 (Selection-based)The PP includes FPT_TST.1 to ensure that the TSF can determine whether or not it is capable of generating secure random numbers.An attacker may try to access sensitive data at rest.FCS_RBG_EXT.1The PP includes FCS_RBG_EXT.1 to define whether random bit generation services are implemented by the TSF or the platform. Depending on how data at rest is protected, the TOE may rely on the use of a random bit generator to create keys that are subsequently used for data protection.FCS_STO_EXT.1The PP includes FCS_STO_EXT.1 to define the mechanism that the TSF uses or relies upon to protect stored credential data.FDP_DAR_EXT.1The PP includes FDP_DAR_EXT.1 to define the mechanism that the TSF uses or relies upon to protect sensitive data at rest.FPT_IDV_EXT.1 (Objective)The PP includes FPT_IDV_EXT.1 to provide a mechanism to identify the TOE version so that it can be determined whether a vulnerability is present on the system based on the installed version.FCS_CKM.1/SK (Selection-based)The PP includes FCS_CKM.1/SK to define the TOEโ€™s capability to generate symmetric keys. These keys may subsequently be used to encrypt stored credential data based on the claims made in FCS_STO_EXT.1.FCS_COP.1/Hash (Selection-based)The PP includes FCS_COP.1/Hash to define integrity mechanisms that may be used by the TOE as part of ensuring that data at rest is protected.FCS_COP.1/KeyedHash (Selection-based)The PP includes FCS_COP.1/KeyedHash to define HMAC mechanisms that may be used by the TOE as part of ensuring that data at rest is protected.FCS_COP.1/SKC (Selection-based)The PP includes FCS_COP.1/SKC to define the AES cryptographic algorithm that may be used to encrypt stored credential data based on the claims made in FCS_STO_EXT.1.FCS_PBKDF_EXT.1 (Selection-based)The PP includes FCS_PBKDF_EXT.1 to define the password-based key derivation function that may be used to encrypt stored credential data based on the claims made in FCS_STO_EXT.1.FCS_RBG.1 (Selection-based)The PP includes FCS_RBG.1 to define the DRBG algorithms used in support of trusted communications.FCS_RBG.2 (Selection-based)The PP includes FCS_RBG.2 to define how entropy is obtained for secure DRBG seeding.FCS_RBG.3 (Selection-based)The PP includes FCS_RBG.3 to define how entropy is obtained for secure DRBG seeding.FCS_RBG.4 (Selection-based)The PP includes FCS_RBG.4 to define how entropy is obtained for secure DRBG seeding.FCS_RBG.5 (Selection-based)The PP includes FCS_RBG.5 to define how entropy is obtained for secure DRBG seeding.FPT_FLS.1 (Selection-based)The PP includes FPT_FLS.1 to ensure that the TSF will not operate when it is in a state where it is unable to generate secure random numbers.FPT_TST.1 (Selection-based)The PP includes FPT_TST.1 to ensure that the TSF can determine whether or not it is capable of generating secure random numbers. + + + + + The TOE relies upon a trustworthy computing platform with a reliable time clock for + its execution. This includes the underlying platform and whatever runtime environment + it provides to the TOE. + + The operational environment objective OE.PLATFORM is realized through + A.PLATFORM. + + + + The administrator of the application software is not careless, willfully + negligent or hostile, and administers the software in compliance with the applied + enterprise security policy. + + The operational environment objective OE.PROPER_ADMIN + is realized through A.PROPER_ADMIN. + + + + + The user of the application software is not willfully negligent or hostile, + and uses the software in compliance with the applied enterprise security policy. + + + The operational environment objective OE.PROPER_USER + is realized through A.PROPER_USER. + + + + + + + + + + + + + + + The following security objectives for the operational environment assist the TOE in correctly providing its security functionality. These track with the assumptions about the environment. + + + The TOE relies upon a trustworthy computing platform for + its execution. This includes the underlying operating system and any discrete execution + environment provided to the TOE. + + + The administrator of the application software is not careless, willfully + negligent or hostile, and administers the software within compliance of the applied + enterprise security policy. + + + The user of the application software is not willfully negligent or hostile, + and uses the software within compliance of the applied enterprise security + policy. + + + + + + + + + + + +
+ + This family defines requirements for management of cryptographic keys that are not addressed by FCS_CKM in CC Part 2. + + + This family defines requirements for implementation of the HTTPS protocol. + + + This family defines requirements for implementation of password-based key derivation functions. + + + This family defines requirements for the generation of random bits. + + + This family defines requirements for the secure storage of credential data. + + + + + + + The <h:b>application</h:b> shall <h:b> <selectables linebreak="yes"><selectable id="fcs_ckm.1.1_AK_1" >invoke platform-provided functionality</selectable><selectable id="fcs_ckm.1.1_AK_2" >implement functionality</selectable> </selectables> </h:b> to generate <h:b>asymmetric</h:b> cryptographic keys in accordance with a specified cryptographic key generation algorithm <selectables linebreak="yes"><selectable id="fcs_ckm.1.1_AK_3">CNSA 2.0 Compliant Algorithms: <selectables linebreak="yes"><selectable id="fcs_ckm.1.1_AK_4"><h:b>Leighton-Micali Signature Algorithm</h:b> using the parameter sets <selectables><selectable id="fcs_ckm.1.1_AK_5" >LMS_SHAKE_M24_H5</selectable><selectable id="fcs_ckm.1.1_AK_6" >LMS_SHAKE_M24_H10</selectable><selectable id="fcs_ckm.1.1_AK_7" >LMS_SHAKE_M24_H15</selectable><selectable id="fcs_ckm.1.1_AK_8" >LMS_SHAKE_M24_H25</selectable><selectable id="fcs_ckm.1.1_AK_9" >LMS_SHAKE_M32_H5</selectable><selectable id="fcs_ckm.1.1_AK_10" >LMS_SHAKE_M32_H10</selectable><selectable id="fcs_ckm.1.1_AK_11" >LMS_SHAKE_M32_H15</selectable><selectable id="fcs_ckm.1.1_AK_12" >LMS_SHAKE_M32_H25</selectable><selectable id="fcs_ckm.1.1_AK_13" >LMS_SHA256_M24_H5</selectable><selectable id="fcs_ckm.1.1_AK_14" >LMS_SHA256_M24_H10</selectable><selectable id="fcs_ckm.1.1_AK_15" >LMS_SHA256_M24_H15</selectable><selectable id="fcs_ckm.1.1_AK_16" >LMS_SHA256_M24_H25</selectable><selectable id="fcs_ckm.1.1_AK_17" >LMS_SHA256_M32_H5</selectable><selectable id="fcs_ckm.1.1_AK_18" >LMS_SHA256_M32_H10</selectable><selectable id="fcs_ckm.1.1_AK_19" >LMS_SHA256_M32_H15</selectable><selectable id="fcs_ckm.1.1_AK_20" >LMS_SHA256_M32_H25</selectable></selectables> that meet the following [NIST SP 800-208, "Recommendation for Stateful Hash-Based Signature Schemes"]</selectable><selectable id="fcs_ckm.1.1_AK_21"><h:b>eXtended Merkle Signature Scheme Algorithm</h:b> using the parameter sets <selectables><selectable id="fcs_ckm.1.1_AK_22" >XMSS-SHA2_10_192</selectable><selectable id="fcs_ckm.1.1_AK_23" >XMSS-SHA2_16_192</selectable><selectable id="fcs_ckm.1.1_AK_24" >XMSS-SHA2_20_192</selectable><selectable id="fcs_ckm.1.1_AK_25" >XMSS-SHA2_10_256</selectable><selectable id="fcs_ckm.1.1_AK_26" >XMSS-SHA2_16_256</selectable><selectable id="fcs_ckm.1.1_AK_27" >XMSS-SHA2_20_256</selectable><selectable id="fcs_ckm.1.1_AK_28" >XMSS-SHAKE_10_192</selectable><selectable id="fcs_ckm.1.1_AK_29" >XMSS-SHAKE_16_192</selectable><selectable id="fcs_ckm.1.1_AK_30" >XMSS-SHAKE_20_192</selectable><selectable id="fcs_ckm.1.1_AK_31" >XMSS-SHAKE_10_256</selectable><selectable id="fcs_ckm.1.1_AK_32" >XMSS-SHAKE_16_256</selectable><selectable id="fcs_ckm.1.1_AK_33" >XMSS-SHAKE_20_256</selectable></selectables> that meets the following: [NIST SP 800-208, "Recommendation for Stateful Hash-Based Signature Schemes"]</selectable><selectable id="fcs_ckm.1.1_AK_34" ><h:b>Module-Lattice-Based Key-Encapsulation Mechanism Standard</h:b> using the parameter set ML-KEM-1024 that meets the following: [FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard]</selectable><selectable id="fcs_ckm.1.1_AK_35" ><h:b>Module-Lattice-Based Digital Signature Standard</h:b> using the parameter set ML-DSA-87 that meets the following [FIPS 204, Module-Lattice-Based Digital Signature Standard]</selectable></selectables> </selectable><selectable id="fcs_ckm.1.1_AK_36">CNSA 1.0 Compliant Algorithms: <selectables linebreak="yes"><selectable id="fcs_ckm.1.1_AK_37" ><h:b>[RSA schemes]</h:b> using cryptographic key sizes of [<h:i>3072-bit or greater</h:i>] that meet the following: [<h:i>FIPS PUB 186-5, "Digital Signature Standard (DSS)," Appendix A.1</h:i>]</selectable><selectable id="fcs_ckm.1.1_AK_38"><h:b>[ECC schemes]</h:b> using [<h:i>โ€œNIST curvesโ€ P-384 and <selectables><selectable id="fcs_ckm.1.1_AK_39" >P-521</selectable><selectable id="fcs_ckm.1.1_AK_40" >no other curves</selectable></selectables> </h:i>] that meet the following: [<h:i>FIPS PUB 186-5, โ€œDigital Signature Standard (DSS),โ€ Appendix A.2</h:i>]</selectable><selectable id="fcs_ckm.1.1_AK_41"><h:b>[FFC Schemes]</h:b> using [<h:i>โ€œsafe-primeโ€ groups</h:i>] <selectables><selectable id="fcs_ckm.1.1_AK_42" >MODP-3072</selectable><selectable id="fcs_ckm.1.1_AK_43" >MODP-4096</selectable><selectable id="fcs_ckm.1.1_AK_44" >MODP-6144</selectable><selectable id="fcs_ckm.1.1_AK_45" >MODP-8192</selectable><selectable id="fcs_ckm.1.1_AK_46" >ffdhe-3072</selectable><selectable id="fcs_ckm.1.1_AK_47" >ffdhe-4096</selectable><selectable id="fcs_ckm.1.1_AK_48" >ffdhe-6144</selectable><selectable id="fcs_ckm.1.1_AK_49" >ffdhe-8192</selectable></selectables> that meet the following: [<h:i>NIST Special Publication 800-56A Revision 3, โ€œRecommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptographyโ€ and <selectables><selectable id="fcs_ckm.1.1_AK_50" >RFC 3526</selectable><selectable id="fcs_ckm.1.1_AK_51" >RFC 7919</selectable></selectables> </h:i>]</selectable></selectables> </selectable> </selectables>. + The ST should claim all key generation schemes used for key establishment and entity authentication. When key generation is used for key establishment, the schemes in FCS_CKM.2.1 and selected cryptographic protocols must match the selection. When key generation is used for entity authentication, the public key is expected to be associated with an X.509v3 certificate.If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation.Note that ML-DSA and ML-KEM are not usable in any functions at the time of initial publication, they are added to this requirement in support of future protocol updates. As support is expanded for CNSA 2.0, CNSA 1.0 will be removed as an selection in a future update. + + The evaluator shall ensure that the TSS identifies the key sizes supported by the TOE. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each schemeIf the ST selects "invoke platform-provided functionality," then the evaluator shall examine the TSS to verify that it describes how the key generation functionality is invoked and that the invocation matches the algorithm and size selections for each supported platform. The evaluator shall confirm the invocation of the platform is using non-deprecated functions provided by the platform(s). + The evaluator shall verify that the operational guidance instructs the administrator how to configure the TOE to use the selected key generation scheme(s) and key size(s) for all uses defined in this PP if any configuration is required. + If the ST selects "implement functionality," then the following test activities shall be carried out. Evaluation Activity Note: The following tests may require the developer to provide access to a developer environment that provides the evaluator with tools that are not typically available to end-users of the application Key Generation for FIPS PUB 186-5 RSA Schemes The evaluator shall verify the implementation of RSA Key Generation by the TOE using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d. Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include:Random Primes:Provable primesProbable primesPrimes with Conditions:Primes p1, p2, q1, q2, p, and q shall all be provable primesPrimes p1, p2, q1, and q2 shall be provable primes, and p and q shall be probable primesPrimes p1, p2, q1, q2, p, and q shall all be probable primes To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seed(s), the public exponent of the RSA key, and the desired key length. For each key length supported, the evaluator shall have the TSF generate 25 key pairs. The evaluator shall verify the correctness of the TSFโ€™s implementation by comparing values generated by the TSF with those generated from a known good implementation. If possible, the Random Probable primes method should also be verified against a known good implementation as described above. Otherwise, the evaluator shall have the TSF generate 10 keys pairs for each supported key length nlen and verify:n = pโ‹…q,p and q are probably prime according to Miller-Rabin tests,GCD(p-1, e) = 1,GCD(q-1, e) = 1,2 16โ‰ค e โ‰ค 2 256 and e is an odd integer,|p-q| > 2 nlen/2 - 100,p โ‰ฅ 2 nlen/2 -1/2,q โ‰ฅ 2 nlen/2 -1/2,2 (nlen/2)< d < LCM(p-1, q-1),eโ‹…d = 1 mod LCM(p-1, q-1). Key Generation for Elliptic Curve Cryptography (ECC) FIPS 186-5 ECC Key Generation Test- For each supported NIST curve, i.e., P-384 and P-521, the evaluator shall require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator shall submit the generated key pairs to the public key verification (PKV) function of a known good implementation. FIPS 186-5 Public Key Verification (PKV) Test- For each supported NIST curve, i.e., P-384 and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e., correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values. Key Generation for Finite-Field Cryptography (FFC) The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and public key y. The Parameter generation specifies two ways (or methods) to generate the cryptographic prime q and the field prime p: Cryptographic and Field Primes:Primes q and p shall both be provable primesPrimes q and field prime p shall both be probable primes and two ways to generate the cryptographic group generator g: Cryptographic Group Generator:Generator g constructed through a verifiable processGenerator g constructed through an unverifiable process. The Key generation specifies 2 ways to generate the private key x: Private Key:len(q) bit output of RBG where 1 โ‰ค x โ‰ค q-1len(q) + 64 bit output of RBG, followed by a mod q-1 operation where 1โ‰ค x โ‰คq-1. The security strength of the RBG must be at least that of the security offered by the FFC parameter set. To test the cryptographic and field prime generation method for the provable primes method and/or the group generator g for a verifiable process, the evaluator must seed the TSF parameter generation routine with sufficient data to deterministically generate the parameter set. For each key length supported, the evaluator shall have the TSF generate 25 parameter sets and key pairs. The evaluator shall verify the correctness of the TSFโ€™s implementation by comparing values generated by the TSF with those generated from a known good implementation. Verification must also confirm g โ‰  0,1q divides p-1g q mod p = 1g x mod p = y for each FFC parameter set and key pair. Testing for FFC Schemes using safe-prime groups is done as part of testing in FCS_CKM.2.1 Key Generation for LMS/XMSS For each supported LMS/LMSOTS pair, the evaluator will provide 1, 2, 3, 4, 5 seeds for H = 25, 20, 15, 10, 5 respectively where H = the height of the LMS tree. For each seed, the TOE will generate the corresponding public key which is to be verified by the evaluator using a known good implementation. Key Generation for ML-DSA The evaluator shall 10x input to the internal KeyGen function a 32-byte random seed. Verify the returned public-private key pair is correct using a known good implementation. Here internal KeyGen refers to the TOEโ€™s implementation of the function ML-DSA.KeyGen_internal(-) as described in FIPS.204. Key Generation for ML-KEM The evaluator shall 10x input to the internal KeyGen function a pair of 32-byte random string. Verify the returned encapsulation and decapsulation key pair is correct using a known good implementation. Here internal KeyGen refers to the TOEโ€™s implementation of the function ML-KEM.KeyGen_internal(-,-) as described in FIPS.203. + + + + + + + + + + + + The <h:b>application</h:b> shall <selectables><selectable id="fcs_ckm.1.1_SK_1" >invoke platform-provided functionality</selectable><selectable id="fcs_ckm.1.1_SK_2" >implement functionality</selectable> </selectables> to generate <h:b>symmetric</h:b> cryptographic keys <h:b>using a Random Bit Generator as specified in FCS_RBG_EXT.1</h:b> and specified cryptographic key sizes <h:i>256-bit</h:i> + This requirement is dependent on selecting any AES selection in FCS_COP.1.1/SKC. Symmetric keys may be used to generate keys along the key chain. + + The evaluator shall review the TSS to determine that it describes how the functionality described by FCS_RBG_EXT.1 is invoked.If the application is relying on random bit generation from the host platform, the evaluator shall verify the TSS includes the name/manufacturer of the external RBG and describes the function call and parameters used when calling the external DRBG function. If different external RBGs are used for different platforms, the evaluator shall verify the TSS identifies each RBG for each platform. Also, the evaluator shall verify the TSS includes a short description of the vendor's assumption for the amount of entropy seeding the external DRBG. The evaluator uses the description of the RBG functionality in FCS_RBG_EXT or documentation available for the operational environment to determine that the key size being requested is identical to the key size and mode to be used for the encryption/decryption of the user data. + The evaluator shall verify the guidance documentation contains any information necessary to configure key sizes. + None. + + + + + + + + + + + <h:p>The application shall <selectables><selectable id="fcs_ckm.2.1_1" >invoke platform-provided functionality</selectable><selectable id="fcs_ckm.2.1_2" >implement functionality</selectable> </selectables> to perform cryptographic key establishment in accordance with a specified cryptographic key establishment method:</h:p> <h:p> <selectables linebreak="yes"><selectable id="fcs_ckm.2.1_3" >CNSA 2.0 Compliant Algorithm:<h:ul><h:b>Module-Lattice-Based Key-Encapsulation Mechanism Standard</h:b> using the <h:b>parameter set ML-KEM-1024</h:b> that meets the following: [FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard]</h:ul></selectable><selectable id="fcs_ckm.2.1_4">CNSA 1.0 Compliant Algorithms: <selectables linebreak="yes"><selectable id="fcs_ckm.2.1_5" ><h:b>[RSA-based key establishment schemes]</h:b> that meet the following: <h:b>[NIST Special Publication 800-56B, โ€œRecommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptographyโ€]</h:b></selectable><selectable id="fcs_ckm.2.1_6" ><h:b>[Elliptic curve-based key establishment schemes]</h:b> that meets the following: <h:b>[NIST Special Publication 800-56A, โ€œRecommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptographyโ€]</h:b></selectable><selectable id="fcs_ckm.2.1_7"><h:b>[FFC Schemes using โ€œsafe-primeโ€ groups]</h:b> that meet the following: <h:b>โ€˜NIST Special Publication 800-56A Revision 3, โ€œRecommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptographyโ€</h:b> and <selectables><selectable id="fcs_ckm.2.1_8" >RFC 3526</selectable><selectable id="fcs_ckm.2.1_9" >RFC 7919</selectable></selectables> </selectable></selectables> </selectable> </selectables> </h:p> . + The ST author shall select all key establishment schemes used for the selected cryptographic protocols. TLS requires cipher suites that use RSA-based key establishment schemes.The RSA-based key establishment schemes are described in Section 9 of NIST SP 800-56B; however, Section 9 relies on implementation of other sections in SP 800-56B. If the TOE acts as a receiver in the RSA key establishment scheme, the TOE does not need to implement RSA key generation.The elliptic curves used for the key establishment scheme shall correlate with the curves specified in FCS_CKM.1.1/AK.The domain parameters used for the finite field-based key establishment scheme are specified by the key generation according to FCS_CKM.1.1/AK.As support is expanded for CNSA 2.0, CNSA 1.0 will be removed as an selection in a future update. + + The evaluator shall ensure that the supported key establishment schemes claimed in the TSS correspond to the key generation schemes identified in FCS_CKM.1.1/AK. If the ST specifies more than one scheme, the evaluator shall examine the TSS to verify that it identifies the usage for each scheme.If the ST selects "invoke platform-provided functionality," then the evaluator shall examine the TSS to verify that it describes how the key establishment functionality is invoked and that the invocation matches the algorithm selection for each supported platform. The evaluator shall confirm the invocation of the platform is using non-deprecated functions provided by the platform(s). + The evaluator shall verify that the operational guidance instructs the administrator how to configure the TOE to use the selected key establishment scheme(s) if configuration is required. + Evaluation Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products. Key Establishment Schemes The evaluator shall verify the implementation of the key establishment schemes supported by the TOE using the applicable tests below. SP800-56A Key Establishment Schemes The evaluator shall verify a TOE's implementation of SP800-56A key agreement schemes using the following Function and Validity tests. These validation tests for each key agreement scheme verify that a TOE has implemented the components of the key agreement scheme according to the specifications in the Recommendation. These components include the calculation of the DLC primitives (the shared secret value Z) and the calculation of the derived keying material (DKM) via the Key Derivation Function (KDF). If key confirmation is supported, the evaluator shall also verify that the components of key confirmation have been implemented correctly, using the test procedures described below. This includes the parsing of the DKM, the generation of MACdata and the calculation of MACtag. Function Test The Function test verifies the ability of the TOE to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each supported key agreement scheme-key agreement role combination, KDF type, and if supported, key confirmation role and type combination, the tester shall generate 10 sets of test vectors. The data set consists of one set of domain parameter values (FFC) or the NIST approved curve (ECC) per 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested. The evaluator shall obtain the DKM, the corresponding TOEโ€™s public keys (static and/or ephemeral), the MAC tag(s), and any inputs used in the KDF, such as the Other Information (OtherInfo) and TOE ID fields. If the TOE does not use a KDF defined in SP 800-56A, the evaluator shall obtain only the public keys and the hashed value of the shared secret. The evaluator shall verify the correctness of the TSFโ€™s implementation of a given scheme by using a known good implementation to calculate the shared secret value, derive the keying material DKM, and compare hashes or MAC tags generated from these values. If key confirmation is supported, the TSF shall perform the above for each implemented approved MAC algorithm. Validity Test The Validity test verifies the ability of the TOE to recognize another partyโ€™s valid and invalid key agreement results with or without key confirmation. To conduct this test, the evaluator shall obtain a list of the supporting cryptographic functions included in the SP800-56A key agreement implementation to determine which errors the TOE should be able to recognize. The evaluator generates a set of 24 (FFC) or 30 (ECC) test vectors consisting of data sets including domain parameter values or NIST approved curves, the evaluatorโ€™s public keys, the TOEโ€™s public/private key pairs, MACTag, and any inputs used in the KDF, such as the OtherInfo and TOE ID fields. The evaluator shall inject an error in some of the test vectors to test that the TOE recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value Z, the DKM, the OtherInfo field, the data to be MACed, or the generated MACTag. If the TOE contains the full or partial (only ECC) public key validation, the evaluator will also individually inject errors in both partiesโ€™ static public keys, both partiesโ€™ ephemeral public keys and the TOEโ€™s static private key to ensure that the TOE detects errors in the public key validation function and/or the partial key validation function (in ECC only). At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass). The TOE shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator shall compare the TOEโ€™s results with the results obtained by using a known good implementation verifying that the TOE detects these errors. SP800-56B Key Establishment Schemes The evaluator shall verify that the TSS describes whether the TOE acts as a sender, a recipient, or both for RSA-based key establishment schemes. If the TOE acts as a sender, the following evaluation activity shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme: To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each combination of supported key establishment scheme and its options (with or without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTS-OAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA public key, the plaintext keying material, any additional input parameters if applicable, the MacKey and MacTag if key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform a key establishment encryption operation on the TOE with the same inputs (in cases where key confirmation is incorporated, the test shall use the MacKey from the test vector instead of the randomly generated MacKey used in normal operation) and ensure that the outputted ciphertext is equivalent to the ciphertext in the test vector. If the TOE acts as a receiver, the following evaluation activities shall be performed to ensure the proper operation of every TOE supported combination of RSA-based key establishment scheme: To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the TOE supported schemes. For each combination of supported key establishment scheme and its options (with or without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTS-OAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA private key, the plaintext keying material (KeyData), any additional input parameters if applicable, the MacTag in cases where key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform the key establishment decryption operation on the TOE and ensure that the outputted plaintext keying material (KeyData) is equivalent to the plaintext keying material in the test vector. In cases where key confirmation is incorporated, the evaluator shall perform the key confirmation steps and ensure that the outputted MacTag is equivalent to the MacTag in the test vector. The evaluator shall ensure that the TSS describes how the TOE handles decryption errors. In accordance with NIST Special Publication 800-56B, the TOE must not reveal the particular error that occurred, either through the contents of any outputted or logged error message or through timing variations. If KTS-OAEP is supported, the evaluator shall create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.2.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each. If KTS-KEM-KWS is supported, the evaluator shall create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800-56B section 7.2.3.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each. FFC Schemes using โ€œsafe-primeโ€ groups The evaluator shall verify the correctness of the TSFโ€™s implementation of safe-prime groups by using a known good implementation for each protocol selected in FTP_DIT_EXT.1 that uses safe-prime groups. This test must be performed for each safe-prime group that each protocol uses. ML-KEM Key Establishment Schemes To test encapsulation the evaluator shall 10x input to the internal Encaps function a random 32-byte string and an encapsulation key. Verify the returned cipher text and shared secret is correct using a known good implementation. Here internal refers to the TOEโ€™s implementation of the function ML-KEM.Encaps_internal(-,-) as described in FIPS.203.To test decapsulation the evaluator shall 10x input to the internal Decaps function a cipher text and decapsulation key. Verify the returned shared secret is correct using a known good implementation. The tests should include a mix of valid and invalid/garbled cipher texts. Here internal refers to the TOEโ€™s implementation of the function ML-KEM.Decaps_internal(-,-) as described in FIPS.203. + + + + + + requires the TSF to specify whether asymmetric key generation is implemented by the TSF, invoked from the operational environment, or not used by the TOE. + No specific management functions are identified. + There are no auditable events foreseen. + No dependencies. + + The application shall <selectables linebreak="yes"><selectable id="fcs_ckm_ext.1.1_1" exclusive="yes">generate no asymmetric cryptographic keys</selectable><selectable id="sel_invoke_genkey" >invoke platform-provided functionality for asymmetric key generation</selectable><selectable id="sel_impl_genkey" >implement asymmetric key generation</selectable> </selectables>. + If "implement asymmetric key generation" or "invoke platform-provided functionality for asymmetric key generation" is selected, then FCS_CKM.1/AK must be claimed in the ST. + + The evaluator shall examine the TSS to verify that it describes whether the TSF has functions that require the use of asymmetric key generation services, and whether these services are implemented within the TOE boundary or invoked by the TSF from its operational environment.Conditional: If the ST claims "generate no asymmetric keys," the evaluator shall ensure that the TOE does not have any functions that would require asymmetric key generation (for example, because it does not use asymmetric keys for any purpose or because the keys that it does use are generated elsewhere and imported into it as part of initial setup). + None. + None. + + + + + + + + + + + The <h:b>application</h:b> shall perform [<h:i>cryptographic hashing services</h:i>] in accordance with a specified cryptographic algorithm <selectables linebreak="yes"><selectable id="fcs_cop.1.1_Hash_1" >SHA-256</selectable><selectable id="fcs_cop.1.1_Hash_2" >SHA-384</selectable><selectable id="fcs_cop.1.1_Hash_3" >SHA-512</selectable> </selectables> and <h:b>message digest</h:b> sizes <selectables linebreak="yes"><selectable id="fcs_cop.1.1_Hash_4" >256</selectable><selectable id="fcs_cop.1.1_Hash_5" >384</selectable><selectable id="fcs_cop.1.1_Hash_6" >512</selectable> </selectables> <h:b>bits</h:b> that meet the following: [<h:i>FIPS Pub 180-4, "Secure Hash Standard"</h:i>]. + This is dependent on implementing cryptographic functionality, as in FTP_DIT_EXT.1.The intent of this requirement is to specify the hashing function. The hash selection must support the message digest size selection. + + The evaluator shall check that the association of the hash function with other application cryptographic functions (for example, the digital signature verification function) is documented in the TSS. + The evaluator shall verify the guidance documentation contains any information required for configuring the algorithm or size. + + The TSF hashing functions can be implemented in one of two modes. The first mode is the byte-oriented mode. In this mode the TSF hashes only messages that are an integral number of bytes in length; i.e., the length (in bits) of the message to be hashed is divisible by 8. The second mode is the bit-oriented mode. In this mode the TSF hashes messages of arbitrary length. As there are different tests for each mode, an indication is given in the following sections for the bit-oriented vs. the byte-oriented test MACs. The evaluator shall perform all of the following tests for each hash algorithm implemented by the TSF and used to satisfy the requirements of this PP. The following tests require the developer to provide access to a test application that provides the evaluator with tools that are typically not found in the production application. + + Short Messages Test - Bit-oriented Mode. The evaluators devise an input set consisting of m+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m bits. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. + Short Messages Test - Byte-oriented Mode. The evaluators devise an input set consisting of m/8+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m/8 bytes, with each message being an integral number of bytes. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. + Selected Long Messages Test - Bit-oriented Mode. The evaluators devise an input set consisting of m messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 99*i, where 1 โ‰ค i โ‰ค m. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. + Selected Long Messages Test - Byte-oriented Mode. The evaluators devise an input set consisting of m/8 messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 8*99*i, where 1 โ‰ค i โ‰ค m/8. The message text shall be pseudorandomly generated. The evaluators compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF. + Pseudorandomly Generated Messages Test. This test is for byte-oriented implementations only. The evaluators randomly generate a seed that is n bits long, where n is the length of the message digest produced by the hash function to be tested. The evaluators then formulate a set of 100 messages and associated digests by following the algorithm provided in Figure 1 of [SHAVS]. The evaluators then ensure that the correct result is produced when the messages are provided to the TSF. + + + + + + + + + + + + + The <h:b>application</h:b> shall perform [<h:i>keyed-hash message authentication</h:i>] in accordance with a specified cryptographic algorithm <selectables linebreak="yes"><selectable id="fcs_cop.1.1_KeyedHash_1" >HMAC-SHA-256</selectable><selectable id="fcs_cop.1.1_KeyedHash_2" >HMAC-SHA-384</selectable><selectable id="fcs_cop.1.1_KeyedHash_3" >HMAC-SHA-512</selectable> </selectables> <h:b>with</h:b> key sizes <assignable>key size (in bits) used in HMAC</assignable> <h:b>and message digest sizes</h:b> <selectables><selectable id="fcs_cop.1.1_KeyedHash_5" >256</selectable><selectable id="fcs_cop.1.1_KeyedHash_6" >384</selectable><selectable id="fcs_cop.1.1_KeyedHash_7" >512</selectable> </selectables> <h:b>bits</h:b> that meet the following: [<h:i>FIPS Pub 198-1, "The Keyed-Hash Message Authentication Code," and FIPS Pub 180-4, "Secure Hash Standard"</h:i>]. + This is dependent on implementing cryptographic functionality, as in FTP_DIT_EXT.1.The intent of this requirement is to specify the keyed-hash message authentication function used for key establishment purposes for the various cryptographic protocols used by the application (e.g., trusted channel). The hash selection must support the message digest size selection. + + + The evaluator shall perform the following activities based on the selections in the ST: + + None. + The evaluator shall verify the guidance documentation contains any information required for configuring the algorithm or size. + For each of the supported parameter sets, the evaluator shall compose 15 sets of test data. Each set shall consist of a key and message data. The evaluator shall have the TSF generate HMAC tags for these sets of test data. The resulting MAC tags shall be compared to the result of generating HMAC tags with the same key and IV using a known-good implementation. + + + + + + + + + + + The <h:b>application</h:b> shall perform [<h:i>cryptographic signature services (generation)</h:i>] in accordance with a specified cryptographic algorithm <selectables linebreak="yes"><selectable id="fcs_cop.1.1_SigGen_1" >CNSA 2.0 Compliant Algorithm:<h:ul><h:b>Module-Lattice-Based Digital Signature Standard</h:b> using the parameter set ML-DSA-87 that meets the following [FIPS 204, Module-Lattice-Based Digital Signature Standard]</h:ul></selectable><selectable id="fcs_cop.1.1_SigGen_2">CNSA 1.0 Compliant Algorithms: <selectables linebreak="yes"><selectable id="fcs_cop.1.1_SigGen_3" ><h:b>RSA schemes</h:b> using cryptographic key sizes of [3072-bit or greater] that meet the following: [FIPS PUB 186-5, โ€œDigital Signature Standard (DSS),โ€ Section 5]</selectable><selectable id="fcs_cop.1.1_SigGen_4"><h:b>ECDSA schemes</h:b> using [โ€œNIST curvesโ€ <selectables><selectable id="fcs_cop.1.1_SigGen_5" >P-384</selectable><selectable id="fcs_cop.1.1_SigGen_6" >P-521</selectable></selectables> ] that meet the following: [FIPS PUB 186-5, โ€œDigital Signature Standard (DSS),โ€ Section 6]</selectable></selectables> </selectable> </selectables>. + This is dependent on implementing cryptographic functionality, as in FTP_DIT_EXT.1.The ST author should choose the algorithm implemented to perform digital signatures; if more than one algorithm is available, this requirement should be iterated to specify the functionality. For the algorithm chosen, the ST author should make the appropriate assignments/selections to specify the parameters that are implemented for that algorithm.Note ML-DSA is not able to be used in any functions at the time of publication, it is being added for future support. As support is expanded for CNSA 2.0, CNSA 1.0 will be removed as an selection in a future update. + + + The evaluator shall perform the following activities based on the selections in the ST. + + + The evaluator shall verify the guidance documentation contains any information required for configuring the algorithm or size. + + The following tests require the developer to provide access to a test application that provides the evaluator with tools that are typically not found in the production application. + + ECDSA Algorithm Test + ECDSA FIPS 186-5 Signature Generation Test. For each supported NIST curve (i.e., P-384 and P-521) and SHA function pair, the evaluator shall generate 10 1024-bit long messages and obtain for each message a public key and the resulting signature values R and S. To determine correctness, the evaluator shall use the signature verification function of a known good implementation. + + + RSA Signature Algorithm Test + Signature Generation Test. The evaluator shall verify the implementation of RSA Signature Generation by the TOE using the Signature Generation Test. To conduct this test the evaluator must generate or obtain 10 messages from a trusted reference implementation for each modulus size/SHA combination supported by the TSF. The evaluator shall have the TOE use their private key and modulus value to sign these messages. The evaluator shall verify the correctness of the TSFโ€™s signature using a known good implementation and the associated public keys to verify the signatures. + + + ML-DSA Test + The evaluator shall 10x input to the internal Sign function a 32-byte random string, private key, and a randomly generated message. Check and confirm the value of the returned signature using a known good implementation. Here internal Sign refers to the TOEโ€™s implementation of the function ML-DSA.Sign_internal(-,-,-) as described in NIST FIPS PUB 204. + + + + + + + + + + + + + + + The <h:b>application</h:b> shall perform [<h:i>cryptographic signature services (verification)</h:i>] in accordance with a specified cryptographic algorithm <selectables linebreak="yes"><selectable id="fcs_cop.1.1_SigVer_1">CNSA 2.0 Compliant Algorithms: <selectables linebreak="yes"><selectable id="fcs_cop.1.1_SigVer_2"><h:b>Leighton-Micali Signature Algorithm</h:b> for verification using cryptographic key sizes of <selectables><selectable id="fcs_cop.1.1_SigVer_3" >192</selectable><selectable id="fcs_cop.1.1_SigVer_4" >256</selectable></selectables> bits that meet the following [NIST SP 800-208, "Recommendation for Stateful Hash-Based Signature Schemes"]</selectable><selectable id="fcs_cop.1.1_SigVer_5"><h:b>eXtended Merkle Signature Scheme Algorithm</h:b> for verification using cryptographic key sizes of <selectables><selectable id="fcs_cop.1.1_SigVer_6" >192</selectable><selectable id="fcs_cop.1.1_SigVer_7" >256</selectable></selectables> bits that meets the following: [NIST SP 800-208, "Recommendation for Stateful Hash-Based Signature Schemes"]</selectable><selectable id="fcs_cop.1.1_SigVer_8" ><h:b>Module-Lattice-Based Digital Signature Standard</h:b> using the parameter set ML-DSA-87 that meets the following [FIPS 204, Module-Lattice-Based Digital Signature Standard]</selectable></selectables> </selectable><selectable id="fcs_cop.1.1_SigVer_9">CNSA 1.0 Compliant Algorithms: <selectables linebreak="yes"><selectable id="fcs_cop.1.1_SigVer_10" ><h:b>RSA schemes</h:b> using cryptographic key sizes of [3072-bit or greater] that meet the following: [FIPS PUB 186-5, โ€œDigital Signature Standard (DSS),โ€ Section 5]</selectable><selectable id="fcs_cop.1.1_SigVer_11"><h:b>ECDSA schemes</h:b> using [โ€œNIST curvesโ€ <selectables><selectable id="fcs_cop.1.1_SigVer_12" >P-384</selectable><selectable id="fcs_cop.1.1_SigVer_13" >P-521</selectable></selectables> ] that meet the following: [FIPS PUB 186-5, โ€œDigital Signature Standard (DSS),โ€ Section 6]</selectable></selectables> </selectable> </selectables>. + This is dependent on implementing cryptographic functionality, as in FTP_DIT_EXT.1.The ST author should choose the algorithm implemented to perform digital signatures; if more than one algorithm is available, this requirement should be iterated to specify the functionality. For the algorithm chosen, the ST author should make the appropriate assignments/selections to specify the parameters that are implemented for that algorithm.Note ML-DSA is not able to be used in any functions at the time of publication, it is being added for future support. As support is expanded for CNSA 2.0, CNSA 1.0 will be removed as an selection in a future update. + + + The evaluator shall perform the following activities based on the selections in the ST. + + None. + The evaluator shall verify the guidance documentation contains any information required for configuring the algorithm or size. + + The following tests require the developer to provide access to a test application that provides the evaluator with tools that are typically not found in the production application. + + ECDSA Algorithm Test + ECDSA FIPS 186-5 Signature Verification Test. For each supported NIST curve (i.e., P-384 and P-521) and SHA function pair, the evaluator shall generate a set of 10 1024-bit message, public key and signature tuples and modify one of the values (message, public key or signature) in five of the 10 tuples. The evaluator shall obtain in response a set of 10 PASS/FAIL values. + + + RSA Signature Algorithm Test + Signature Verification Test. The evaluator shall perform the Signature Verification test to verify the ability of the TOE to recognize another partyโ€™s valid and invalid signatures. The evaluator shall inject errors into the test vectors produced during the Signature Verification Test by introducing errors in some of the public keys, e, messages, IR format, and/or signatures. The TOE attempts to verify the signatures and returns success or failure. + + + LMS/XMSS Signature Algorithm Test + For each supported LMS/LMSOTS pair, the evaluator generates a private/public key pair. With the private key, the evaluator generates 4 messages of length 1024 bits. The messages and public key are provided to the TOE. The signature for each message is generated with the following error types "none", โ€œmodify messageโ€, โ€œmodify signatureโ€, โ€œmodify headerโ€. For "none" the message is unmodified and the signature is correct. For "modify message" the signature is for a modified message where a single bit is flipped. For "modify signature", one bit of the signature is flipped. For "modify header" the signature uses a different LMS/LMSOTS pair. Each error type is represented. For each message, signature pair the TOE returns "true" or "false" depending on whether the signature verifies or not. + + + ML-DSA Test + The evaluator shall 10x input to the internal SigVer function, a public key, message and signature. Verify the signature. Tests should involve a mix of good and bad signatures generated using different messages, keys, etc. Here internal SigVer refers to the TOEโ€™s implementation of the function ML-DSA.Verify_internal(-,-,-) as described in FIPS.204. + + + + + + + + + + + + + + The <h:b>application</h:b> shall <selectables><selectable id="fcs_cop.1.1_SKC_1" >perform</selectable><selectable id="fcs_cop.1.1_SKC_2" >invoke the platform to perform</selectable> </selectables> [<h:i>encryption and decryption</h:i>] in accordance with a specified cryptographic algorithm <selectables linebreak="yes"><selectable id="sel_aes_cbc" >AES-CBC (as defined in NIST SP 800-38A) mode</selectable><selectable id="sel_aes_gcm" >AES-GCM (as defined in NIST SP 800-38D) mode</selectable><selectable id="sel_aes_xts" >AES-XTS (as defined in NIST SP 800-38E) mode</selectable><selectable id="sel_aes_ccm" >AES-CCM (as defined in NIST SP 800-38C) mode</selectable><selectable id="sel_aes_ctr" >AES-CTR (as defined in NIST SP 800-38A) mode</selectable> </selectables> and cryptographic key size of [<h:i>256-bits</h:i>]. + This is dependent on implementing cryptographic functionality, as in FTP_DIT_EXT.1.For the selection, the ST author should choose the mode or modes in which AES operates.It is expected that symmetric keys will be generated or imported by the TSF as a dependency on this function, so FCS_CKM.1/SK must be claimed when this SFR is claimed. FCS_SNI_EXT.1 must also be claimed to define what, if any, salts the cryptographic algorithm implementation uses. + + Conditional: If AES-GCM is selected, the evaluator shall verify the tag length is described in the TSS and that a tag length of at least 128 is used unless the following "Appendix C: Requirements and Guidelines for Using Short Tags" is being followed from NIST SP 800-38D. + The evaluator checks the guidance documents to determine that any configuration that is required to be done to configure the functionality for the required modes and key size is present. + The evaluator shall perform all of the following tests for each algorithm implemented by the TSF and used to satisfy the requirements of this PP: AES-CBC Known Answer Tests There are four Known Answer Tests (KATs), described below. In all KATs, the plaintext, ciphertext, and IV values shall be 128-bit blocks. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. KAT-1. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of 5 plaintext values and obtain the ciphertext value that results from AES-CBC encryption of the given plaintext using a key value of all zeros and an IV of all zeros. Five plaintext values shall be encrypted with a 256-bit all- zeros key. To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using 10 ciphertext values as input and AES-CBC decryption.KAT-2. To test the encrypt functionality of AES-CBC, the evaluator shall supply a set of 5 key values and obtain the ciphertext value that results from AES-CBC encryption of an all-zeros plaintext using the given key value and an IV of all zeros. The keys shall be 256-bit keys. To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using an all-zero ciphertext value as input and AES-CBC decryption.KAT-3. To test the encrypt functionality of AES-CBC, the evaluator shall supply the set of key values described below and obtain the ciphertext value that results from AES encryption of an all-zeros plaintext using the given key value and an IV of all zeros. The set of keys shall have 256-bit keys. Key i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1,N]. To test the decrypt functionality of AES-CBC, the evaluator shall supply the sets of key and ciphertext value pairs described below and obtain the plaintext value that results from AES-CBC decryption of the given ciphertext using the given key and an IV of all zeros. The set of key/ciphertext pairs shall have 256-bit key/ciphertext pairs. Key i in each set shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1,N]. The ciphertext value in each pair shall be the value that results in an all-zeros plaintext when decrypted with its corresponding key.KAT-4. To test the encrypt functionality of AES-CBC, the evaluator shall supply the set of 128 plaintext values described below and obtain the ciphertext values that result from AES-CBC encryption of the given plaintext using a 256-bit key value of all zeros with an IV of all zeros. Plaintext value i in each set shall have the leftmost i bits be ones and the rightmost 128-i bits be zeros, for i in [1,128]. To test the decrypt functionality of AES-CBC, the evaluator shall perform the same test as for encrypt, using ciphertext values of the same form as the plaintext in the encrypt test as input and AES-CBC decryption. AES-CBC Multi-Block Message Test The evaluator shall test the encrypt functionality by encrypting an i-block message where 1 < i โ€Œโ€Œ<= 10. The evaluator shall choose a key, an IV and plaintext message of length i blocks and encrypt the message, using the mode to be tested, with the chosen key and IV. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation. The evaluator shall also test the decrypt functionality for each mode by decrypting an i-block message where 1 < i โ€Œโ€Œ<=10. The evaluator shall choose a key, an IV and a ciphertext message of length i blocks and decrypt the message, using the mode to be tested, with the chosen key and IV. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key and IV using a known good implementation. AES-CBC Monte Carlo Tests The evaluator shall test the encrypt functionality using a set of 100 plaintext, IV, and key 3-tuples. 100 of these shall use shall use 256-bit keys. The plaintext and IV values shall be 128-bit blocks. For each 3-tuple, 1000 iterations shall be run as follows: # Input: PT, IV, Key +for i = 1 to 1000: + if i == 1: + CT[1] = AES-CBC-Encrypt(Key, IV, PT) + PT = IV + else: + CT[i] = AES-CBC-Encrypt(Key, PT) + PT = CT[i-1] The ciphertext computed in the 1000th iteration (i.e., CT[1000]) is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation. The evaluator shall test the decrypt functionality using the same test as for encrypt, exchanging CT and PT and replacing AES-CBC-Encrypt with AES-CBC-Decrypt. AES-GCM Monte Carlo Tests The evaluator shall test the authenticated encrypt functionality of AES-GCM for each combination of the following input parameter lengths: 256-bit keysTwo plaintext lengths. One of the plaintext lengths shall be a non-zero integer multiple of 128 bits, if supported. The other plaintext length shall not be an integer multiple of 128 bits, if supported.Three AAD lengths. One AAD length shall be 0, if supported. One AAD length shall be a non-zero integer multiple of 128 bits, if supported. One AAD length shall not be an integer multiple of 128 bits, if supported.Two IV lengths. If 96 bit IV is supported, 96 bits shall be one of the two IV lengths tested. The evaluator shall test the encrypt functionality using a set of 10 key, plaintext, AAD, and IV tuples for each combination of parameter lengths above and obtain the ciphertext value and tag that results from AES-GCM authenticated encrypt. Each supported tag length shall be tested at least once per set of 10. The IV value may be supplied by the evaluator or the implementation being tested, as long as it is known. The evaluator shall test the decrypt functionality using a set of 10 key, ciphertext, tag, AAD, and IV 5-tuples for each combination of parameter lengths above and obtain a Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall include five tuples that Pass and five that Fail. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. AES-XTS Tests The evaluator shall test the encrypt functionality of XTS-AES for each combination of the following input parameter lengths: 512 bit (for AES-256) keys Three data unit (i.e., plaintext) lengths. One of the data unit lengths shall be a non-zero integer multiple of 128 bits, if supported. One of the data unit lengths shall not be an integer multiple of 128 bits, if supported. The third data unit length shall be either the longest supported data unit length or 216 bits, whichever is smaller. Using a set of 100 (key, plaintext and 128-bit random tweak value) 3-tuples, the evaluator shall obtain the ciphertext that results from XTS-AES encrypt. The evaluator may supply a data unit sequence number instead of the tweak value if the implementation supports it. The data unit sequence number is a base-10 number ranging between 0 and 255 that implementations convert to a tweak value internally. The evaluator shall test the decrypt functionality of XTS-AES using the same test as for encrypt, replacing plaintext values with ciphertext values and XTS-AES encrypt with XTS-AES decrypt. AES-CCM Tests It is not recommended that evaluators use values obtained from static sources such as http://csrc.nist.gov/groups/STM/cavp/documents/mac/ccmtestvectors.zip or use values not generated expressly to exercise the AES-CCM implementation. The evaluator shall test the generation-encryption and decryption-verification functionality of AES-CCM for the following input parameter and tag lengths: Keys: All supported and selected key sizes (e.g., 256 bits).Associated Data: Two or three values for associated data length: The minimum (โ‰ฅ 0 bytes) and maximum (โ‰ค 32 bytes) supported associated data lengths, and 2^16 (65536) bytes, if supported.Payload: Two values for payload length: The minimum (โ‰ฅ 0 bytes) and maximum (โ‰ค 32 bytes) supported payload lengths.Nonces: All supported nonce lengths (7, 8, 9, 10, 11, 12, 13) in bytes.Tag: All supported tag lengths (4, 6, 8, 10, 12, 14, 16) in bytes. The testing for CCM consists of five tests. To determine correctness in each of the below tests, the evaluator shall compare the ciphertext with the result of encryption of the same inputs with a known good implementation. Variable Associated Data Test For each supported key size and associated data length, and any supported payload length, nonce length, and tag length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext. Variable Payload Test For each supported key size and payload length, and any supported associated data length, nonce length, and tag length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext. Variable Nonce Test For each supported key size and nonce length, and any supported associated data length, payload length, and tag length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext. Variable Tag Test For each supported key size and tag length, and any supported associated data length, payload length, and nonce length, the evaluator shall supply one key value, one nonce value, and 10 pairs of associated data and payload values, and obtain the resulting ciphertext. Decryption-Verification Process Test To test the decryption-verification functionality of AES-CCM, for each combination of supported associated data length, payload length, nonce length, and tag length, the evaluator shall supply a key value and 15 sets of input plus ciphertext, and obtain the decrypted payload. Ten of the 15 input sets supplied should fail verification and five should pass. AES-CTR Tests Test 1: Known Answer Tests (KATs) There are four Known Answer Tests (KATs) described below. For all KATs, the plaintext, IV, and ciphertext values shall be 128-bit blocks. The results from each test may either be obtained by the validator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator shall compare the resulting values to those obtained by submitting the same inputs to a known good implementation. KAT-1. To test the encrypt functionality, the evaluator shall supply a set of 5 plaintext values and obtain the ciphertext value that results from encryption of the given plaintext using a key value of all zeros and an IV of all zeros. Five plaintext values shall be encrypted with a 256-bit all zeros key. To test the decrypt functionality, the evaluator shall perform the same test as for encrypt, using 5 ciphertext values as input.KAT-2. To test the encrypt functionality, the evaluator shall supply a set of 5 key values and obtain the ciphertext value that results from encryption of an all zeros plaintext using the given key value and an IV of all zeros. Five of the key values shall be 256-bit keys. To test the decrypt functionality, the evaluator shall perform the same test as for encrypt, using an all zero ciphertext value as input.KAT-3. To test the encrypt functionality, the evaluator shall supply the key values described below and obtain the ciphertext values that result from AES encryption of an all zeros plaintext using the given key values an an IV of all zeros. The set of keys shall have 256 256-bit keys. Key_i shall have the leftmost i bits be ones and the rightmost N-i bits be zeros, for i in [1, N]. To test the decrypt functionality, the evaluator shall supply the key and ciphertext value pairs described below and obtain the plaintext value that results from decryption of the given ciphertext using the given key values and an IV of all zeros. The first set of key/ciphertext pairs shall have 256 256-bit pairs. Key_i shall have the leftmost i bits be ones and the rightmost N-i bits be zeros for i in [1, N]. The ciphertext value in each pair shall be the value that results in an all zeros plaintext when decrypted with its corresponding key.KAT-4. To test the encrypt functionality, the evaluator shall supply the set of 128 plaintext values described below and obtain the ciphertext values that result from encryption of the given plaintext using a 256-bit key value of all zeros, and an IV of all zeros. Plaintext value i in each set shall have the leftmost bits be ones and the rightmost 128-i bits be zeros, for i in [1, 128]. To test the decrypt functionality, the evaluator shall perform the same test as for encrypt, using ciphertext values of the same form as the plaintext in the encrypt test as input. Test 2: Multi-Block Message Test The evaluator shall test the encrypt functionality by encrypting an i-block message where 1 less-than i less-than-or-equal to 10. For each i the evaluator shall choose a key, IV, and plaintext message of length i blocks and encrypt the message, using the mode to be tested, with the chosen key. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation. The evaluator shall also test the decrypt functionality by decrypting an i-block message where 1 less-than i less-than-or-equal to 10. For each i the evaluator shall choose a key and a ciphertext message of length i blocks and decrypt the message, using the mode to be tested, with the chosen key. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key using a known good implementation. Test 3: Monte-Carlo Test For AES-CTR mode, perform the Monte Carlo Test for ECB Mode on the encryption engine of the counter mode implementation. There is no need to test the decryption engine. The evaluator shall test the encrypt functionality using 100 plaintext/key pairs. 100 of these shall use 256-bit keys. The plaintext values shall be 128-bit blocks. For each pair, 1000 iterations shall be run as follows: + For AES-ECB mode + # Input: PT, Key + for i = 1 to 1000: + CT[i] = AES-ECB-Encrypt(Key, PT) + PT = CT[i] + The ciphertext computed in the 1000th iteration is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation. + + + + + + + + + defines the capability of the TOE to implement HTTPS. + No specific management functions are identified. + There are no auditable events foreseen. + FCS_TLS_EXT.1 TLS Protocol + + The application shall implement the HTTPS protocol as a <selectables><selectable id="https_client" >client</selectable><selectable id="https_server_noauth" >server</selectable><selectable id="https_server_auth" >server with mutual authentication</selectable> </selectables> that complies with RFC 2818. + + The evaluator shall examine the TSS to verify that it describes the TSF's HTTPS implementation as a client, server, or both, and that if the TSF implements an HTTPS server, whether this supports mutual authentication. Additionally, the evaluator shall examine the TSS to verify that it includes enough detail is provided to explain how the implementation complies with RFC 2818. + The evaluator shall review the operational guidance to ensure that it includes any information necessary for configuring HTTPS in alignment with RFC 2818, or whether this is the default behavior of the TOE. + + + Conditional: If the TOE implements HTTPS as a client, for each HTTPS client interface, the evaluator shall attempt to establish an HTTPS connection from the TOE to an external server, observe the traffic with a packet analyzer, and verify that the connection succeeds and that the traffic is identified as TLS or HTTPS. + Conditional: If the TOE implements HTTPS as a server, for each HTTPS server interface, the evaluator shall attempt to establish an HTTPS connection to the TOE using a client, observe the traffic with a packet analyzer, and verify that the connection succeeds and that the traffic is identified as TLS or HTTPS. + + + + + + The application shall implement HTTPS using TLS as defined in the Functional Package for TLS. + This SFR is claimed when FTP_DIT_EXT.1 specifies the TOE's use + of HTTPS as a trusted protocol. If the TSF implements HTTPS as a client, or if it implements HTTPS as a server with mutual authentication, then FCS_HTTPS_EXT.2 must be claimed to specify the TSF's behavior when presented with an invalid peer certificate. + + + + + + + + + defines the TSF's response when an invalid certificate is presented as part of HTTPS connection establishment. + The following actions could be considered for the management functions in FMT:Configuration of HTTPS behavior in response to receipt of invalid certificate. + There are no auditable events foreseen. + FCS_HTTPS_EXT.1 HTTPS ProtocolFIA_X509_EXT.1 X.509 Certificate Validation + + The application shall <selectables><selectable id="fcs_https_ext.2.1_1" >establish the connection</selectable><selectable id="fcs_https_ext.2.1_2" >not establish the connection</selectable><selectable id="fcs_https_ext.2.1_3" >establish or not establish the connection based on an administrative or user setting</selectable> </selectables> if the peer certificate is deemed invalid when attempting to establish a HTTPS connection. + This SFR is claimed when the TOE implements HTTPS as a client, or when the TOE implements HTTPS as a server with support for mutual authentication. + + The evaluator shall verify that the TSS describes the TOE's behavior when an invalid peer certificate is presented to it during establishment of an HTTPS connection. + If the TOE's response to being presented with an invalid certificate is configurable, the evaluator shall verify that the operational guidance includes instructions for configuring this behavior and what the configurable options are. If this includes configuration to a permissive setting where an invalid certificate may be accepted without administrator intervention, the evaluator shall verify that the operational guidance includes sufficient warning of the potential security risks of applying this setting. + The evaluator shall attempt to establish an HTTPS connection using the + TOE, present an invalid peer certificate, and verify that the TSF behaves in the manner specified in the TSF in response. If this behavior is configurable, the evaluator shall iterate this test as necessary to exercise each configuration option and verify that the TSF behaves in the configured manner. Other tests are performed in conjunction with the Functional Package for Transport Layer Security (TLS), version 2.1 and the + Functional Package for X.509. + + + + + + + defines the capability of the TOE to implement PBKDF2 for key derivation. + No specific management functions are identified. + There are no auditable events foreseen. + FCS_COP.1 Cryptographic OperationFCS_RBG_EXT.1 Random Bit Generation Services + + The application shall condition passwords/passphrases with <assignable>Password-based Key Derivation Functions</assignable> in accordance with a specified cryptographic algorithm as specified in FCS_COP.1 <h:b>/KeyedHash</h:b>, with <selectables><selectable id="fcs_pbkdf_ext.1.1_2" ><assignable>positive integer between 1,000 and 9,999</assignable></selectable><selectable id="fcs_pbkdf_ext.1.1_3" ><assignable>positive integer between 1,0000 and 199,999</assignable></selectable><selectable id="fcs_pbkdf_ext.1.1_4" ><assignable>positive integer greater than 200,000</assignable></selectable> </selectables> iterations, and output size of <assignable>positive integer of 256 or greater</assignable> bits that meet the following [<h:i>NIST SP 800-132</h:i>]. + The application shall condition passwords/passphrases with + <assignable>Password-based Key Derivation Functions </assignable> in accordance with a specified cryptographic algorithm as specified in FCS_COP.1, with <assignable>positive integer of 1,000 or greater </assignable> iterations, and output cryptographic key sizes <assignable>positive integer of 256 of greater </assignable> bits that meet the following <assignable>applicable standard </assignable>. + + Support for PBKDF: The evaluator shall examine the password hierarchy described in the TSS to ensure that the formation of all password based derived keys is described and that the key sizes match that described by the ST author. The evaluator shall check that the TSS describes the method by which the password/passphrase is first encoded and then fed to the SHA algorithm. The settings for the algorithm (padding, blocking, etc.) shall be described, and the evaluator shall verify that these are supported by the selections in this component as well as the selections concerning the hash function itself. The evaluator shall verify that the TSS contains a description of how the output of the hash function is used to form the submask that will be input into the function. For the NIST SP 800-132-based conditioning of the password/passphrase, the required evaluation activities will be performed when doing the evaluation activities for the appropriate requirements (FCS_COP.1.1/KeyedHash). No explicit testing of the formation of the submask from the input password is required. FCS_PBKDF_EXT.1: The evaluator shall verify the TSS describes the salt size and verify that the salt size aligns with NIST SP 800-132 with a minimum random length of 128 bits. + The evaluator shall confirm the guidance documentation contains any information necessary for configuring the password conditioning if any configuration is supported. + None. + + + + The TSF shall generate salts in accordance with FCS_SNI_EXT.1 and with entropy corresponding to the security strength selected for PBKDF in FCS_PBKDF_EXT.1. + This should be included if selected in FCS_STO_EXT.1.Conditioning can be performed using one of the identified hash functions or the process described in NIST SP 800-132; the method used is selected by the ST Author. SP 800-132 requires the use of a pseudorandom function (PRF) consisting of HMAC with an approved hash function. The ST author selects the hash function used, including the appropriate requirements for HMAC and the hash function.Appendix A of SP800-132 recommends setting the number of iterations as high as can be tolerated for the environment, while maintaining acceptable performance. For unconstrained environments, this could be 200,000 or much higher. The larger the iteration count, the greater protection is against a password recovery attack due to the increase computation needed to a derive a key. This value is expected to increase to a minimum of 10,000 in a future iteration based on NIST SP 800-63. + + + + + + + The TSF shall perform deterministic random bit generation services using <selectables linebreak="yes"><selectable id="fcs_rbg.1.1_1" >Hash_DRBG (any)</selectable><selectable id="fcs_rbg.1.1_2" >HMAC_DRBG (any)</selectable><selectable id="fcs_rbg.1.1_3" >CTR_DRBG (AES)</selectable> </selectables> in accordance with [<h:i>NIST SP 800-90A</h:i>] after initialization with a seed. + NIST SP 800-90A contains three different methods of generating random numbers; each of these, in turn, depends on underlying cryptographic primitives (hash functions/ciphers). The ST author will select the function used and include the specific underlying cryptographic primitives used in the requirement or in the TSS. While any of the identified hash functions (SHA-224, SHA-256, SHA-384, SHA-512) are allowed for Hash_DRBG or HMAC_DRBG, only AES-based implementations for CTR_DRBG are allowed. + + The evaluator shall verify that the TSS identifies the DRBGs used by the TOE. + If the DRBG functionality is configurable, the evaluator shall verify that the operational guidance includes instructions on how to configure this behavior. + The evaluator shall perform the following tests: The evaluator shall perform 15 trials for the DRBG implementation. If the DRBG is configurable, the evaluator shall perform 15 trials for each configuration. The evaluator shall also confirm that the operational guidance contains appropriate instructions for configuring the DRBG functionality. If the DRBG has prediction resistance enabled, each trial consists of (1) instantiate DRBG, (2) generate the first block of random bits (3) generate a second block of random bits (4) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 โ€“ 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The next two are additional input and entropy input for the first call to generate. The final two are additional input and entropy input for the second call to generate. These values are randomly generated. "generate one block of random bits" means to generate random bits with number of returned bits equal to the Output Block Length (as defined in NIST SP 800-90A). If the DRBG does not have prediction resistance, each trial consists of (1) instantiate DRBG, (2) generate the first block of random bits (3) reseed, (4) generate a second block of random bits (5) uninstantiate. The evaluator verifies that the second block of random bits is the expected value. The evaluator shall generate eight input values for each trial. The first is a count (0 โ€“ 14). The next three are entropy input, nonce, and personalization string for the instantiate operation. The fifth value is additional input to the first call to generate. The sixth and seventh are additional input and entropy input to the call to reseed. The final value is additional input to the second generate call. The following list contains more information on some of the input values to be generated/selected by the evaluator.Entropy input: The length of the entropy input value must equal the seed length.Nonce: If a nonce is supported (CTR_DRBG with no Derivation Function does not use a nonce), the nonce bit length is one-half the seed length.Personalization string: The length of the personalization string must be less than or equal to seed length. If the implementation only supports one personalization string length, then the same length can be used for both values. If more than one string length is support, the evaluator shall use personalization strings of two different lengths. If the implementation does not use a personalization string, no value needs to be supplied.Additional input: The additional input bit lengths have the same defaults and restrictions as the personalization string lengths. + + + + The TSF shall use a <selectables><selectable id="internal-seed">TSF noise source <assignable>name of noise source</assignable> </selectable><selectable id="internal-seeds"><h:b>multiple TSF noise sources <assignable>names of noise sources</assignable> </h:b></selectable><selectable id="external-seed" >TSF interface for seeding</selectable> </selectables> for initialized seeding. + For the selection in this requirement, the ST author selects "TSF noise source" if a single noise source is used as input to the DRBG. The ST author selects "multiple TSF noise sources" if a seed is formed from a combination of two or more noise sources within the TOE boundary. If the TSF implements two or more separate DRBGs that are seeded in separate manners, this SFR should be iterated for each DRBG. If multiple distinct noise sources exist such that each DRBG only uses one of them, then each iteration would select "TSF noise source"; "multiple TSF noise sources" is only selected if a single DRBG uses multiple noise sources for its seed. The ST author selects "TSF interface for seeding" if noise source data is generated outside the TOE boundary.If "TSF noise source" is selected, FCS_RBG.3 must be claimed.If "multiple TSF noise sources" is selected, FCS_RBG.4 and FCS_RBG.5 must be claimed.If "TSF interface for seeding" is selected, FCS_RBG.2 must be claimed. + + + Documentation will be produced - and the evaluator shall perform the activities - in accordance with Appendix D - Entropy Documentation and Assessment appendix and the Clarification to the Entropy Documentation and Assessment Annex. + + + + + + + + The TSF shall update the RBG state by <selectables><selectable id="fcs_rbg.1.3_1" >reseeding</selectable><selectable id="fcs_rbg.1.3_2" >uninstantiating and reinstantiating</selectable> </selectables> using a <selectables><selectable id="fcs_rbg.1.3_3">TSF noise source <assignable>name of noise source</assignable> </selectable><selectable id="fcs_rbg.1.3_5" >TSF interface for seeding</selectable> </selectables> in the following situations: <selectables linebreak="yes"><selectable id="fcs_rbg.1.3_6" >on demand</selectable><selectable id="fcs_rbg.1.3_7">on the condition: <assignable>condition</assignable> </selectable><selectable id="fcs_rbg.1.3_9">after <assignable>time</assignable> </selectable> </selectables> in accordance with <assignable>list of standards</assignable>. + + The evaluator shall verify that the TSS identifies how the DRBG state is updated, and the situations under which this may occur. + If the ST claims that the DRBG state can be updated on demand, the evaluator shall verify that the operational guidance has instructions for how to perform this operation. + + + + + + + + + The TSF shall be able to accept a minimum input of <assignable>minimum input length, in bits, greater than zero</assignable> from a TSF interface for the purpose of seeding. + This requirement is claimed when a DRBG is seeded with entropy from one or more noise sources that are outside the TOE boundary. Typically the entropy produced by an environmental noise source is conditioned such that the input length has full entropy and is therefore usable as the seed. However, if this is not the case, it should be noted what the minimum entropy rate of the noise source is so that the TSF can collect a sufficiently large sample of noise data to be conditioned into a seed value. + + + The evaluator shall examine the entropy documentation required by FCS_RBG.1.2 to verify that it identifies, for each DRBG function implemented by the TOE, the TSF external interface used to seed the TOE's DRBG. The evaluator shall verify that this includes the amount of sampled data and the min-entropy rate of the sampled data such that it can be determined that sufficient entropy can be made available for the highest strength keys that the TSF can generate (e.g., 256 bits). If the seed data cannot be assumed to have full entropy (e.g., the min-entropy of the sampled bits is less than 1), the evaluator shall ensure that the entropy documentation describes the method by which the TOE estimates the amount of entropy that has been accumulated to ensure that sufficient data is collected and any conditioning that the TSF applies to the output data to create a seed of sufficient size with full entropy. + + + + + + + + + + + + The TSF shall be able to seed the RBG using a TSF software-based noise source with a minimum of <assignable>number of bits</assignable> bits of min-entropy. + This requirement is claimed when a DRBG is seeded with entropy from a single noise source that is within the TOE boundary. Min-entropy should be expressed as a ratio of entropy bits to sampled bits so that the total amount of data needed to ensure full entropy is known, as well as the conditioning function by which that data is reduced in size to the seed. + + + The evaluator shall examine the entropy documentation required by FCS_RBG.1.2 to verify that it identifies, for each DRBG function implemented by the TOE, the TSF noise source used to seed the TOE's DRBG. The evaluator shall verify that this includes the amount of sampled data and the min-entropy rate of the sampled data such that it can be determined that sufficient entropy can be made available for the highest strength keys that the TSF can generate (e.g., 256 bits). If the seed data cannot be assumed to have full entropy (e.g., the min-entropy of the sampled bits is less than 1), the evaluator shall ensure that the entropy documentation describes the method by which the TOE estimates the amount of entropy that has been accumulated to ensure that sufficient data is collected and any conditioning that the TSF applies to the output data to create a seed of sufficient size with full entropy. + + + + + + + + + + + + The TSF shall be able to seed the RBG using <assignable>number</assignable> TSF software-based noise source(s). + This requirement is claimed when a DRBG is seeded with entropy from multiple noise sources that are within the TOE boundary. FCS_RBG.5 defines the mechanism by which these sources are combined to ensure sufficient minimum entropy. + + + The evaluator shall examine the entropy documentation required by FCS_RBG.1.2 to verify that it identifies, for each DRBG function implemented by the TOE, each TSF noise source used to seed the TOE's DRBG. The evaluator shall verify that this includes the amount of sampled data and the min-entropy rate of the sampled data from each data source. + + + + + + + + + + + + The TSF shall <assignable>combining operation</assignable> + <selectables><selectable id="fcs_rbg.5.1_2" >output from TSF noise source(s)</selectable><selectable id="fcs_rbg.5.1_3" >input from TSF interface(s) for seeding</selectable> </selectables> to create the entropy input into the derivation function as defined in <assignable>list of standards</assignable>, resulting in a minimum of <assignable>number of bits</assignable> bits of min-entropy. + Examples of typical combining operations include, but are not limited to, XORing or hashing. + + + Using the entropy sources specified in FCS_RBG.4, the evaluator shall examine the entropy documentation required by FCS_RBG.1.2 to verify that it describes the method by which the various entropy sources are combined into a single seed. This should include an estimation of the rate at which each noise source outputs data and whether this is dependent on any system-specific factors so that each source's relative contribution to the overall entropy is understood. The evaluator shall verify that the resulting combination of sampled data and the min-entropy rate of the sampled data is described in sufficient detail to determine that sufficient entropy can be made available for the highest strength keys that the TSF can generate (e.g., 256 bits). If the seed data cannot be assumed to have full entropy (e.g., the min-entropy of the sampled bits is less than 1), the evaluator shall ensure that the entropy documentation describes the method by which the TOE estimates the amount of entropy that has been accumulated to ensure that sufficient data is collected and any conditioning that the TSF applies to the output data to create a seed of sufficient size with full entropy. + + + + + + + + + + requires the TSF to specify whether random bit generation is implemented by the TSF, invoked from the operational environment, or not used by the TOE. + No specific management functions are identified. + There are no auditable events foreseen. + No dependencies. + + The application shall <selectables linebreak="yes"><selectable id="fcs_rbg_ext.1.1_1" exclusive="yes">use no DRBG functionality</selectable><selectable id="fcs_rbg_ext.1.1_2" >invoke platform-provided DRBG functionality</selectable><selectable id="drbg" >implement DRBG functionality</selectable> </selectables> for its cryptographic operations. + The selection "invoke platform-provided DRBG functionality" should only be chosen for direct invocations of the platform DRBG by the TSF.The selection "use no DRBG functionality" is chosen when the TSF calls a platform implementation of a function that subsequently calls a platform-provided DRBG itself, because this is not a direct invocation of the platform DRBG by the TSF.If "implement DRBG functionality" is selected, FCS_RBG.1 must be claimed for the DRBG mechanism, and FPT_TST.1 and FPT_FLS.1 must be claimed for the self-testing and error handling of this mechanism.In this requirement, cryptographic operations include all cryptographic key generation/derivation/agreement, IVs (for certain modes), as well as protocol-specific random values. Cryptographic operations in this requirement refer to the other cryptographic requirements in this PP, not additional functionality that is not in scope. + + If "use no DRBG functionality" is selected, the evaluator shall inspect the application and its developer documentation and verify that the application needs no random bit generation services.If "implement DRBG functionality" is selected, the evaluator shall ensure that FCS_RBG.1 is claimed.If "invoke platform-provided DRBG functionality" is selected, the evaluator performs the following activities. The evaluator shall examine the TSS to confirm that it identifies all functions (as described by the SFRs included in the ST) that obtain random numbers from the platform RBG. The evaluator shall determine that for each of these functions, the TSS states which platform interface (API) is used to obtain the random numbers. The evaluator shall confirm that each of these interfaces corresponds to the acceptable interfaces listed for each platform below.It should be noted that there is no expectation that the evaluators attempt to confirm that the APIs are being used correctly for the functions identified in the TSS; the activity is to list the used APIs and then do an existence check via decompilation. + The evaluator shall verify the guidance documentation contains any information required for configuring the DRBG. + + If "invoke platform-provided DRBG functionality" is selected, the following tests shall be performed: The evaluator shall decompile the application binary using a decompiler suitable for the application (TOE). The evaluator shall search the output of the decompiler to determine that, for each API listed in the TSS, that API appears in the output. If the representation of the API does not correspond directly to the strings in the following list, the evaluator shall provide a mapping from the decompiled text to its corresponding API, with a description of why the API text does not directly correspond to the decompiled text and justification that the decompiled text corresponds to the associated API. The following are the per-platform list of acceptable APIs: + + + + + The evaluator shall verify that the application uses at least one of javax.crypto.KeyGenerator class or the java.security.SecureRandom class or /dev/random or /dev/urandom. + + + + + + + + The evaluator shall verify that rand_s, RtlGenRandom, BCryptGenRandom, or CryptGenRandom API is used for classic desktop applications. The evaluator shall verify the application uses the RNGCryptoServiceProvider class or derives a class from System.Security.Cryptography.RandomNumberGenerator API for Windows Universal Applications. It is only required that the API is called/invoked, there is no requirement that the API be used directly. In future versions of this document, CryptGenRandom may be removed as an option as it is no longer the preferred API per vendor documentation. + + + + + + + + The evaluator shall verify that the application invokes either SecRandomCopyBytes, CCRandomGenerateBytes, or CCRandomCopyBytes, or uses /dev/random directly to acquire random. + + + + + + + + The evaluator shall verify that the application collects random from /dev/random or /dev/urandom. + + + + + + + + The evaluator shall verify that the application collects random from /dev/random. + + + + + + + + The evaluator shall verify that the application invokes either CCRandomGenerateBytes or CCRandomCopyBytes, or collects random from /dev/random. + + + + If invocation of platform-provided functionality is achieved in another way, the evaluator shall ensure the TSS describes how this is carried out, and how it is equivalent to the methods listed here (e.g. higher-level API invokes identical low-level API). + + + + + + + + + + + + + requires the application to define how to generate salt, nonces, and initialization vectors + No specific management functions are identified. + There are no auditable events foreseen. + No dependencies. + + The application shall <selectables><selectable id="fcs_sni_ext.1.1_1" >use no salts</selectable><selectable id="fcs_sni_ext.1.1_2" >use salts that are generated by a DRBG as specified in FCS_RBG_EXT.1</selectable> </selectables> + + If salts are used, the evaluator shall ensure the TSS describes how salts are generated. The evaluator shall confirm that the salt is generating using an RBG described in FCS_RBG_EXT.1.If nonces are used the evaluator shall ensure the TSS describes how nonces are created verify they are a minimum of 64 bits in size.If initialization vectors (IV) are used the evaluator shall ensure the TSS describes how IVs and tweaks are handled based on the AES mode. The evaluator shall confirm that the IVs and tweaks meet the stated requirements for each AES mode.If using a GCM IV, the evaluator shall confirm the TSS describes the GCM IV construction and that it matches one of two allowed construction methods given in Section 8.2 of SP800-38D. + None. + None. + + + + The application shall use <selectables><selectable id="fcs_sni_ext.1.2_1" >no nonces</selectable><selectable id="fcs_sni_ext.1.2_2" >unique nonces with a minimum size of [<h:i>64</h:i>] bits.</selectable> </selectables> + + + The application shall <selectables><selectable id="fcs_sni_ext.1.3_1" >use no IVs</selectable><selectable id="fcs_sni_ext.1.3_2">create IVs in the following manner <selectables linebreak="yes"><selectable id="fcs_sni_ext.1.3_3" >CBC: IVs shall be non-repeating and unpredictable;</selectable><selectable id="fcs_sni_ext.1.3_4" >CCM: Nonce shall be non-repeating;</selectable><selectable id="fcs_sni_ext.1.3_5" >CTR: "Initial Counter" shall be non-repeating. No counter value shall be repeated across multiple messages with the same secret key.</selectable><selectable id="fcs_sni_ext.1.3_6" >XTS: No IV. Tweak values shall be non-negative integers, assigned consecutively, and starting at an arbitrary non-negative integer;</selectable><selectable id="fcs_sni_ext.1.3_7" >GCM: IV shall be non-repeating. The number of invocations of GCM shall not exceed 2^32 for a given secret key. The IV constructed using one of two allowed construction methods given in Section 8.2 of NIST SP 800-38D.</selectable></selectables> </selectable> </selectables> + This requirement ensures that salts, nonces, and initialization vectors are properly implemented. If the application is implementing a salt, nonce, or initialization vector they must select the corresponding selection. If the platform implements these functions, the corresponding "use no..." options are selected.This requirement is dependent on selecting "implement functionality to securely store..." in FCS_STO_EXT.1.1 or any AES selection in FCS_COP.1.1/SKC. + + + + + requires the application to define how to store credentials to non-volatile memory. + No specific management functions are identified. + There are no auditable events foreseen. + No dependencies. + + The application shall <selectables linebreak="yes"><selectable id="fcs_sto_ext.1.1_1" exclusive="yes">not store any credentials</selectable><selectable id="fcs_sto_ext.1.1_2">invoke the functionality provided by the platform to securely store <assignable>list of credentials</assignable> </selectable><selectable id="sel_plat_sto">securely store <assignable>list of credentials</assignable> with platform provided <selectables><selectable id="fcs_sto_ext.1.1_5"> <selectables linebreak="yes"><selectable id="fcs_sto_ext.1.1_6" >AES-CBC (as defined in NIST SP 800-38A) mode</selectable><selectable id="fcs_sto_ext.1.1_7" >AES-GCM (as defined in NIST SP 800-38D) mode</selectable><selectable id="fcs_sto_ext.1.1_8" >AES-XTS (as defined in NIST SP 800-38E) mode</selectable></selectables> and cryptographic key size of 256-bits.</selectable><selectable id="fcs_sto_ext.1.1_9">PBKDF2 function that uses <selectables linebreak="yes"><selectable id="fcs_sto_ext.1.1_10" >HMAC-SHA256</selectable><selectable id="fcs_sto_ext.1.1_11" >HMAC-SHA384</selectable><selectable id="fcs_sto_ext.1.1_12" >HMAC-SHA512</selectable></selectables> with <assignable>positive integer of 1,000 or greater</assignable> iterations and output cryptographic key size of <assignable>positive integer of 256 of greater</assignable> bits that meet the following [<h:i>NIST SP 800-132</h:i>].</selectable></selectables> </selectable><selectable id="sel_impl_sto">implement functionality to securely store <assignable>list of credentials</assignable> according to <selectables><selectable id="sel-fcs-sto-skc" >FCS_COP.1/SKC</selectable><selectable id="sel-fcs-sto-pbkdf" >FCS_PBKDF_EXT.1</selectable></selectables> </selectable> </selectables> to non-volatile memory. + The application shall <selectables linebreak="yes"><selectable exclusive="yes">not store any credentials </selectable> <selectable>invoke the functionality provided by the platform to securely store <assignable>list of credentials </assignable> </selectable> <selectable>implement functionality to securely store <assignable>list of credentials </assignable> according to <assignable>cryptographic mechanisms </assignable> </selectable> </selectables> to non-volatile memory. + This requirement ensures that persistent credentials (secret keys, PKI private keys, passwords, etc) are stored securely, and never persisted in cleartext form. Application developers are encouraged to use platform mechanisms for the secure storage of credentials. Depending on the platform that may include hardware-backed protection for credential storage. Application developers must choose a selection, or multiple selections, based on all credentials that the application stores. If "not store any credentials" is selected, then the application must not store any credentials. If "invoke the functionality provided by the platform to securely store" is selected, then the application developer must closely review the EA for their platform and provide documentation indicating which platform mechanisms are used to store credentials. If "securely store" is selected, the application shall leverage platform cryptographic APIs to implement storage of credentials. If "implement functionality to securely store credentials" is selected, then the following components must be included in the ST: (FCS_COP.1/SKC and FCS_SNI_EXT.1) or FCS_PBKDF_EXT.1. If the OS is Linux and Java KeyStores are used to store credentials, "implement functionality to securely store credentials" must be selected. + + The evaluator shall check the TSS to ensure that it lists all persistent credentials (secret keys, PKI private keys, or passwords) needed to meet the requirements in the ST. For each of these items, the evaluator shall confirm that the TSS lists for what purpose it is used, and how it is stored.If not store any credentials is selected, the evaluator shall verify the TSS describes the behavior of the TOE in sufficient detail to verify that the TSF does not have any behavior that would require any credentials to be stored (e.g., because the TOE does not have any functionality requiring authentication).If securely store is selected, the evaluator shall verify the TSS contains the platform functions utilized and verify those functions are documented by the platform to be non-deprecated functions meeting the specifications in the requirement.If invoke the functionality provided by the platform to securely store is selected, the evaluator shall confirm the TSS describes how the platform storage is invoked for each supported platform. The evaluator shall confirm the invocation of the platform is using non-deprecated functions provided by the platform(s). + None. + + For all credentials for which the application implements functionality, the evaluator shall verify credentials are encrypted according to FCS_COP.1/SKC or conditioned according to FCS_PBKDF_EXT.1. For all credentials for which the application invokes platform-provided functionality, the evaluator shall perform the following actions which vary per platform. + + + + + The evaluator shall verify that the application uses the Android KeyStore or the Android KeyChain to store certificates. + + + + + + + + The evaluator shall verify that all certificates are stored in the Windows Certificate Store. The evaluator shall verify that other credentials, like passwords, are stored in the Windows Credential Manager or stored using the Data Protection API (DPAPI). For Windows Universal Applications, the evaluator shall verify that the application is using the ProtectData class and storing credentials in IsolatedStorage. + + + + + + + + The evaluator shall verify that all credentials are stored within a Keychain. + + + + + + + + The evaluator shall verify that all keys are stored using Linux keyrings. + + + + + + + + The evaluator shall verify that all keys are stored using Solaris Key Management Framework (KMF). + + + + + + + + The evaluator shall verify that all credentials are stored within Keychain. + + + + + + + +
+ +
+ + This family defines requirements for implementation of data-at-rest protection. + + + This family defines requirements for accessing platform resources. + + + This family defines requirements for the TOEโ€™s use of network connectivity. + + + + requires the application to be able to protect all data with a chosen method of encryption. + No specific management functions are identified. + There are no auditable events foreseen. + No dependencies. + + The application shall <selectables linebreak="yes"><selectable id="fdp_dar_ext.1.1_1" >leverage platform-provided functionality to encrypt sensitive data</selectable><selectable id="fdp_dar_ext.1.1_2" >implement functionality to encrypt sensitive data as defined in the PP-Module for File Encryption</selectable><selectable id="fdp_dar_ext.1.1_3" >protect sensitive data in accordance with FCS_STO_EXT.1</selectable><selectable id="fdp_dar_ext.1.1_4" exclusive="yes">not store any sensitive data</selectable> </selectables> in non-volatile memory. + If "implement functionality to encrypt sensitive data + as defined in the PP-Module for File Encryption" is selected, the TSF must claim + conformance to a PP-Configuration that includes the PP-Module for File Encryption.Any file that may potentially contain sensitive data (to include temporary files) shall be protected. The only exception is if the user intentionally exports the sensitive data to non-protected files. ST authors should select "protect sensitive data in accordance with FCS_STO_EXT.1" for the sensitive data that is covered by the FCS_STO_EXT.1 SFR. + + If any selection other than not store any sensitive data is + selected the evaluator shall examine the TSS to ensure that it describes the sensitive data processed by the application. The evaluator shall then ensure that the following activities cover all of the sensitive data identified in the TSS.If not store any sensitive data is selected, the evaluator shall inspect the TSS to ensure that it describes how sensitive data cannot be written to non-volatile memory. The evaluator shall also ensure that this is consistent with the file system test below.If implement functionality to encrypt sensitive data is selected the evaluator shall confirm the TSS describes how the application ensures all sensitive data is protected by the file encryption functions. If protect sensitive data in accordance with FCS_STO_EXT.1 is selected the evaluator shall confirm the TSS describes which data is protected via this mechanism and the selections within FCS_STO_EXT.1 that are leveraged. If multiple selections are included the evaluator shall ensure the TSS describes which sensitive data is captured by which selection.If "leverage platform-provided functionality..." is selected, the evaluation activities will be performed as stated in the following requirements, which vary on a per-platform basis. The evaluator shall inspect the TSS and verify that it describes how files containing sensitive data are stored with the MODE_PRIVATE flag set. The Windows platform currently does not provide data-at-rest encryption services which depend upon invocation by application developers. The evaluator shall inspect the TSS and ensure that it describes how the application uses the Complete Protection, Protected Unless Open, or Protected Until First User Authentication Data Protection Class for each data file stored locally. The Linux platform currently does not provide data-at-rest encryption services which depend upon invocation by application developers. The Solaris platform currently does not provide data-at-rest encryption services which depend upon invocation by application developers. The macOS platform currently does not provide data-at-rest encryption services which depend upon invocation by application developers. + The evaluator shall confirm the operational guidance contains any instructions necessary for configuring the storage and protection of any sensitive data.If leverage platform-provided functionality to encrypt sensitive data is selected the evaluator shall confirm the operational guidance contains the list of supported operational environments and any steps necessary to ensure the platform captures any sensitive data that is stored. + If "implement functionality to encrypt sensitive data as defined in the PP-Module for File Encryption" or "protect sensitive data in accordance with FCS_STO_EXT.1" is selected, the evaluator shall inventory the file system locations where the application may write data. The evaluator shall run the application and attempt to store sensitive data. The evaluator shall then inspect those areas of the file system to note where data was stored (if any), and verify it has been encrypted. If "leverage platform-provided functionality..." is selected no additional testing is required. + + + + + + requires the application to restrict access to hardware sources and sensitive information repositories. + The following action could be considered for the management functions in FMT:Enabling and disabling the transmission of any information describing the systemโ€™s hardware, software, or configuration. + There are no auditable events foreseen. + FCS_TLS_EXT.1 TLS ProtocolFIA_X509_EXT.1 X.509 Certificate Validation + + The application shall restrict its access to only <selectables linebreak="yes"><selectable id="fdp_dec_ext.1.1_1" exclusive="yes">no hardware resources</selectable><selectable id="fdp_dec_ext.1.1_2" >network connectivity</selectable><selectable id="fdp_dec_ext.1.1_3" >camera</selectable><selectable id="fdp_dec_ext.1.1_4" >microphone</selectable><selectable id="fdp_dec_ext.1.1_5" >location services</selectable><selectable id="fdp_dec_ext.1.1_6" >NFC</selectable><selectable id="fdp_dec_ext.1.1_7" >USB</selectable><selectable id="fdp_dec_ext.1.1_8" >Bluetooth</selectable><selectable id="fdp_dec_ext.1.1_1" ><assignable>list of additional hardware resources</assignable></selectable> </selectables>. + The intent is for the evaluator to ensure that the selection captures all hardware resources which the application accesses, and that these are restricted to those which are justified. On some platforms, the application must explicitly solicit permission in order to access hardware resources. Seeking such permissions, even if the application does not later make use of the hardware resource, should still be considered access. Selections should be expressed in a manner consistent with how the application expresses its access needs to the underlying platform. For example, the platform may provide location services which implies the potential use of a variety of hardware resources (e.g. satellite receivers, WiFi, cellular radio) yet "location services" is the proper selection. This is because use of these resources can be inferred, but also because the actual usage may vary based on the particular platform. Resources that do not need to be explicitly identified are those which are ordinarily used by any application such as central processing units, main memory, displays, input devices (e.g. keyboards, mice), and persistent storage devices provided by the platform. + + None. + The evaluator shall perform the platform-specific actions below and inspect user documentation to determine the application's access to hardware resources. The evaluator shall ensure that this is consistent with the selections indicated. The evaluator shall review documentation provided by the application developer and for each resource which it accesses, identify the justification as to why access is required. + + + + + + The evaluator shall verify that each uses-permission entry in the AndroidManifest.xml file for access to a hardware resource is reflected in the selection. + + + + + + + + For Windows Universal Applications the evaluator shall check the AppxManifest.xml file for a list of required hardware capabilities. The evaluator shall verify that the user is made aware of the required hardware capabilities when the application is first installed. This includes permissions such as ID_CAP_ISV_CAMERA, ID_CAP_LOCATION, ID_CAP_NETWORKING, ID_CAP_MICROPHONE, ID_CAP_PROXIMITY and so on. A complete list of Windows App permissions can be found at: + http://msdn.microsoft.com/en-US/library/windows/apps/jj206936.aspx For Windows Desktop Applications the evaluator shall identify in either the application software or its documentation the list of the required hardware resources. + + + + + + + + The evaluator shall verify that either the application or the documentation provides a list of the hardware resources it accesses. + + + + + + + + The evaluator shall verify that either the application software or its documentation provides a list of the hardware resources it accesses. + + + + + + + + The evaluator shall verify that either the application software or its documentation provides a list of the hardware resources it accesses. + + + + + + + + The evaluator shall verify that either the application software or its documentation provides a list of the hardware resources it accesses. + + + + + + + + The application shall restrict its access to only <selectables linebreak="yes"><selectable id="fdp_dec_ext.1.2_1" exclusive="yes">no sensitive information repositories</selectable><selectable id="fdp_dec_ext.1.2_2" >address book</selectable><selectable id="fdp_dec_ext.1.2_3" >calendar</selectable><selectable id="fdp_dec_ext.1.2_4" >call lists</selectable><selectable id="fdp_dec_ext.1.2_5" >system logs</selectable><selectable id="fdp_dec_ext.1.2_1" ><assignable>list of additional sensitive information repositories</assignable></selectable> </selectables>. + "Sensitive information repositories" are defined as those collections of sensitive data that could be expected to be shared among some applications, users, or user roles, but to which not all of these would ordinarily require access. + + None. + The evaluator shall perform the platform-specific actions below and inspect user documentation to determine the application's access to sensitive information repositories. The evaluator shall ensure that this is consistent with the selections indicated. The evaluator shall review documentation provided by the application developer and for each sensitive information repository which it accesses, identify the justification as to why access is required. + + + + + + The evaluator shall verify that each uses-permission entry in the AndroidManifest.xml file for access to a sensitive information repository is reflected in the selection. + + + + + + + + For Windows Universal Applications the evaluator shall check the AppxManifest.xml file for a list of required capabilities. The evaluator shall identify the required information repositories when the application is first installed. This includes permissions such as ID_CAP_CONTACTS,ID_CAP_APPOINTMENTS,ID_CAP_MEDIALIB and so on. A complete list of Windows App permissions can be found at: + http://msdn.microsoft.com/en-US/library/windows/apps/jj206936.aspx For Windows Desktop Applications the evaluator shall identify in either the application software or its documentation the list of sensitive information repositories it accesses. + + + + + + + + The evaluator shall verify that either the application software or its documentation provides a list of the sensitive information repositories it accesses. + + + + + + + + The evaluator shall verify that either the application software or its documentation provides a list of sensitive information repositories it accesses. + + + + + + + + The evaluator shall verify that either the application software or its documentation provides a list of sensitive information repositories it accesses. + + + + + + + + The evaluator shall verify that either the application software or its documentation provides a list of sensitive information repositories it accesses. + + + + + + + + + + identifies the purpose for each network interface used by the TOE and how that interface is invoked. + No specific management functions are identified. + There are no auditable events foreseen. + No dependencies. + + The application shall restrict network communication to <selectables linebreak="yes"><selectable id="fdp_net_ext.1.1_1" exclusive="yes">no network communication</selectable><selectable id="fdp_net_ext.1.1_2">user-initiated communication for <assignable>list of functions for which the user can initiate network communication</assignable> </selectable><selectable id="fdp_net_ext.1.1_4">respond to <assignable>list of remotely initiated communication</assignable> </selectable><selectable id="fdp_net_ext.1.1_3" ><assignable>list of application-initiated network communication</assignable></selectable> </selectables>. + This requirement is intended to restrict both inbound and outbound network communications to only those required, or to network communications that are user initiated. It does not apply to network communications in which the application may generically access the file system which may result in the platform accessing remotely mounted drives/shares. + + None. + The evaluator shall verify the guidance documents contain any instructions necessary to configure the restriction of network communications. + + The evaluator shall perform the following tests: + + The evaluator shall run the application. While the application is running, the evaluator shall sniff network traffic ignoring all non-application associated traffic and verify that any network communications witnessed are documented in the TSS or are user-initiated. + The evaluator shall run the application. After the application initializes, the evaluator shall run network port scans to verify that any ports opened by the application have been captured in the ST for the third selection and its assignment. This includes connection-based protocols (e.g. TCP, DCCP) as well as connectionless protocols (e.g. UDP). + + + + + + If "no network communication" is selected, the evaluator shall ensure that the application's AndroidManifest.xml file does not contain a uses-permission or uses-permission-sdk-23 tag containing android:name="android.permission.INTERNET". In this case, it is not necessary to perform the above Tests 1 and 2, as the platform will not allow the application to perform any network communication. + + + + + + + +
+ +
+ + This family defines requirements for authorization to manage the behavior of the application. + + + This family defines requirements for the TOEโ€™s use of mechanisms for the storage of configuration data. + + + + requires the application to define how to set new credentials and protect the application from modification by unprivileged users. + No specific management functions are identified. + There are no auditable events foreseen. + No dependencies. + + The application shall <selectables><selectable id="fmt_cfg_ext.1.1_1" >not use credentials</selectable><selectable id="fmt_cfg_ext.1.1_2" >use platform-provided credentials</selectable><selectable id="fmt_cfg_ext.1.1_3" >provide only enough functionality to set new credentials when configured with default credentials or no credentials for application provided credentials</selectable> </selectables>. + Default credentials are credentials (e.g., passwords, keys) that are automatically (without user interaction) loaded onto the platform during application installation. Credentials that are generated during installation using requirements laid out in FCS_RBG_EXT.1 or established by leveraging platform accounts are not by definition default credentials. + + The evaluator shall check that the TSS describes whether the application requires any type of application provided credentials and whether the application is pre-configured with default values for these credentials. If credentials are required, the evaluator shall verify that the TSS details how use of the TOE is restricted until new credentials are set (which includes the replacement of default credentials if any are present). + The evaluator shall verify the guidance documentation details regarding any default or null application provided credentials being used and how they would be updated. + + If the application uses any default credentials the evaluator shall run the following tests. + + For any application provided credentials the evaluator shall install and run the application without generating or loading new credentials and verify that only the minimal application functionality required to set new credentials is available. + For any application provided credentials the evaluator shall attempt to clear all credentials and verify that only the minimal application functionality required to set new credentials is available. + For any application provided credentials the evaluator shall run the application, establish new credentials and verify that the original default credentials no longer provide access to the application. + + + + + + The application shall be configured by default with file permissions which protect the application binaries and data files from modification by normal unprivileged users. + The precise expectations for file permissions vary per platform but the general intention is that a trust boundary protects the application and its data. + + None. + None. + + The evaluator shall install and run the application. The evaluator shall inspect the file system of the platform (to the extent possible) for any files created by the application and ensure that their permissions are adequate to protect them. The method of doing so varies per platform. + + + + + The evaluator shall run the command find -L. -perm /002 inside the application's data directories to ensure that all files are not world-writable. The command should not print any files (for this test, directories are not considered to be files). + + + + + + + + The evaluator shall run the SysInternals tools Process Monitor and Access Check (or tools of equivalent capability, like icacls.exe) for Classic Desktop applications to verify that files written to disk during an application's installation have the correct file permissions, such that a standard user cannot modify the application or its data files. For Windows Universal Applications the evaluator shall consider the requirement met because of the AppContainer sandbox. + + + + + + + + The evaluator shall determine whether the application leverages the appropriate Data Protection Class for each data file stored locally. + + + + + + + + The evaluator shall run the command find -L. -perm /002 inside the application's data directories to ensure that all files are not world-writable. The command should not print any files. + + + + + + + + The evaluator shall run the command find. \( -perm -002 \) inside the application's data directories to ensure that all files are not world-writable. The command should not print any files. + + + + + + + + The evaluator shall run the command find. -perm +002 inside the application's data directories to ensure that all files are not world-writable. The command should not print any files. + + + + + + + + + + requires the application to store configuration data either through the use of an appropriate environmental mechanism or through its own file encryption capability. + No specific management functions are identified. + There are no auditable events foreseen. + No dependencies. + + The application shall <selectables><selectable id="fmt_mec_ext.1.1_1" >invoke the mechanisms recommended by the platform vendor for storing and setting configuration options</selectable><selectable id="fmt_mec_ext.1.1_2" >implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption</selectable> </selectables>. + Configuration options that are stored remotely are not subject to this requirement. Sensitive Data is generally not considered part of configuration options and should be stored according to FDP_DAR_EXT.1 or FCS_STO_EXT.1.If โ€œimplement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption" is selected, the TSF must claim conformance to a PP-Configuration that includes the PP-Module for File Encryption. + + The evaluator shall review the TSS to identify the application's configuration options (e.g., settings) and determine whether these are stored and set using the mechanisms supported by the platform or implemented by the application in accordance with the PP-Module for File Encryption. At a minimum the TSS shall list settings related to any SFRs and any settings that are mandated in the operational guidance in response to an SFR.Conditional: If "implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption" is selected, the evaluator shall ensure that the TSS identifies those options, as well as indicates where the encrypted representation of these options is stored. + The evaluator shall verify the guidance documentation contains any information necessary to configure the protection of configuration settings. + + If " invoke the mechanisms recommended by the platform vendor for storing and setting configuration options" is selected, the method of testing varies per platform as follows: + + + + The evaluator shall inspect the TSS and verify that it describes what Android API is used (and provides a link to the documentation of the API) when storing configuration data. The evaluator shall run the application and verify that the behavior of the TOE is consistent with where and how the API documentation says the configuration data will be stored.For SharedPreferences, the evaluator shall examine the XML file to make sure it reflects the changes made to the configuration to verify that the application used SharedPreferences or PreferenceActivity to store the configuration data. For DataStore, the evaluator shall use a protocol buffer analyzer to examine the file to make sure it reflects the changes made to the configuration to verify that the application used DataStore to store the configuration data. + + + + + + The evaluator shall determine and verify that Windows Universal Applications use either the Windows.Storage namespace, Windows.UI.ApplicationSettings namespace, or the IsolatedStorageSettings namespace for storing application specific settings. For .NET applications, the evaluator shall determine and verify that the application uses one of the locations listed in + https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/ or + https://learn.microsoft.com/en-us/previous-versions/dotnet/netframework-4.0/zzdt0e7f(v=vs.100) or + https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/ or + https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/web-config for storing application specific (whether application-wide or user-specific) settings.For Classic Desktop applications, the evaluator shall run the application while monitoring it with the SysInternals tool Process Monitor and make changes to its configuration. The evaluator shall verify that Process Monitor logs show corresponding changes to the Windows Registry or C:\ProgramData\ directory. + + + + + + + The evaluator shall verify that the app uses the user defaults system or key-value store for storing all settings. + + + + + + + + The evaluator shall run the application while monitoring it with the utility strace. The evaluator shall make security-related changes to its configuration. The evaluator shall verify that strace logs corresponding changes to configuration files that reside in /etc (for system-specific configuration), in the user's home directory (for user-specific configuration), or /var/lib/ (for configurations controlled by UI and not intended to be directly modified by an administrator). + + + + + + + + The evaluator shall run the application while monitoring it with the utility dtrace. The evaluator shall make security-related changes to its configuration. The evaluator shall verify that dtrace logs corresponding changes to configuration files that reside in /etc (for system-specific configuration) or in the user's home directory (for user-specific configuration). + + + + + + + + The evaluator shall verify that the application stores and retrieves settings using the NSUserDefaults class. + + + + If " implement functionality to encrypt and store configuration options as defined by FDP_PRT_EXT.1 in the PP-Module for File Encryption" is selected, for all configuration options listed in the TSS as being stored and protected using encryption, the evaluator shall examine the contents of the configuration option storage (identified in the TSS) to determine that the options have been encrypted. + + + + + + + + The TSF shall be capable of performing the following management functions <selectables linebreak="yes"><selectable id="fmt_smf.1.1_1" exclusive="yes">no management functions</selectable><selectable id="fmt_smf.1.1_2" >enable/disable the transmission of any information describing the system's hardware, software, or configuration</selectable><selectable id="fmt_smf.1.1_3" >enable/disable the transmission of any PII</selectable><selectable id="fmt_smf.1.1_4" >enable/disable transmission of any application state (e.g. crashdump) information</selectable><selectable id="fmt_smf.1.1_5">enable/disable network backup functionality to <assignable>list of enterprise or commercial cloud backup systems</assignable> </selectable><selectable id="fmt_smf.1.1_2" ><assignable>list of other management functions to be provided by the TSF</assignable></selectable> </selectables>. + This requirement stipulates that an application needs to provide the ability to enable/disable only those functions that it actually implements. The application is not responsible for controlling the behavior of the platform or other applications. + + The evaluator shall verify the TSS details how the application's management functions align with the selected management functions. + The evaluator shall verify that every management function mandated by the PP is described in the operational guidance and that the description contains the information required to perform the management duties associated with the management function. + The evaluator shall test the application's ability to provide the management functions by configuring the application and testing each option selected from above. The evaluator is expected to test these functions in all the ways in which the ST and guidance documentation state the configuration can be managed. + + + +
+ +
+ + This family defines requirements for anonymity that are not covered by the Part 2 family FPR_ANO. + + + + requires the TSF to transmit personally identifiable information only with explicit approval. + The following action could be considered for the management functions in FMT:Enabling and disabling the transmission of any PII. + There are no auditable events foreseen. + No dependencies. + + The application shall <selectables onlyone="yes" linebreak="yes"><selectable id="fpr_ano_ext.1.1_1" >not use PII</selectable><selectable id="fpr_ano_ext.1.1_2" >not transmit PII over a network</selectable><selectable id="fpr_ano_ext.1.1_3">require user approval before executing <assignable>list of functions that transmit PII over a network</assignable> </selectable> </selectables>. + PII is considered to be sensitive data. If "require user approval before executing..." is claimed, the ST must not claim "not transmit any..." in FTP_DIT_EXT.1.This requirement applies only to PII that is specifically requested by the application; it does not apply if the user volunteers PII without prompting from the application into a general (or inappropriate) data field. A dialog box that declares intent to send PII presented to the user at the time the application is started is sufficient to meet this requirement. + + If "not use PII" is claimed, the evaluator shall verify the TSS states the application does not utilize any PII.If "not transmit PII over a network" is claimed, the evaluator shall verify that the TSS makes this assertion (e.g., because it does not use network connectivity at all or if the functions for which it uses network connectivity do not involve transmission of PII). If "require user approval before executing..." is selected, the evaluator shall inspect the TSS documentation to verify that it identifies the functions where PII may be transmitted over a network. + The evaluator shall verify the guidance documentation contains any instructions to configure the transmission of PII and details any prompts that would approve or deny transmission of PII. + If " require user approval before executing..." is selected, the evaluator shall run the application, execute each function that is claimed as being used to transmit PII, and verify that user approval is required before transmission of the PII for each function. + + + +
+ +
+ + This family defines requirements for protecting against common types of software exploitation techniques. + + + This family defines requirements for specifying the environmental APIs used by the TOE. + + + This family defines requirements for how the TOE version is identified. + + + This family defines requirements for identification of any third-party libraries used by the TOE. + + + This family defines requirements for applying updates to the TOE. + + + + requires the application to implement functionality that protects against common software exploits. + No specific management functions are identified. + There are no auditable events foreseen. + No dependencies. + + The application shall not request to map memory at an explicit address except for <assignable>list of explicit exceptions</assignable>. + Requesting a memory mapping at an explicit address subverts address space layout randomization (ASLR). + + The evaluator shall ensure that the TSS describes the compiler flags used to enable ASLR when the application is compiled. If any explicitly-mapped exceptions are claimed, the evaluator shall check that the TSS identifies these exceptions, describes the static memory mapping that is used, and provides justification for why static memory mapping is appropriate in this case. + None. + + The evaluator shall perform either a static or dynamic analysis to determine that no memory mappings are placed at an explicit and consistent address except for any exceptions claimed in the SFR. For these exceptions, the evaluator shall verify that this analysis shows explicit mappings that are consistent with what is claimed in the TSS. The method of doing so varies per platform. For those platforms requiring the same application running on two different systems, the evaluator may alternatively use the same device. After collecting the first instance of mappings, the evaluator must uninstall the application, reboot the device, and reinstall the application to collect the second instance of mappings. + + + + + The evaluator shall run the same application on two different Android systems. Both devices do not need to be evaluated, as the second device is acting only as a tool. Connect via ADB and inspect /proc/PID/maps. Ensure the two different instances share no memory mappings made by the application at the same location. + + + + + + + + The evaluator shall run the same application on two different Windows systems and run a tool that will list all memory mapped addresses for the application. The evaluator shall then verify the two different instances share no mapping locations. The Microsoft SysInternals tool, VMMap, could be used to view memory addresses of a running application. The evaluator shall use a tool such as Microsoft's BinScope Binary Analyzer to confirm that the application has ASLR enabled. + + + + + + + + The evaluator shall perform a static analysis to search for any mmap calls (or API calls that call mmap), and ensure that no arguments are provided that request a mapping at a fixed address. + + + + + + + + The evaluator shall run the same application on two different Linux systems. The evaluator shall then compare their memory maps using pmap -x PID to ensure the two different instances share no mapping locations. + + + + + + + + The evaluator shall run the same application on two different Solaris systems. The evaluator shall then compare their memory maps using pmap -x PID to ensure the two different instances share no mapping locations. + + + + + + + + The evaluator shall run the same application on two different Mac systems. The evaluator shall then compare their memory maps using vmmap PID to ensure the two different instances share no mapping locations. + + + + + + + + The application shall <selectables onlyone="yes" linebreak="yes"><selectable id="fpt_aex_ext.1.2_1" >not allocate any memory region with both write and execute permissions</selectable><selectable id="fpt_aex_ext.1.2_2">allocate memory regions with write and execute permissions for only <assignable>list of functions performing just-in-time compilation</assignable> </selectable> </selectables>. + Requesting a memory mapping with both write and execute permissions subverts the platform protection provided by DEP. If the application performs no just-in-time compiling, then the first selection must be chosen. + + None. + None. + + The evaluator shall verify that no memory mapping requests are made with write and execute permissions. The method of doing so varies per platform. + + + + + The evaluator shall perform static analysis on the application to verify that mmap is never invoked with both the PROT_WRITE and PROT_EXEC permissions, andmprotect is never invoked. + + + + + + + The evaluator shall use a tool such as Microsoft's BinScope Binary Analyzer to confirm that the application passes the NXCheck. The evaluator may also ensure that the /NXCOMPAT flag was used during compilation to verify that DEP protections are enabled for the application. + + + + + + + + The evaluator shall perform static analysis on the application to verify that mprotect is never invoked with the PROT_EXEC permission. + + + + + + + + The evaluator shall perform static analysis on the application to verify that both mmap is never invoked with both the PROT_WRITE and PROT_EXEC permissions, andmprotect is never invoked with the PROT_EXEC permission. + + + + + + + The evaluator shall perform static analysis on the application to verify that both mmap is never invoked with both the PROT_WRITE and PROT_EXEC permissions, andmprotect is never invoked with the PROT_EXEC permission. + + + + + + + The evaluator shall perform static analysis on the application to verify that mprotect is never invoked with the PROT_EXEC permission. + + + + + + + + The application shall be compatible with security features provided by the platform vendor. + This requirement is designed to ensure that platform security features do not need to be disabled in order for the application to run. + + None. + None. + + The evaluator shall configure the platform in the necessary manner and carry out one of the prescribed tests: + + + + + Applications running on Android cannot disable Android security features, therefore this requirement is met and no evaluation activity is required. + + + + + + + If the OS platform supports Windows Defender Exploit Guard, then the evaluator shall ensure that the application can run successfully with Windows Defender Exploit Guard Exploit Protection configured with the following minimum mitigations enabled; Control Flow Guard (CFG), Randomize memory allocations (Bottom-Up ASLR), Export address filtering (EAF), Import address filtering (IAF), and Data Execution Prevention (DEP). The following link describes how to enable Exploit Protection, https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/enable-exploit-protection?view=o365-worldwide. + + + + + + + Applications running on iOS cannot disable security features, therefore this requirement is met and no evaluation activity is required. + + + + + + + + The evaluator shall ensure that the application can successfully run on a system with either SELinux or AppArmor enabled and in enforce mode. + + + + + + + + The evaluator shall ensure that the application can run with Solaris Trusted Extensions enabled and enforcing. + + + + + + + + The evaluator shall ensure that the application can successfully run on macOS without disabling any security features. + + + + + + + + The application shall not write user-modifiable files to directories that contain executable files unless explicitly directed by the user to do so. + The purpose of this requirement is to help ensure the integrity of application binaries by supporting file protection mechanisms such as directory-level file permissions and application allowlisting.A user-modifiable file for purposes of this requirement is a file that is writable by an unprivileged user of the application -- either directly through application execution or independently of the application. If the application runs in the context of the application user, then the application should not be able to write to the directory containing the application binaries -- regardless of whether the files are configuration data, audit data, or temporary files.Executables and user-modifiable files may not share the same parent directory, but may share directories above the parent. + + None. + None. + + The evaluator shall run the application and determine where it writes its files. For files where the user does not choose the destination, the evaluator shall check whether the destination directory contains executable files. This varies per platform: + + + + + The evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written. The evaluator shall ensure that there are no executable files stored under /data/data/package/ where package is the Java package of the application. + + + + + + + + For Windows Universal Applications the evaluator shall consider the requirement met because the platform forces applications to write all data within the application working directory (sandbox). For Windows Desktop Applications the evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written. The evaluator shall ensure that there are no executable files stored in the same directories to which the application wrote user-modifiable files. + + + + + + + + The evaluator shall consider the requirement met because the platform forces applications to write all data within the application working directory (sandbox). + + + + + + + + The evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written. The evaluator shall ensure that there are no executable files stored in the same directories to which the application wrote user-modifiable files. + + + + + + + + The evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written. The evaluator shall ensure that there are no executable files stored in the same directories to which the application wrote user-modifiable files. + + + + + + + + The evaluator shall run the program, mimicking normal usage, and note where all user-modifiable files are written. The evaluator shall ensure that there are no executable files stored in the same directories to which the application wrote user-modifiable files. + + + + + + + + The application shall be built with stack-based buffer overflow protection enabled. + + (Conditional: The PE or ELF automated tests fail) The evaluator shall ensure that the TSS describes the stack-based buffer overflow compiler flags. + None. + + The evaluator will inspect every native executable included in the TOE to ensure that stack-based buffer overflow protection is present. + + + + + Applications that run as Managed Code in the .NET Framework do not require these stack protections. Applications developed in Object Pascal using the Delphi IDE compiled with RangeChecking enabled comply with this element. For other code, the evaluator shall review the TSS and verify that the /GS flag was used during compilation. The evaluator shall run a tool like, BinSkim, that can verify the correct usage of /GS. + + + + + For PE, the evaluator will disassemble each and ensure the following sequence appears:mov rcx, QWORD PTR [rsp+(...)]xor rcx, (...)call (...) + + + For ELF executables, the evaluator will ensure that each contains references to the symbol __stack_chk_fail.If these automated tests fail, the evaluator shall perform the above, conditional TSS activity. + + Tools such as Canary Detector may help automate these activities. + + + + + + + requires the application to use only documented platform APIs. + No specific management functions are identified. + There are no auditable events foreseen. + No dependencies. + + The application shall use only documented platform APIs. + The definition of "documented" may vary depending upon whether the application is provided by a third party (who relies upon documented platform APIs) or by a platform vendor who may be able to guarantee support for platform APIs. + + The evaluator shall verify that the TSS lists the platform APIs used in the application. The evaluator shall then compare the list with the supported APIs (available through e.g. developer accounts, platform developer groups) and ensure that all APIs listed in the TSS are supported. + None. + + + + + + + requires the application to implement media parsing in a specified manner. + No specific management functions are identified. + There are no auditable events foreseen. + No dependencies. + + The application <selectables onlyone="yes"><selectable id="fpt_api_ext.2.1_1" >shall use platform-provided libraries</selectable><selectable id="fpt_api_ext.2.1_2" >does not implement functionality</selectable> </selectables> for parsing <assignable>list of formats parsed that are included in the IANA MIME media types</assignable>. + The IANA MIME types are listed at http://www.iana.org/assignments/media-types and include many image, audio, video, and content file formats.This requirement does not apply if providing parsing services is the purpose of the application. + + The evaluator shall verify that the TSS lists any IANA MIME media types (as described by + http://www.iana.org/assignments/media-types) for all formats the application processes and that it maps those formats to parsing services provided by the platform.The API shall be verified in FPT_API_EXT.1. + None. + None. + + + + + + + + The TSF shall preserve a secure state when the following types of failures occur: [<h:i>DRBG self-test failure</h:i>]. + The intent of this requirement is to ensure that cryptographic services requiring random bit generation cannot be performed if a failure of a self-test defined in FPT_TST.1 occurs. + + The evaluator shall verify that the TSF describes how the TOE enters an error state in the event of a DRBG self-test failure. + The evaluator shall verify that the guidance documentation describes the error state that results from a DRBG self-test failure and the actions that a user or administrator should take in response to attempt to resolve the error state. + + + + + + + requires the TSF to specify the versioning mechanism used. + No specific management functions are identified. + There are no auditable events foreseen. + No dependencies. + + The application shall be versioned with <h:i>SWID tags that comply with minimum requirements from ISO/IEC 19770-2:2015</h:i>. + The application shall be versioned with + <selectables><selectable>SWID tags that comply with minimum requirements from ISO/IEC 19770-2:2015 </selectable> <selectable><assignable>other version information </assignable> </selectable> </selectables>. + The use of a SWID tag to identify application software is a requirement for DoD IT based on DoD Instruction 8500.01 which requires the use of SCAP which includes SWID tags per the NIST standard.Valid SWID tags must contain a SoftwareIdentity element and an Entity element as defined in the ISO/IEC 19770-2:2015 standard. SWID tags must be stored with a .swidtag file extensions as defined in the ISO/IEC 19770-2:2015. + + None. + None. + The evaluator shall install the application and check for a .swidtag file. The evaluator shall open the file and verify that is contains at least a SoftwareIdentity element and an Entity element. + + + + + + requires the TOE to identify the third party libraries that it uses. + No specific management functions are identified. + There are no auditable events foreseen. + No dependencies. + + The application shall be packaged with only <assignable>list of third-party libraries</assignable>. + The intention of this requirement is for the evaluator to discover and document whether the application includes unnecessary or unexpected third-party libraries. This includes adware libraries which could present a privacy threat, as well as ensuring documentation of such libraries in case vulnerabilities are later discovered. + + None. + None. + The evaluator shall install the application and survey its installation directory for dynamic libraries. The evaluator shall verify that libraries found to be packaged with or employed by the application are limited to those in the assignment. + + + + + + + + The TSF shall run a suite of the following self-tests <selectables><selectable id="fpt_tst.1.1_1" >during initial start-up</selectable><selectable id="fpt_tst.1.1_2" >periodically during normal operation</selectable><selectable id="fpt_tst.1.1_3" >at the request of the authorized user</selectable><selectable id="fpt_tst.1.1_4">at the conditions <assignable>conditions under which self-test should occur</assignable> </selectable> </selectables> to demonstrate the correct operation of [<h:i>TSF DRBG specified in FCS_RBG.1</h:i>]. + + The evaluator shall examine the TSS to ensure that it details the self-tests that are run by the TSF along with how they are run. This description should include an outline of what the tests are actually doing. The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the DRBG is operating correctly.Note that this information may also be placed in the entropy documentation specified by . + If a self-test can be executed at the request of an authorized user, the evaluator shall verify that the operational guidance provides instructions on how to execute that self-test. + For each self-test, the evaluator shall verify that evidence is produced that the self-test is executed when specified by FPT_TST.1.1. If a self-test can be executed at the request of an authorized user, the evaluator shall verify that following the steps documented in the operational guidance to perform the self-test will result in execution of the self-test. + + + + The TSF shall provide authorized users with the capability to verify the integrity of [<h:i>[DRBG seed/output data]</h:i>]. + + + The TSF shall provide authorized users with the capability to verify the integrity of [<h:i>[TSF DRBG specified in FCS_RBG.1]</h:i>]. + This SFR is a required dependency of FCS_RBG.1. It is intended to require that any DRBG implemented by the TOE undergo health testing to ensure that the random bit generation functionality has not been degraded. If the TSF supports multiple DRBGs, this SFR should be iterated to describe the self-test behavior for each. + + + + + requires the TSF to specify how updates to it are acquired and verified. + No specific management functions are identified. + There are no auditable events foreseen. + FPT_IDV_EXT.1 Software Identification and Versions + + The application shall <selectables><selectable id="fpt_tud_ext.1.1_1" >provide the ability</selectable><selectable id="fpt_tud_ext.1.1_2" >use platform-provided services</selectable> </selectables> to check for updates and patches to the application software. + This requirement is about the ability to "check" for updates. The actual installation of any updates should be done by the platform. This requirement is intended to ensure that the application can check for updates provided by the vendor, as updates provided by another source may contain malicious code. + + The evaluator shall verify the TSS contains a description of the update mechanism leveraged, how new updates are checked for, how the current version is checked for, and how the updates are signed. + The evaluator shall check to ensure the guidance includes a description of how to check for and apply new updates. + The evaluator shall check for an update using procedures described in either the application documentation or the platform documentation and verify that the application does not issue an error. If it is updated or if it reports that no update is available this requirement is considered to be met. + + + + The application shall <selectables><selectable id="fpt_tud_ext.1.2_1" >provide the ability</selectable><selectable id="fpt_tud_ext.1.2_2" >use platform-provided services</selectable> </selectables> to query the current version of the application software. + + + The evaluator shall verify guidance includes a description of how to query the current version of the application. + The evaluator shall query the application for the current version of the software according to the operational user guidance. The evaluator shall then verify that the current version matches that of the documented and installed version. + + + + The application shall <selectables linebreak="yes"><selectable id="toe-update" >perform trusted updates</selectable><selectable id="fpt_tud_ext.1.3_1" >not download, modify, replace or update its own binary code</selectable> </selectables>. + This requirement applies to the code of the application; it does not apply to mobile code technologies that are designed for download and execution by the application.If "perform trusted updates" is selected then FPT_TUD_EXT.2 must be included in the ST. + + + + + Conditional: If "not download, modify, replace or update its own binary code" is selected the evaluator shall verify that the application's executable files are not changed by the application with the following tests: + + + + + The evaluator shall consider the requirement met because the platform forces applications to write all data within the application working directory (sandbox). + + + + + + + + + + + + The evaluator shall install the application and then locate all of its executable files. The evaluator shall then, for each file, save off either a hash of the file or a copy of the file itself. The evaluator shall then run the application and exercise all features of the application as described in the ST. The evaluator shall then compare each executable file with either the saved hash or the saved copy of the files. The evaluator shall verify that these are identical. + + + + + + + + Application updates shall be digitally signed such that the application platform can cryptographically verify them prior to installation. + The specifics of the verification of updates involves requirements on the platform (and not the application), so these are not fully specified here. + + The evaluator shall verify that the TSS identifies how updates to the application are signed by an authorized source. The definition of an authorized source must be contained in the TSS. The evaluator shall also ensure that the TSS (or the operational guidance) describes how candidate updates are obtained. + + + + + + The application is distributed <selectables><selectable id="sel_with_plat" >with the platform OS</selectable><selectable id="sel_add_plat" >as an additional software package to the platform OS</selectable> </selectables>. + Application software that is distributed as part of the platform operating system is not required to be packaged for installation or uninstallation. If "as an additional software package to the platform OS" is selected, the requirements from FPT_TUD_EXT.2 must be included in the ST. + + The evaluator shall verify that the TSS identifies how the application is distributed. If "as an additional package..." is selected, the evaluator shall perform the tests in FPT_TUD_EXT.2. + None. + If " with the platform OS" is selected, the evaluator shall perform a clean installation or factory reset to confirm that TOE software is included as part of the platform OS. + + + + + + + + requires TOE updates to be packaged in a certain manner. + No specific management functions are identified. + There are no auditable events foreseen. + FPT_TUD_EXT.1 Integrity for Installation and Update + + The application shall be distributed using <selectables><selectable id="fpt_tud_ext.2.1_1" >the format of the platform-supported package manager</selectable><selectable id="fpt_tud_ext.2.1_2" >a container image</selectable> </selectables>. + + The evaluator shall verify that the TSS describes how the application is distributed and verify that description aligns with the selections in the ST. + None. + + If a container image is claimed, the evaluator shall verify that application updates are distributed as container images. If the format of the platform-supported package manager is claimed, the evaluator shall verify that application updates are distributed in the format supported by the platform. This varies per platform: + + + + + The evaluator shall ensure that the application is packaged in the Android application package (APK) format. + + + + + + + + The evaluator shall ensure that the application is packaged in the standard Windows Installer (.MSI) format, the Windows Application Software (.EXE) format signed using the Microsoft Authenticode process, or the Windows Universal Application package (.APPX) format. See https://msdn.microsoft.com/en-us/library/ms537364(v=vs.85).aspx for details regarding Authenticode signing. + + + + + + + + The evaluator shall ensure that the application is packaged in the IPA format. + + + + + + + + The evaluator shall ensure that the application is packaged in the format of the package management infrastructure of the chosen distribution. For example, applications running on Red Hat and Red Hat derivatives shall be packaged in RPM format. Applications running on Debian and Debian derivatives shall be packaged in DEB format. + + + + + + + + The evaluator shall ensure that the application is packaged in the PKG format. + + + + + + + + The evaluator shall ensure that the application is packaged in the DMG format, the PKG format, or the MPKG format. + + + + + + + + The application shall be packaged such that its removal results in the deletion of all traces of the application, with the exception of configuration settings, output files, and audit/log events. + Application software bundled with the system/firmware image are not subject to this requirement if the user is unable to remove the application through means provided by the OS. + + None. + The evaluator shall verify the guidance documentation details how uninstallation of the application is performed. + + + + + + The evaluator shall consider the requirement met because the platform forces applications to write all data within the application working directory (sandbox). + + + + + + + + The evaluator shall consider the requirement met because the platform forces applications to write all data within the application working directory (sandbox). + + + + For all other platforms, the evaluator shall record the path of every file on the entire file system prior to installation of the application, and then install and run the application. Afterward, the evaluator shall uninstall the application, and compare the resulting file system to the initial record to verify that no files, other than configuration, output, and audit or log files, have been added to the file system. + + + + + The application installation package shall be digitally signed such that <selectables><selectable id="fpt_tud_ext.2.3_1" >its platform can cryptographically verify them prior to installation.</selectable><selectable id="fpt_tud_ext.2.3_2">the application can verify them using <selectables><selectable id="toe-lms" >Leighton-Micali Signature.</selectable><selectable id="toe-xmss" >eXtended Merkle Signature Scheme.</selectable></selectables> </selectable> </selectables> + The specifics of the verification of installation packages involves requirements on the platform (and not the application), so these are not fully specified here.If "Leighton-Micali Signature" or "eXtended Merkle Signature Scheme" is selected, the corresponding selection must be made in FCS_COP.1/SigVer. + + The evaluator shall verify that the TSS identifies how the application installation package is signed by an authorized source. The definition of an authorized source must be contained in the TSS. + None. + + Conditional: if "the application can verify them using" is selected the evaluator shall perform the following tests: + + The evaluator shall ensure that the update has a digital signature belonging to the vendor prior to its installation. The evaluator shall modify the downloaded update in such a way that the digital signature is no longer valid. The evaluator will then attempt to install the modified update. The evaluator shall ensure that the modified update fails to install. + The evaluator shall ensure that the update has a digital signature belonging to the vendor. The evaluator shall then attempt to install the update (or permit installation to continue). The evaluator shall ensure that the update successfully installs. + + + + + +
+ +
+ + This family defines requirements for protecting data in transit. + + + + requires the TSF to specify what data is transmitted outside the TOE over a trusted channel, what protocol is used for data transmission, and whether the TSF implements this protocol or invokes an environmental interface to do so. + No specific management functions are identified. + There are no auditable events foreseen. + No dependencies. + + The application shall <selectables linebreak="yes"><selectable + id="ftp_dit_ext.1.1_1">not transmit any <selectables onlyone="yes"><selectable + id="ftp_dit_ext.1.1_2" >data</selectable><selectable id="ftp_dit_ext.1.1_3" + >sensitive data</selectable></selectables> </selectable><selectable + id="ftp_dit_ext.1.1_4">encrypt all transmitted <selectables onlyone="yes"><selectable id="ftp_dit_ext.1.1_5" >sensitive data</selectable><selectable id="ftp_dit_ext.1.1_6" >data</selectable></selectables> with <selectables><selectable id="sel_all_https_cl" >HTTPS as a client in accordance with FCS_HTTPS_EXT.1 and FCS_HTTPS_EXT.2</selectable><selectable id="sel_all_https_sv" >HTTPS as a server in accordance with FCS_HTTPS_EXT.1</selectable><selectable id="sel_all_https_ma" >HTTPS as a server with support for mutual authentication in accordance with FCS_HTTPS_EXT.1 and FCS_HTTPS_EXT.2</selectable><selectable id="sel_all_tlss">TLS as a server as defined in Functional Package for Transport Layer Security (TLS), version 2.1 and also supports functionality for <selectables><selectable id="ftp_dit_ext.1.1_7" >mutual authentication</selectable><selectable id="ftp_dit_ext.1.1_8" >none</selectable></selectables> </selectable><selectable id="sel_all_tlsc" >TLS as a client as defined in Functional Package for Transport Layer Security (TLS), version 2.1</selectable><selectable id="sel_all_dtlss">DTLS as a server as defined in Functional Package for Transport Layer Security (TLS), version 2.1 and also supports functionality for <selectables><selectable id="ftp_dit_ext.1.1_9" >mutual authentication</selectable><selectable id="ftp_dit_ext.1.1_10" >none</selectable></selectables> </selectable><selectable id="sel_all_dtlsc" >DTLS as a client as defined in Functional Package for Transport Layer Security (TLS), version 2.1</selectable><selectable id="sel_all_ssh" >SSH as defined in the <xref to="pkg-ssh"/></selectable><selectable id="sel_all_ipsec" >IPsec as defined in the VPN Client PP-Module, version 3.0</selectable></selectables> for <assignable>function(s)</assignable> using certificates as defined in the <h:a href="https://commoncriteria.github.io/x509/release-1.0/x509-release.html"> Functional Package for X.509</h:a></selectable><selectable id="ftp_dit_ext.1.1_12">invoke platform-provided functionality to encrypt all transmitted sensitive data with <selectables><selectable id="ftp_dit_ext.1.1_13" >HTTPS</selectable><selectable id="ftp_dit_ext.1.1_14" >TLS</selectable><selectable id="ftp_dit_ext.1.1_15" >DTLS</selectable><selectable id="ftp_dit_ext.1.1_16" >SSH</selectable><selectable id="ftp_dit_ext.1.1_17" >IPsec</selectable></selectables> for <assignable>function(s)</assignable> using certificates as defined in the <h:a href="https://commoncriteria.github.io/x509/release-1.0/x509-release.html"> Functional Package for X.509</h:a></selectable><selectable id="ftp_dit_ext.1.1_19">invoke platform-provided functionality to encrypt all transmitted data with <selectables><selectable id="ftp_dit_ext.1.1_20" >HTTPS</selectable><selectable id="ftp_dit_ext.1.1_21" >TLS</selectable><selectable id="ftp_dit_ext.1.1_22" >DTLS</selectable><selectable id="ftp_dit_ext.1.1_23" >SSH</selectable><selectable id="ftp_dit_ext.1.1_24" >IPsec</selectable></selectables> for <assignable>function(s)</assignable> using certificates as defined in the <h:a href="https://commoncriteria.github.io/x509/release-1.0/x509-release.html"> Functional Package for X.509</h:a></selectable> </selectables> between itself and another trusted IT product. + The application shall <selectables onlyone="yes" linebreak="yes"><selectable>not transmit any <selectables onlyone="yes"><selectable>data </selectable> <selectable>sensitive data </selectable> </selectables> </selectable> <selectable>encrypt all transmitted <selectables onlyone="yes"><selectable>sensitive data </selectable> <selectable>data </selectable> </selectables> with <assignable>trusted protocol </assignable> for <assignable>function(s) </assignable> </selectable> <selectable>invoke platform-provided functionality to encrypt all transmitted sensitive data with <assignable>trusted protocol </assignable> for <assignable>function(s) </assignable> </selectable> <selectable>invoke platform-provided functionality to encrypt all transmitted data with <assignable>trusted protocol </assignable> for <assignable>function(s) </assignable> </selectable> </selectables> between itself and another trusted IT product. + Encryption is not required for applications transmitting + data that is not sensitive.If "not transmit any..." is selected, no other option can be selected.If "not transmit any..." is NOT selected, it is possible to select more than one of the other options to encrypt data for a specific cryptographic function (e.g., application encrypts management data using SSH AND application invokes platform-provided functionality to encrypt syslog data using TLS OR application encrypts syslog data using TLS. Protocol selections and function assignments should be made to cover all data/sensitive data.If "encrypt all transmitted..." is selected and "TLS" or "DTLS" as a client or server is selected, then corresponding components from Functional Package for Transport Layer Security (TLS), version 2.1 must be selected.If "encrypt all transmitted..." is selected and any claim involving HTTPS is selected, then FCS_HTTPS_EXT.1 and potentially FCS_HTTPS_EXT.2 is required, as indicated by the chosen selections.If "encrypt all transmitted..." is selected and "SSH" is selected, then the TSF shall be validated against the Functional Package for Secure Shell.If "encrypt all transmitted..." is selected and "IPsec" is selected, then the TSF must claim conformance to a PP-Configuration that includes the VPN Client PP-Module, version 3.0.If "encrypt all transmitted..." is selected, FCS_CKM.2 and all iterations of FCS_COP.1 must be claimed.Claims from the + Functional Package for X.509 are only required to the extent that they are needed to support the functionality required by the trusted protocols that are claimed. For example, if the TOE supports HTTPS as a server but does not support mutual authentication, then for this interface the TSF would only present certificates in accordance with the requirements of the package and not validate presented certificates.If the TSF implements a protocol that requires the validation of a certificate presented by an external entity, FIA_X509_EXT.1 and FIA_X509_EXT.2 will be claimed. FIA_TSM_EXT.1 may also be claimed if the TSF implements its own trust store. Note that FIA_X509_EXT.1 and FIA_X509_EXT.2 have selections for invocation of platform-provided functionality, so it is expected that these claims are made and tested even when the trusted protocol is implemented by the TOE platform.If the TSF implements a protocol that requires the presentation of any certificates to an external entity, FIA_XCU_EXT.2 from + Functional Package for X.509 will be claimed. FIA_X509_EXT.3 from + Functional Package for X.509 will also be claimed, along with any applicable dependencies, depending on how the certificates presented by the TOE are obtained.If the TSF implements a protocol that does not require presenting or validating X.509 certificates, no claims from the + Functional Package for X.509 are required. + + The evaluator shall confirm the TSS describes the data transmitted, and + verify it matches the selections of all data or sensitive + data.The evaluator shall confirm the TSS describes the method by which + the data is protected and that is matches the chosen selections, if multiple selections are included the evaluator shall verify the TSS describes which data is sent over which trusted channels and the totality of the data type selection is covered by all chosen selections.For platform-provided functionality, the evaluator shall verify the TSS contains the calls to the platform that the TOE is leveraging to invoke the functionality. The evaluator shall verify calls are documented by the platform vendor and non-deprecated.For platform-provided HTTPS, IPsec, TLS, or DTLS as a client the evaluator shall verify that the TSS lists any specific calls the product uses that specifies or allows the end users to specify cipher suites, support for mutual authentication, support for session renegotiation, hash algorithms for the signature_algorithms extension in the Client Hello with the supported_signature_algorithms value, and the supported groups in the Supported Groups Extension in Client Hello. The evaluator shall verify any calls the product specifies align with the options provided in this PP and the Functional Package for Transport Layer Security (TLS), version 2.1.For platform-provided HTTPS, IPsec, TLS, or DTLS as a server the evaluator shall verify that the TSS lists any specific calls the product uses that specifies or allows the end users to specify cipher suites, which protocols are denied connection requests, key establishment algorithms, support for mutual authentication, response to an invalid client certificate, and support for session renegotiation. The evaluator shall verify any calls the product specifies align with the options provided in this PP and the Functional Package for Transport Layer Security (TLS), version 2.1.For platform-provided HTTPS the evaluator shall verify that the TSS lists any specific calls the product uses that specifies or allows the end users to specify the response to an invalid certificate.For platform-provided HTTPS as a server the evaluator shall verify that the TSS lists any specific calls the product uses that specifies or allows the end users to specify cipher suites, which protocols are denied connection requests, key establishment algorithms, support for mutual authentication, response to an invalid client certificate, and support for session renegotiation. The evaluator shall verify any calls the product specifies align with the options provided in this PP and the Functional Package for Transport Layer Security (TLS), version 2.1.For platform-provided SSH the evaluator shall verify that the TSS lists any specific calls the product uses that specifies or allows the end users to specify the applicable RFCs, the authentication methods, the limit for dropping large packets in an SSH transport connection, the SSH transport accepted algorithms, the SSH public key for public-key based authentication, The diffie-hellman-group used for key exchange, and the parameters of session rekey or termination. The evaluator shall verify any calls the product specifies align with the options provided in this PP and the . + The evaluator shall confirm the guidance documentation contains any information necessary for enabling and configuring the trusted channels that have been selected. + + The evaluator shall perform the following tests. + + If "not transmit any data" is selected, the evaluator shall exercise each of the TOE's identified functions, while observing the network traffic from the device and verify that no TSF initiated connections were observed during the attempts. + The evaluator shall exercise the application (attempting to transmit data; for example by connecting to remote systems or websites) while capturing packets from the application. The evaluator shall verify from the packet capture that the traffic is encrypted with HTTPS, TLS, DTLS, SSH, or IPsec in accordance with the selection in the ST. + The evaluator shall exercise the application (attempting to transmit data; for example by connecting to remote systems or websites) while capturing packets from the application. The evaluator shall review the packet capture and verify that no sensitive data is transmitted in the clear. + The evaluator shall inspect the TSS to determine if user credentials are transmitted. If credentials are transmitted the evaluator shall set the credential to a known value. The evaluator shall capture packets from the application while causing credentials to be transmitted as described in the TSS. The evaluator shall perform a string search of the captured network packets and verify that the plaintext credential previously set by the evaluator is not found. + + + + + + If "not transmit any data" is selected, the evaluator shall ensure that the application's AndroidManifest.xml file does not contain a uses-permission or uses-permission-sdk-23 tag containing android:name="android.permission.INTERNET". In this case, it is not necessary to perform the above Tests 1, 2, 3, or 4 as the platform will not allow the application to perform any network communication. + + + + + + + + If "encrypt all transmitted data" is selected, the evaluator shall ensure that the application's Info.plist file does not contain the NSAllowsArbitraryLoads or NSExceptionAllowsInsecureHTTPLoads keys, as these keys disable iOS's Application Transport Security feature. + + + + + + + +
+ + +
+ The PP identifies the Security Assurance Requirements (SARs) to frame the extent to which the evaluator assesses the documentation applicable for the evaluation and performs independent testing.This section lists the set of SARs from CC part 3 that are required in evaluations against this PP. Individual Evaluation Activities (EAs) to be performed are specified both in as well as in this section. These SARs were chosen based on the notion that a hypothetical attacker of the TOE lacks administrative privilege on its platform but otherwise has persistent access to the TOE itself and the sophistication to interact with the platform in a way that they can attempt to access stored data without authorization or to run tools that automate more sophisticated malicious activity.The general model for evaluation of TOEs against STs written to conform to this PP is as follows:After the ST has been approved for evaluation, the CCTL will obtain the TOE, supporting environmental IT, and the administrative/user guides for the TOE. The CCTL is expected to perform actions mandated by the Common Evaluation Methodology (CEM) for the ASE and ALC SARs. The CCTL also performs the evaluation activities contained within , which are intended to be an interpretation of the other CEM assurance requirements as they apply to the specific technology instantiated in the TOE. The evaluation activities that are captured in also provide clarification as to what the developer needs to provide to demonstrate the TOE is compliant with the PP. The results of these activities will be documented and presented (along with the administrative guidance used) for validation. +
As per ASE activities defined in .
+
+ + The information about the TOE is contained in the guidance documentation available to the end user as well as the TSS portion of the ST. The TOE developer must concur with the description of the product that is contained in the TSS as it relates to the functional requirements. The evaluation activities contained in should provide the ST authors with sufficient information to determine the appropriate content for the TSS section. + + + + The functional specification describes the TSFIs. It is not necessary to have a formal or complete specification of these interfaces. Additionally, because TOEs conforming to this PP will necessarily have interfaces to the Operational Environment that are not directly invocable by TOE users, there is little point specifying that such interfaces be described in and of themselves since only indirect testing of such interfaces may be possible. For this PP, the activities for this family should focus on understanding the interfaces presented in the TSS in response to the functional requirements and the interfaces presented in the AGD documentation. No additional โ€œfunctional specificationโ€ documentation is necessary to satisfy the evaluation activities specified. The interfaces that need to be evaluated are characterized through the information needed to perform the assurance activities listed, rather than as an independent, abstract list. + + + The developer shall provide a functional specification. + + + + The developer shall provide a tracing from the functional specification to the SFRs. + As indicated in the introduction to this section, the functional specification is comprised of the information contained in the AGD_OPE and AGD_PRE documentation. The developer may reference a website accessible to application developers and the evaluator. The evaluation activities in the functional requirements point to evidence that should exist in the documentation and TSS section; since these are directly associated with the SFRs, the tracing in element ADV_FSP.1.2D is implicitly already done and no additional documentation is necessary. + + + + The functional specification shall describe the purpose and method of use for each SFR-enforcing and SFR-supporting TSFI. + + + + The functional specification shall identify all parameters associated with each SFR-enforcing and SFR-supporting TSFI. + + + + The functional specification shall provide rationale for the implicit categorization of interfaces as SFR-non-interfering. + + + + The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification. + + + + The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. + + + + The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. + There are no specific evaluation activities associated with these SARs, except ensuring the information is provided. The functional specification documentation is provided to support the evaluation activities described in , and other activities described for AGD, ATE, and AVA SARs. The requirements on the content of the functional specification information is implicitly assessed by virtue of the other evaluation activities being performed; if the evaluator is unable to perform an activity because there is insufficient interface information, then an adequate functional specification has not been provided. + + +
+
+ + The guidance documents will be provided with the ST. Guidance must include a description of how the IT personnel verifies that the Operational Environment can fulfill its role for the security functionality. The documentation should be in an informal style and readable by the IT personnel. Guidance must be provided for every operational environment that the product supports as claimed in the ST. This guidance includes instructions to successfully install the TSF in that environment; and instructions to manage the security of the TSF as a product and as a component of the larger operational environment. Guidance pertaining to particular security functionality is also provided; requirements on such guidance are contained in the evaluation activities specified with each requirement. + + + + The developer shall provide operational user guidance. + The operational user guidance does not have to be contained in a single document. Guidance to users, administrators and application developers can be spread among documents or web pages. Where appropriate, the guidance documentation is expressed in the eXtensible Configuration Checklist Description Format (XCCDF) to support security automation. Rather than repeat information here, the developer should review the evaluation activities for this component to ascertain the specifics of the guidance that the evaluator will be checking for. This will provide the necessary information for the preparation of acceptable guidance. + + + + The operational user guidance shall describe, for each user role, the user-accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings. + User and administrator are to be considered in the definition of user role. + + + + The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure manner. + + + + The operational user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate. + + + + The operational user guidance shall, for each user role, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF. + + + + The operational user guidance shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences, and implications for maintaining secure operation. + + + + The operational user guidance shall, for each user role, describe the security measures to be followed in order to fulfill the security objectives for the operational environment as described in the ST. + + + + The operational user guidance shall be clear and reasonable. + + + + The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. + Some of the contents of the operational guidance will be verified by the evaluation activities in and evaluation of the TOE according to the . The following additional information is also required.If cryptographic functions are provided by the TOE, the operational guidance shall contain instructions for configuring the cryptographic engine associated with the evaluated configuration of the TOE. It shall provide a warning to the administrator that use of other cryptographic engines was not evaluated nor tested during the CC evaluation of the TOE.The documentation must describe the process for verifying updates to the TOE by verifying a digital signature โ€“ this may be done by the TOE or the underlying platform.The evaluator shall verify that this process includes the following steps:Instructions for obtaining the update itself. This should include instructions for making the update accessible to the TOE (e.g., placement in a specific directory).Instructions for initiating the update process, as well as discerning whether the process was successful or unsuccessful. This includes generation of the digital signature. The TOE will likely contain security functionality that does not fall in the scope of evaluation under this PP. The operational guidance shall make it clear to an administrator which security functionality is covered by the evaluation activities. + + + + + The developer shall provide the TOE, including its preparative procedures. + As with the operational guidance, the developer should look to the evaluation activities to determine the required content with respect to preparative procedures. + + + + The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer's delivery procedures. + + + + The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST. + + + + The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. + + + + The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation. + As indicated in the introduction above, there are significant expectations with respect to the documentationโ€”especially when configuring the operational environment to support TOE functional requirements. The evaluator shall check to ensure that the guidance provided for the TOE adequately addresses all platforms claimed for the TOE in the ST. + + +
+
+ + At the assurance level provided for TOEs conformant to this PP, life-cycle support is limited to end-user-visible aspects of the life-cycle, rather than an examination of the TOE vendorโ€™s development and configuration management process. This is not meant to diminish the critical role that a developerโ€™s practices play in contributing to the overall trustworthiness of a product; rather, it is a reflection on the information to be made available for evaluation at this assurance level. + + + + This component is targeted at identifying the TOE such that it can be distinguished from other products or versions from the same vendor and can be easily specified when being procured by an end user. + + + The developer shall provide the TOE and a reference for the TOE. + + + + The application shall be labeled with a unique reference. + Unique reference information includes:Application NameApplication VersionApplication DescriptionPlatform on which Application RunsSoftware Identification (SWID) tags, if available + + + + The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. + The evaluator shall check the ST to ensure that it contains an identifier (such as a product name/version number) that specifically identifies the version that meets the requirements of the ST. Further, the evaluator shall check the operational guidance and TOE samples received for testing to ensure that the version number is consistent with that in the ST. If the vendor maintains a website advertising the TOE, the evaluator shall examine the information on the website to ensure that the information in the ST is sufficient to distinguish the product. + + + + + The developer shall provide a configuration list for the TOE. + + + + The configuration list shall include the following: the TOE itself; and the evaluation evidence required by the SARs. + + + + The configuration list shall uniquely identify the configuration items. + + + + The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. + The "evaluation evidence required by the SARs" in this PP is limited to the information in the ST coupled with the guidance provided to administrators and users under the AGD requirements. By ensuring that the TOE is specifically identified and that this identification is consistent in the ST and in the AGD guidance (as done in the evaluation activity for ALC_CMC.1), the evaluator implicitly confirms the information required by this component. Life-cycle support is targeted aspects of the developerโ€™s life-cycle and instructions to providers of applications for the developerโ€™s devices, rather than an in-depth examination of the TSF manufacturerโ€™s development and configuration management process. This is not meant to diminish the critical role that a developerโ€™s practices play in contributing to the overall trustworthiness of a product; rather, itโ€™s a reflection on the information to be made available for evaluation.The evaluator shall ensure that the developer has identified (in guidance documentation for application developers concerning the targeted platform) one or more development environments appropriate for use in developing applications for the developerโ€™s platform. For each of these development environments, the developer shall provide information on how to configure the environment to ensure that buffer overflow protection mechanisms in the environment(s) are invoked (e.g., compiler flags). The evaluator shall ensure that this documentation also includes an indication of whether such protections are on by default, or have to be specifically enabled. The evaluator shall ensure that the TSF is uniquely identified (with respect to other products from the TSF vendor), and that documentation provided by the developer in association with the requirements in the ST is associated with the TSF using this unique identification. + + + + + The developer shall document and provide flaw remediation procedures addressed to TOE developers. + + + + The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE. + + + + The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw. + + + + The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws. + + + + The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users. + + + + The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. + The evaluator shall inspect the TSS and verify it identifies how to access the flaw remediation procedures. + + + + + The developer shall document and provide flaw remediation procedures addressed to TOE developers. + + + + The developer shall establish a procedure for accepting and acting upon all reports of security flaws and requests for corrections to those flaws. + + + + The developer shall provide flaw remediation guidance addressed to TOE users. + + + + The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE. + + + + The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw. + + + + The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws. + + + + The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users. + + + + The flaw remediation procedures shall describe a means by which the developer receives from TOE users reports and enquiries of suspected security flaws in the TOE. + + + + The procedures for processing reported security flaws shall ensure that any reported flaws are remediated and the remediation procedures issued to TOE users. + + + + The procedures for processing reported security flaws shall provide safeguards that any corrections to these security flaws do not introduce any new flaws. + + + + The flaw remediation guidance shall describe a means by which TOE users report to the developer any suspected security flaws in the TOE. + + + + The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. + The evaluator shall inspect the TSS and verify it identifies how to access the flaw remediation procedures.The evaluator shall inspect the guidance document and verify it describes how to access the flaw remediation guidance. + + + + + The developer shall document and provide flaw remediation procedures addressed to TOE developers. + + + + The developer shall establish a procedure for accepting and acting upon all reports of security flaws and requests for corrections to those flaws. + + + + The developer shall provide flaw remediation guidance addressed to TOE users. + + + + The flaw remediation procedures documentation shall describe the procedures used to track all reported security flaws in each release of the TOE. + + + + The flaw remediation procedures shall require that a description of the nature and effect of each security flaw be provided, as well as the status of finding a correction to that flaw. + + + + The flaw remediation procedures shall require that corrective actions be identified for each of the security flaws. + + + + The flaw remediation procedures documentation shall describe the methods used to provide flaw information, corrections and guidance on corrective actions to TOE users. + + + + The flaw remediation procedures shall describe a means by which the developer receives from TOE users reports and enquiries of suspected security flaws in the TOE. + + + + The flaw remediation procedures shall include a procedure requiring timely response and the automatic distribution of security flaw reports and the associated corrections to registered users who might be affected by the security flaw. + + + + The procedures for processing reported security flaws shall ensure that any reported flaws are remediated and the remediation procedures issued to TOE users. + + + + The procedures for processing reported security flaws shall provide safeguards that any corrections to these security flaws do not introduce any new flaws. + + + + The flaw remediation guidance shall describe a means by which TOE users report to the developer any suspected security flaws in the TOE. + + + + The flaw remediation guidance shall describe a means by which TOE users may register with the developer, to be eligible to receive security flaw reports and corrections. + + + + The flaw remediation guidance shall identify the specific points of contact for all reports and enquiries about security issues involving the TOE. + + + + The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. + The evaluator shall inspect the TSS and verify it identifies how to access the flaw remediation procedures.The evaluator shall inspect the guidance document and verify it describes how to access the flaw remediation guidance. + + + + + This component requires the TOE developer, in conjunction with any other necessary parties, to provide information as to how the end-user devices are updated to address security issues in a timely manner. The documentation describes the process of providing updates to the public from the time a security flaw is reported/discovered, to the time an update is released. This description includes the parties involved (e.g., the developer, carriers(s)) and the steps that are performed (e.g., developer testing, carrier testing), including worst case time periods, before an update is made available to the public. + + + The developer shall provide a description in the TSS of how timely security updates are made to the TOE. + Application developers must support updates to their products for purposes of fixing security vulnerabilities. + + + + The developer shall provide a description in the TSS of how users are notified when updates change security properties or the configuration of the product. + + + + The description shall include the process for creating and deploying security updates for the TOE software. + + + + The description shall express the time window as the length of time, in days, between public disclosure of a vulnerability and the public availability of security updates to the TOE. + + + + The description shall include the mechanisms publicly available for reporting security issues pertaining to the TOE. + The reporting mechanism could include a website or email address as well as a means to protect the sensitive nature of the report (e.g., public keys that could be used to encrypt the details of a proof-of-concept exploit). + + + + The evaluator <h:i>shall confirm</h:i> that the information provided meets all requirements for content and presentation of evidence. + The evaluator shall verify that the TSS contains a description of the timely security update process used by the developer to create and deploy security updates. The evaluator shall verify that this description addresses the entire application. The evaluator shall also verify that, in addition to the TOE developerโ€™s process, any third-party processes are also addressed in the description. The evaluator shall also verify that each mechanism for deployment of security updates is described.The evaluator shall verify that, for each deployment mechanism described for the update process, the TSS lists a time between public disclosure of a vulnerability and public availability of the security update to the TOE patching this vulnerability, to include any third-party or carrier delays in deployment. The evaluator shall verify that this time is expressed in a number or range of days.The evaluator shall verify that this description includes the publicly available mechanisms (including either an email address or website) for reporting security issues related to the TOE. The evaluator shall verify that the description of this mechanism includes a method for protecting the report either using a public key for encrypting email or a trusted channel for a website. + + +
+
+ + Testing is specified for functional aspects of the system as well as aspects that take advantage of design or implementation weaknesses. The former is done through the ATE_IND family, while the latter is through the AVA_VAN family. At the assurance level specified in this PP, testing is based on advertised functionality and interfaces with dependency on the availability of design information. One of the primary outputs of the evaluation process is the test report as specified in the following requirements. + + + + Testing is performed to confirm the functionality described in the TSS as well as the administrative (including configuration and operational) documentation provided. The focus of the testing is to confirm that the requirements specified in are being met, although some additional testing is specified for SARs in . The evaluation activities identify the additional testing activities associated with these components. The evaluator produces a test report documenting the plan for and results of testing, as well as coverage arguments focused on the platform/TOE combinations that are claiming conformance to this PP. Given the scope of the TOE and its associated evaluation evidence requirements, this componentโ€™s evaluation activities are covered by the evaluation activities listed for ALC_CMC.1. + + + The developer shall provide the TOE for testing. + The developer must provide at least one product instance of the TOE for complete testing on at least one platform regardless of equivalency. See the Equivalency Appendix for more details. + + + + The TOE shall be suitable for testing. + + + + The evaluator <h:i>shall confirm</h:i> that the information provided meets all requirements for content and presentation of evidence. + + + + The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified. + The evaluator should test the application on the most current fully patched version of the platform. + The evaluator shall prepare a test plan and report documenting the testing aspects of the system, including any application crashes during testing. The evaluator shall determine the root cause of any application crashes and include that information in the report. The test plan covers all of the testing actions contained in the and the body of this PPโ€™s evaluation activities.While it is not necessary to have one test case per test listed in an evaluation activity, the evaluator must document in the test plan that each applicable testing requirement in the ST is covered. The test plan identifies the platforms to be tested, and for those platforms not included in the test plan but included in the ST, the test plan provides a justification for not testing the platforms. This justification must address the differences between the tested platforms and the untested platforms, and make an argument that the differences do not affect the testing to be performed. It is not sufficient to merely assert that the differences have no effect; rationale must be provided. If all platforms claimed in the ST are tested, then no rationale is necessary. The test plan describes the composition of each platform to be tested, and any setup that is necessary beyond what is contained in the AGD documentation. It should be noted that the evaluator is expected to follow the AGD documentation for installation and setup of each platform either as part of a test or as a standard pre-test condition. This may include special test drivers or tools. For each driver or tool, an argument (not just an assertion) should be provided that the driver or tool will not adversely affect the performance of the functionality by the TOE and its platform.This also includes the configuration of the cryptographic engine to be used. The cryptographic algorithms implemented by this engine are those specified by this PP and used by the cryptographic protocols being evaluated (e.g., SSH). The test plan identifies high-level test objectives as well as the test procedures to be followed to achieve those objectives. These procedures include expected results.The test report (which could just be an annotated version of the test plan) details the activities that took place when the test procedures were executed, and includes the actual results of the tests. This shall be a cumulative account, so if there was a test run that resulted in a failure; a fix installed; and then a successful re-run of the test, the report would show a โ€œfailโ€ and โ€œpassโ€ result (and the supporting details), and not just the โ€œpassโ€ result. + + +
+
+ + For the current generation of this protection profile, the evaluation lab is expected to survey open sources to discover what vulnerabilities have been discovered in these types of products. In most cases, these vulnerabilities will require sophistication beyond that of a basic attacker. Until penetration tools are created and uniformly distributed to the evaluation labs, the evaluator will not be expected to test for these vulnerabilities in the TOE. The labs will be expected to comment on the likelihood of these vulnerabilities given the documentation provided by the vendor. This information will be used in the development of penetration testing tools and for the development of future protection profiles. + + + + The developer shall provide the TOE for testing. + + + + The application shall be suitable for testing. + Suitability for testing means not being obfuscated or packaged in such a way as to disrupt either static or dynamic analysis by the evaluator. + + + + The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. + + + + The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE. + Public domain sources include the Common Vulnerabilities and Exposures (CVE) dictionary for publicly known vulnerabilities. Public domain sources also include sites which provide free checking of files for viruses. + + + + The evaluator shall conduct penetration testing, based on the identified potential vulnerabilities, to determine that the TOE is resistant to attacks performed by an attacker possessing Basic attack potential. + The evaluator shall generate a report to document their findings with respect to this requirement. This report could physically be part of the overall test report mentioned in ATE_IND, or a separate document. The evaluator performs a search of public information to find vulnerabilities that have been found in similar applications with a particular focus on network protocols the application uses and document formats it parses.The evaluator documents the sources consulted and the vulnerabilities found in the report.For each vulnerability found, the evaluator either provides a rationale with respect to its non-applicability, or the evaluator formulates a test (using the guidelines provided in ATE_IND) to confirm the vulnerability, if suitable. Suitability is determined by assessing the attack vector needed to take advantage of the vulnerability. If exploiting the vulnerability requires expert skills and an electron microscope, for instance, then a test would not be suitable and an appropriate justification would be formulated. The evaluator shall also run a virus scanner with the most current virus definitions against the application files and verify that no files are flagged as malicious. + + +
+
+ + This appendix describes the required supplementary information for the entropy source used by the TOE. The documentation of the entropy source should be detailed enough that, after reading, the evaluator will thoroughly understand the entropy source and why it can be relied upon to provide sufficient entropy. This documentation should include multiple detailed sections: design description, entropy justification, operating conditions, and health testing. This documentation is not required to be part of the TSS.
Documentation shall include the design of the entropy source as a whole, including the interaction of all entropy source components. Any information that can be shared regarding the design should also be included for any third-party entropy sources that are included in the product. The documentation shall describe how unprocessed (raw) data was obtained for the analysis. This description shall be sufficiently detailed to explain at what point in the entropy source model the data was collected and what effects, if any, the process of data collection had on the overall entropy generation rate. The documentation should walk through the entropy source design indicating where the entropy comes from, where the entropy output is passed next, any post-processing of the raw outputs (hash, XOR, etc.), if/where it is stored, and finally, how it is output from the entropy source. Any conditions placed on the process (e.g., blocking) should also be described in the entropy source design. Diagrams and examples are encouraged. This design must also include a description of the content of the security boundary of the entropy source and a description of how the security boundary ensures that an adversary outside the boundary cannot affect the entropy rate. If implemented, the design description shall include a description of how third-party applications can add entropy to the RBG. A description of any RBG state saving between power-off and power-on shall be included.
There should be a technical argument for where the unpredictability in the source comes from and why there is confidence in the entropy source delivering sufficient entropy for the uses made of the RBG output (by this particular TOE). This argument will include a description of the expected min-entropy rate (i.e. the minimum entropy (in bits) per bit or byte of source data) and explain that sufficient entropy is going into the TOE randomizer seeding process. This discussion will be part of a justification for why the entropy source can be relied upon to produce bits with entropy. The amount of information necessary to justify the expected min-entropy rate depends on the type of entropy source included in the product. For developer provided entropy sources, in order to justify the min-entropy rate, it is expected that a large number of raw source bits will be collected, statistical tests will be performed, and the min-entropy rate determined from the statistical tests. While no particular statistical tests are required at this time, it is expected that some testing is necessary in order to determine the amount of min-entropy in each output. For third party provided entropy sources, in which the TOE vendor has limited access to the design and raw entropy data of the source, the documentation will indicate an estimate of the amount of min-entropy obtained from this third-party source. It is acceptable for the vendor to โ€œassumeโ€ an amount of min-entropy, however, this assumption must be clearly stated in the documentation provided. In particular, the min-entropy estimate must be specified and the assumption included in the ST. Regardless of type of entropy source, the justification will also include how the DRBG is initialized with the entropy stated in the ST, for example by verifying that the min-entropy rate is multiplied by the amount of source data used to seed the DRBG or that the rate of entropy expected based on the amount of source data is explicitly stated and compared to the statistical rate. If the amount of source data used to seed the DRBG is not clear or the calculated rate is not explicitly related to the seed, the documentation will not be considered complete. The entropy justification shall not include any data added from any third-party application or from any state saving between restarts.
The entropy rate may be affected by conditions outside the control of the entropy source itself. For example, voltage, frequency, temperature, and elapsed time after power-on are just a few of the factors that may affect the operation of the entropy source. As such, documentation will also include the range of operating conditions under which the entropy source is expected to generate random data. It will clearly describe the measures that have been taken in the system design to ensure the entropy source continues to operate under those conditions. Similarly, documentation shall describe the conditions under which the entropy source is known to malfunction or become inconsistent. Methods used to detect failure or degradation of the source shall be included.
More specifically, all entropy source health tests and their rationale will be documented. This will include a description of the health tests, the rate and conditions under which each health test is performed (e.g., at startup, continuously, or on-demand), the expected results for each health test, and rationale indicating why each test is believed to be appropriate for detecting one or more failures in the entropy source.
+
The purpose of equivalence in PP-based evaluations is to find a balance between evaluation rigor and commercial practicabilityโ€”to ensure that evaluations meet customer expectations while recognizing that there is little to be gained from requiring that every variation in a product or platform be fully tested. If a product is found to be compliant with a PP on one platform, then all equivalent products on equivalent platforms are also considered to be compliant with the PP. A Vendor can make a claim of equivalence if the Vendor believes that a particular instance of their Product implements PP-specified security functionality in a way equivalent to the implementation of the same functionality on another instance of their Product on which the functionality was tested. The Product instances can differ in version number or feature level (model), or the instances may run on different platforms. Equivalency can be used to reduce the testing required across claimed evaluated configurations. It can also be used during Assurance Maintenance to reduce testing needed to add more evaluated configurations to a certification. These equivalency guidelines do not replace Assurance Maintenance requirements or scheme-specific policy requirements for CAVP certificates. Nor may equivalency be used to leverage evaluations with expired certifications. These Equivalency Guidelines represent a shift from complete testing of all product instances to more of a risk-based approach. Rather than require that every combination of product and platform be tested, these guidelines support an approach that recognizes that products are being used in a variety of environmentsโ€”and often in cloud environments over where the vendor (and sometimes the customer) have little or no control over the underlying hardware. Developers should be responsible for the security functionality of their applications on the platforms they are developed forโ€”whether that is an operating system, a virtual machine, or a software-based execution environment such as a container. But those platforms may themselves run within other environmentsโ€”virtual machines or operating systemsโ€”that completely abstract away the underlying hardware from the application. The developer should not be held accountable for security functionality that is implemented by platform layers that are abstracted away. The implication is that not all security functionality will necessarily be tested for all platform layers down to the hardware for all evaluated configurationsโ€”especially for applications developed for software-based execution environments such as containers. For these cases, the balancing of evaluation rigor and commercial practicability tips in favor of practicability. Note that this does not affect the requirement that at least one product instance be fully tested on at least one platform with cryptography mapped to a CAVP certificate. Equivalency has two aspects: Product Equivalence: Products may be considered equivalent if there are no differences between Product Models and Product Versions with respect to PP-specified security functionality. Platform Equivalence: Platforms may be considered equivalent if there are no significant differences in the services they provide to the Productโ€”or in the way the platforms provide those servicesโ€”with respect to PP-specified security functionality. The equivalency determination is made in accordance with these guidelines by the Validator and Scheme using information provided by the Evaluator/Vendor.
There are two scenarios for performing equivalency analysis. One is when a product has been certified and the vendor wants to show that a later product should be considered certified due to equivalence with the earlier product. The other is when multiple product variants are going though evaluation together and the vendor would like to reduce the amount of testing that must be done. The basic rules for determining equivalence are the same in both cases. But there is one additional consideration that applies to equivalence with previously certified products. That is, the product with which equivalence is being claimed must have a valid certification in accordance with scheme rules and the Assurance Maintenance process must be followed. If a productโ€™s certification has expired, then equivalence cannot be claimed with that product. When performing equivalency analysis, the Evaluator/Vendor should first use the factors and guidelines for Product Model equivalence to determine the set of Product Models to be evaluated. In general, Product models that do not differ in PP-specified security functionality are considered equivalent for purposes of evaluation against the this PP. If multiple revision levels of Product Models are to be evaluatedโ€”or to determine whether a revision of an evaluated product needs re-evaluationโ€”the Evaluator/Vendor and Validator should use the factors and guidelines for Product Version equivalence to analyze whether Product Versions are equivalent. Having determined the set of Product Models and Versions to be evaluated, the next step is to determine the set of Platforms that the Products must be tested on. Each non-equivalent Product for which compliance is claimed must be fully tested on each non-equivalent platform for which compliance is claimed. For non-equivalent Products on equivalent platforms, only the differences that affect PP-specified security functionality must be tested for each product. โ€œDifferences in PP-Specified Security Functionalityโ€ Defined If PP-specified security functionality is implemented by the TOE, then differences in the actual implementation between versions or product models break equivalence for that feature. Likewise, if the TOE implements the functionality in one version or model and the functionality is implemented by the platform in another version or model, then equivalence is broken. If the functionality is implemented by the platform in multiple models or versions on equivalent platforms, then the functionality is considered different if the product invokes the platform differently to perform the function.
Product Model equivalence attempts to determine whether different feature levels of the same product across a product line are equivalent for purposes of PP testing. For example, if a product has a โ€œbasicโ€ edition and an โ€œenterpriseโ€ edition, is it necessary to test both models? Or does testing one model provide sufficient assurance that both models are compliant? Product models are considered equivalent if there are no differences that affect PP-specified security functionalityโ€”as indicated in Table 1. Factor Same/Different Guidance PP-Specified Functionality Same If the differences between Models affect only non-PP-specified functionality, then the Models are equivalent. Different If PP-specified security functionality is affected by the differences between Models, then the Models are not equivalent and must be tested separately. It is necessary only to test the functionality affected by the software differences. If only differences are tested, then the differences must be enumerated, and for each difference the Vendor must provide an explanation of why each difference does or does not affect PP-specified functionality. If the Product Models are separately tested fully, then there is no need to document the differences. Table 1. Determining Product Model Equivalence
In cases of version equivalence, differences are expressed in terms of changes implemented in revisions of an evaluated Product. In general, versions are equivalent if the changes have no effect on any security-relevant claims about the TOE or assurance evidence. Non-security-relevant changes to TOE functionality or the addition of non-security-relevant functionality does not affect equivalence. Factor Same/Different Guidance Product Models Different Versions of different Product Models are not equivalent unless the Models are equivalent as defined in Section 3. PP-Specified Functionality Same If the differences affect only non-PP-specified functionality, then the Versions are equivalent. Different If PP-specified security functionality is affected by the differences, then the Versions are not considered equivalent and must be tested separately. It is necessary only to test the functionality affected by the changes. If only the differences are tested, then for each difference the Vendor must provide an explanation of why the difference does or does not affect PP-specified functionality. If the Product Versions are separately tested fully, then there is no need to document the differences. Table 2. Factors for Determining Product Version Equivalence
Platform equivalence is used to determine the platforms that equivalent versions of a Product must be tested on. Platform equivalence analysis done for one software application cannot be applied to another software application. Platform equivalence is not generalโ€”it is with respect to a particular application. Product Equivalency analysis must already have been done and Products have been determined to be equivalent. The platform can be hardware or virtual hardware, an operating system or similar entity, or a software execution environment such as a container. For purposes of determining equivalence for software applications, we address each type of platform separately. In general, platform equivalence is based on differences in the interfaces between the TOE and Platform that are relevant to the implementation of PP-specified security functionality.
If an application runs directly on hardware without an operating systemโ€”or directly on virtualized hardware without an operating systemโ€”then platform equivalence is based on processor architecture and instruction sets. In the case of virtualized hardware, it is the virtualized processor and architecture that are presented to the application that mattersโ€”not the physical hardware. Platforms with different processor architectures and instruction sets are not equivalent. This is not likely to be an issue for equivalency analysis for applications since there is likely to be a different version of the application for different hardware environments. Equivalency analysis becomes important when comparing processors with the same architecture. Processors with the same architecture that have instruction sets that are subsets or supersets of each other are not disqualified from being equivalent for purposes of an App evaluation. If the application takes the same code paths when executing PP-specified security functionality on different processors of the same family, then the processors can be considered equivalent with respect to that application. For example, if an application follows one code path on platforms that support the AES-NI instruction and another on platforms that do not, then those two platforms are not equivalent with respect to that application functionality. But if the application follows the same code path whether or not the platform supports AES-NI, then the platforms are equivalent with respect to that functionality. The platforms are equivalent with respect to the application if the platforms are equivalent with respect to all PP-specified security functionality. Factor Same/Different/None Guidance Platform Architectures Different Platforms that present different processor architectures and instruction sets to the application are not equivalent. PP-Specified Functionality Same For platforms with the same processor architecture, the platforms are equivalent with respect to the application if execution of all PP-specified security functionality follows the same code path on both platforms. Table 3. Factors for Determining Hardware/Virtual Hardware Platform Equivalence
For traditional applications that are built for and run on operating systems, platform equivalence is determined by the interfaces between the application and the operating system that are relevant to PP-specified security functionality. Generally, these are the processor interface, device interfaces, and OS APIs. The following factors applied in order: Factor Same/Different/None Guidance Platform Architectures Different Platforms that run on different processor architectures and instruction sets are not equivalent. Platform Vendors Different Platforms from different vendors are not equivalent. Platform Versions Different Platforms from the same vendor with different major version numbers are not equivalent. Platform Interfaces Different Platforms from the same vendor and major version are not equivalent if there are differences in device interfaces and OS APIs that are relevant to the way the platform provides PP-specified security functionality to the application. Platform Interfaces Same Platforms from the same vendor and major version are equivalent if there are no differences in device interfaces and OS APIs that are relevant to the way the platform provides PP-specified security functionality to the application, or if the Platform does not provide such functionality to the application. Table 4. Factors for Determining OS/VS Platform Equivalence
If an Application is built for and runs in a non-OS software-based execution environment, such as a Container or Java Runtime, then the below criteria must be used to determine platform equivalence. The key point is that the underlying hardware (virtual or physical) and OS is not relevant to platform equivalence. This allows applications to be tested and run on software-based execution environments on any hardwareโ€”as in cloud deployments. Factor Same/Different/None Guidance Platform Type/Vendor Different Software-based execution environments that are substantially different or come from different vendors are not equivalent. For example, a Java virtual machine is not the same as a container. A Docker container is not the same as a CoreOS container. Platform Versions Different Execution environments that are otherwise equivalent are not equivalent if they have different major version numbers. PP-Specified Security Functionality Same All other things being equal, execution environments are equivalent if there is no significant difference in the interfaces through which the environments provide PP-specified security functionality to applications. Table 5. Factors for Software-based Execution Environment Platform Equivalence
In order to make equivalency determinations, the vendor and evaluator must agree on the equivalency claims. They must then provide the scheme with sufficient information about the TOE instances and platforms that were evaluated, and the TOE instances and platforms that are claimed to be equivalent. The ST must describe all configurations evaluated down to processor manufacturer, model number, and microarchitecture version. The information regarding claimed equivalent configurations depends on the platform that the application was developed for and runs on. Bare-Metal Applications For applications that run without an operating system on bare-metal or virtual bare-metal, the claimed configuration must describe the platform down to the specific processor manufacturer, model number, and microarchitecture version. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage platform differences (e.g., instruction set extensions) in the tested configuration versus the claimed equivalent configuration. Traditional Applications For applications that run with an operating system as their immediate platform, the claimed configuration must describe the platform down to the specific operating system version. If the platform is a virtualization system, then the claimed configuration must describe the platform down to the specific virtualization system version. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage platform differences in the tested configuration versus the claimed equivalent configuration. Relevant platform differences could include instruction sets, device interfaces, and OS APIs invoked by the TOE to implement PP-specified security functionality. Software-Based Execution Environments For applications that run in a software-based execution environment such as a Java virtual machine or a Container, then the claimed configuration must describe the platform down to the specific version of the software execution environment. The Vendor must describe the differences in the TOE with respect to PP-specified security functionality and how the TOE functions differently to leverage platform differences in the tested configuration versus the claimed equivalent configuration.
+ + + + OMB + Reporting Incidents Involving Personally Identifiable Information and Incorporating the + Cost for Security in Agency Information Technology Investments, OMB M-06-19, July 12, 2006. + + + diff --git a/input/cc.xml b/input/cc.xml new file mode 100755 index 0000000..c6902b9 --- /dev/null +++ b/input/cc.xml @@ -0,0 +1,53805 @@ + + + + + + + For the purposes of this document, the terms, definitions, + symbols and abbreviated terms given in CC Part 1 apply. + + + + Security assurance components, as defined in this CC Part 3, are + the basis for the security assurance requirements expressed in a + Protection Profile (PP) or a Security Target (ST). + + These requirements establish a standard way of expressing the + assurance requirements for TOEs. This CC Part 3 catalogues the + set of assurance components, families and classes. This CC Part + 3 also defines evaluation criteria for PPs and STs and presents + evaluation assurance levels that define the predefined CC scale + for rating assurance for TOEs, which is called the Evaluation + Assurance Levels (EALs). + + The audience for this CC Part 3 includes consumers, developers, + and evaluators of secure IT products. CC Part 1 Clause provides additional information + on the target audience of the CC, and on the use of the CC by + the groups that comprise the target audience. These groups may + use this part of the CC as follows: + + + Consumers, who use this CC Part 3 when selecting components + to express assurance requirements to satisfy the security + objectives expressed in a PP or ST, determining required + levels of security assurance of the TOE. + + + Developers, who respond to actual or perceived consumer + security requirements in constructing a TOE, reference this + CC Part 3 when interpreting statements of assurance + requirements and determining assurance approaches of TOEs. + + + Evaluators, who use the assurance requirements defined in + this part of the CC as mandatory statement of evaluation + criteria when determining the assurance of TOEs and when + evaluating PPs and STs. + + + + + + + Clause describes the paradigm + used in the security assurance requirements of CC Part + 3. + + Clause describes the + presentation structure of the assurance classes, families, + components, evaluation assurance levels along with their + relationships, and the structure of the composed assurance + packages. It also characterises the assurance classes and + families found in Clauses through + . + + Clause provides detailed + definitions of the EALs. + + Clause provides detailed + definitions of the CAPs. + + Clauses through provide the detailed definitions of the CC Part 3 + assurance classes. + + provides further + explanations and examples of the concepts behind the + Development class. + + provides an explanation of + the concepts behind composed TOE evaluations and the + Composition class. + + provides + a summary of the dependencies between the assurance + components. + + provides a cross + reference between PPs and the families and components of the + class. + + provides a cross reference + between the EALs and the assurance components. + + provides a cross reference + between the CAPs and the assurance components. + + + + + The following referenced documents are indispensable for the + application of this document. For dated references, only the + edition cited applies. For undated references, the latest + edition of the referenced document (including any amendments) + applies. + + CC-1 + + Common Criteria for Information Technology Security + Evaluation, Version _CCVERSION_, revision _CCREVISION_, + _CCDATE_. Part 1: Introduction and general model. + + + + CC-2 + + Common Criteria for Information Technology Security + Evaluation, Version _CCVERSION_, revision _CCREVISION_, + _CCDATE_. Part 2: Functional security components. + + + + + + This CC Part 3 defines the assurance requirements of the CC. It + includes the evaluation assurance levels (EALs) that define a + scale for measuring assurance for component TOEs, the composed + assurance packages (CAPs) that define a scale for measuring + assurance for composed TOEs, the individual assurance components + from which the assurance levels and packages are composed, and + the criteria for evaluation of PPs and STs. + + + + The goal of this annex is to explain the concepts behind + composition evaluations and the + criteria. This annex does not define the criteria; this definition can be found in clause + . + + + The IT market is, on the whole, made up of vendors offering a + particular type of product/technology. Although there is some + overlap, where a PC hardware vendor may also offer application + software and/or operating systems or a chip manufacturer may + also develop a dedicated operating system for their own + chipset, it is often the case that an IT solution is + implemented by a variety of vendors. + + There is sometimes a need for assurance in the combination + (composition) of components in addition to the assurance of + the individual components. Although there is cooperation + between these vendors, in the dissemination of certain + material required for the technical integration of the + components, the agreements rarely stretch to the extent of + providing detailed design information and development + process/procedure evidence. This lack of information from the + developer of a component on which another component relies + means that the dependent component developer does not have + access to the type of information necessary to perform an + evaluation of both the dependent and base components at EAL2 + or above. Therefore, while an evaluation of the dependent + component can still be performed at any assurance level, to + compose components with assurance at EAL2 or above it is + necessary to reuse the evaluation evidence and results of + evaluations performed for the component developer. + + It is intended that the criteria + are applicable in the situation where one IT entity is + dependent on another for the provision of security + services. The entity providing the services is termed the + ``base component'', and that receiving the services is termed + the ``dependent component''. This relationship may exist in a + number of contexts. For example, an application (dependent + component) may use services provided by an operating system + (base component). Alternatively, the relationship may be + peer-to-peer, in the sense of two linked applications, either + running in a common operating system environment, or on + separate hardware platforms. If there is a dominant peer + providing the services to the minor peer, the dominant peer is + considered to be the base component and the minor peer the + dependent component. If the peers provide services to each + other in a mutual manner, each peer will be considered to be + the base component for the services offered and dependent + component for the services required. This will require + iterations of the components + applying all requirements to each type of component + peer. + + The criteria are also intended to be more broadly applicable, + stepwise (where a composed TOE comprised of a dependent + component and a base component itself becomes the base + component of another composed TOE), in more complex + relationships, but this may require further + interpretation. + + It is still required for composed TOE evaluations that the + individual components are evaluated independently, as the + composition evaluation builds on the results of the individual + component evaluations. The evaluation of the dependent + component may still be in progress when the composed TOE + evaluation commences. However, the dependent component + evaluation must complete before the composed TOE evaluation + completes. + + The composed evaluation activities may take place at the same + time as the dependent component evaluation. This is due to two + factors: + + + Economic/business drivers - the dependent component + developer will either be sponsoring the composition + evaluation activities or supporting these activities as + the evaluation deliverables from the dependent component + evaluation are required for composed evaluation + activities. + + Technical drivers - the components consider whether the + requisite assurance is provided by the base component + (e.g. considering the changes to the base component since + completion of the component evaluation) with the + understanding that the dependent component has recently + undergone (is undergoing) component evaluation and all + evaluation deliverables associated with the evaluation are + available. Therefore, there are no activities during + composition requesting the dependent component evaluation + activities to be re-verified. Also, it is verified that + the base component forms (one of) the test configurations + for the testing of the dependent component during the + dependent component evaluation, leaving to consider the base component in this + configuration. + + The evaluation evidence from the evaluation of the dependent + component is required input into the composed TOE evaluation + activities. The only evaluation material from the evaluation + of the base component that is required as input into the + composed TOE evaluation activities: + + + Residual vulnerabilities in the base component, as + reported during the base component evaluation. This is + required for the + activities. + + No other evaluation evidence from the base component + activities should be required for the composed TOE evaluation, + as the evaluation results from the component evaluation of the + base component should be reused. Additional information about + the base component may be required if the composed TOE TSF + includes more of the base component than was considered to be + TSF during component evaluation of the base component. + + The component evaluation of the base and dependent components + are assumed to be complete by the time final verdicts are + assigned for the components. + + The components only consider + resistance against an attacker with an attack potential up to + Enhanced-Basic. This is due to the level of design information + that can be provided of how the base component provides the + services on which the dependent component relies through + application of the + activities. Therefore, the confidence arising from composed TOE + evaluations using CAPs is limited to a level similar to that + obtained from EAL4 component TOE evaluations. Although + assurance in the components that comprise the composed TOE may + be higher than EAL4. + + + + An ST will be submitted by the developer for the evaluation of + the composed (base component + dependent component) TOE. This + ST will identify the assurance package to be applied to the + composed TOE, providing assurance in the composed entity by + drawing upon the assurance gained in the component + evaluations. + + The purpose of considering the composition of components + within an ST is to validate the compatibility of the + components from the point of view of both the environment and + the requirements, and also to assess that the composed TOE ST + is consistent with the component STs and the security policies + expressed within them. This includes determining that the + component STs and the security policies expressed within them + are compatible. + + The composed TOE ST may refer out to the content of the + component STs, or the ST author may chose to reiterate the + material of the component STs within the composed TOE ST + providing a rationale of how the component STs are represented + in the composed TOE ST. + + During the conduct of the + evaluation activities for a composed TOE ST the evaluator + determines that the component STs are accurately represented + in the composed TOE ST. This is achieved through determining + that the composed TOE ST demonstrably conforms to the + component TOE STs. Also, the evaluator will need to determine + that the dependencies of the dependent component on the + operational environment are adequately fulfilled in the + composed TOE. + + The composed TOE description will describe the composed + solution. The logical and physical scope and boundary of the + composed solution will be described, and the logical + boundary(ies) between the components will also be + identified. The description will identify the security + functionality to be provided by each component. + + The statement of SFRs for the composed TOE will identify which + component is to satisfy an SFR. If an SFR is met by both + components, then the statement will identify which component + meets the different aspects of the SFR. Similarly the composed + TOE Summary Specification will identify which component + provides the security functionality described. + + The package of requirements + applied to the composed TOE ST should be consistent with the + package of requirements used in + the component evaluations. + + Reuse of evaluation results from the evaluation of component + STs can be made in the instances that the composed TOE ST + directly refers to the component STs. e.g. if the composed TOE + ST refers to a component ST for part of its statement of SFRs, + the evaluator can understand that the requirement for the + completion of all assignment and selection operations (as + stated in .*.3C has been + satisfied in the component evaluations. + + + + The TSF of the base component is often defined without + knowledge of the dependencies of the possible applications + with which it may by composed. The TSF of this base component + is defined to include all parts of the base component that + have to be relied upon for enforcement of the base component + SFRs. This will include all parts of the base component + required to implement the base component SFRs. + + The TSFI of this base component represents the interfaces + provided by the TSF to the external entities defined in the + statement of SFRs to invoke a service of the TSF. This + includes interfaces to the human user and also interfaces to + external IT entities. However, the TSFI only includes those + interfaces to the TSF, and therefore is not necessarily an + exhaustive interface specification of all possible interfaces + available between an external entity and the base + component. The base component may present interfaces to + services that were not considered security-relevant, either + because of the inherent purpose of the service (e.g., adjust + type font) or because associated CC SFRs are not being claimed + in the base component's ST (e.g. the login interface when no + SFRs are claimed). + + The functional interfaces provided by the base component are + in addition to the security interfaces (TSFIs), and are not + required to be considered during the base component + evaluation. These often include interfaces that are used by a + dependent component to invoke a service provided by the base + component. + + The base component may include some indirect interfaces + through which TSFIs may be called, e.g. APIs that can be used + to invoke a service of the TSF, which were not considered + during the evaluation of the base component. +
+ + The dependent component, which relies on the base component, + is similarly defined: interfaces to external entities defined + in the SFRs of the component ST are categorised as TSFI and + are examined in . + + Any call out from the dependent TSF to the environment in + support of an SFR will indicate that the dependent TSF + requires some service from the environment in order to satisfy + the enforcement of the stated dependent component SFRs. Such a + service is outside the dependent component boundary and the + base component is unlikely to be defined in the dependent ST + as an external entity. Hence, the calls for services made out + by the dependent TSF to its underlying platform (the base + component) will not be analysed as part of the activities. These dependencies on + the base component are expressed in the dependent component ST + as security objectives for the environment. + + This abstraction of the dependent component and the interfaces + is shown in Figure + below. +
+ + When considering the composition of the base component and the + dependent component, if the dependent component's TSF requires + services from the base component to support the implementation + of the SFR, the interface to the service will need to be + defined. If that service is provided by the base component's + TSF, then that interface should be a TSFI of the base + component and will therefore already be defined within the + functional specification of the base component. + + If, however, the service called by the dependent component's + TSF is not provided by the TSF of the base component (i.e., it + is implemented in the non-TSF portion of the base component or + possibly even in the non-TOE portion of the base component + (not illustrated in Figure ), there is unlikely to be a TSFI of the base + component relating to the service, unless the service is + mediated by the TSF of the base component. The interfaces to + these services from the dependent component to the operational + environment are considered in the family . + + The non-TSF portion of the base component is drawn into the + TSF of the composed TOE due to the dependencies the dependent + component has on the base component to support the SFRs of the + dependent component. Therefore, in such cases, the TSF of the + composed TOE would be larger than simply the sum of the + components' TSFs. +
+ + It may be the case that the base component TSFI is being + called in a manner that was unforeseen in the base component + evaluation. Hence there would be a requirement for further + testing of the base component TSFI. + + The possible interfaces are further described in the following + diagram (Figure ) and + supporting text. +
+ + + + Arrows going into 'dependent component-a' + (A and B) = where the component expects the environment to + respond to a service request (responding to calls out from + dependent component to the environment); + + Arrows coming out of 'base component-b' + (C and D) = interfaces of services provided by the base + component to the environment; + + Broken lines between components = types of communication + between pairs of interfaces; + + The other (grey) arrows = interfaces that are described by + the given criteria. + + The following is a simplification, but explains the + considerations that need to be made. + + There are components a ('dependent component-a') and b ('base + component-b'): the arrows coming out of TSF-a + are services provided by TSF-a and are therefore TSFIs(a); + likewise, the arrows coming out of TSF-b + (``C'') are TSFIs(b). These are each detailed in their + respective functional specs. component-a is such that it + requires services from its environment: those needed by the + TSF(a) are labelled ``A''; the other (not related to TSF-a) + services are labelled ``B''. + + When component-a and component-b are combined, there are four + possible combinations of {services needed by component-a} and + {services provided by component-b}, shown as broken lines + (types of communication between pairs of interfaces). Any set + of these might exist for a particular composition: + + + TSF-a needs those services that are provided by TSF-b ("A" is connected to "C"): + this is straightforward: the details about "C" are in the FSP for component-b. + In this instance the interfaces should all be defined in the functional specifications for + the component-b. + + + Non-TSF-a needs those services that are provided by TSF-b + (``B'' is connected to ``C''): this is straightforward + (again, the details about ``C'' are in the FSP for + component-b), but unimportant: security-wise. + + Non-TSF-a needs those services that are provided by + non-TSF-b (``B'' is connected to ``D''): we have no + details about D, but there are no security implications + about the use of these interfaces, so they do not need to + be considered in the evaluation, although they are likely + to be an integration issue for the developer. + + TSF-a needs those services that are provided by non-TSF-b + (``A'' is connected to ``D''): this would arise when + component-a and component-b have different senses of what + a ``security service'' is. Perhaps component-b is making + no claims about I&A (has no + SFRs in its ST), but component-a needs authentication + provided by its environment. There are no details about + the ``D'' interfaces available (they are not TSFI (b), so + they are not in component-b's FSP). + + Note: if the kind of interaction described in case d above + exists, then the TSF of the composed TOE would be TSF-a + TSF-b + + Non-TSF-b. Otherwise, the TSF of the composed TOE would be + TSF-a + TSF-b. + + Interfaces types 2 and 4 of Figure are not directly relevant to the evaluation of + the composed TOE. Interfaces 1 and 3 will be considered during + the application of different families: + + + (for component-b) will + describe the C interfaces. + + will describe the A + interfaces. + + will describe the C + interfaces for connection type 1 and the D interfaces for + connection type 3. + + A typical example where composition may be applied is a + database management system (DBMS) that relies upon its + underlying operating system (OS). During the evaluation of + the DBMS component, there will be an assessment made of the + security properties of that DBMS (to whatever degree of rigour + is dictated by the assurance components used in the + evaluation): its TSF boundary will be identified, its + functional specification will be assessed to determine whether + it describes the interfaces to the security services provided + by the TSF, perhaps additional information about the TSF (its + design, architecture, internal structure) will be provided, + the TSF will be tested, aspects of its life-cycle and its + guidance documentation will be assessed, etc. + + However, the DBMS evaluation will not call for any evidence + concerning the dependency the DBMS has on the OS. The ST of + the DBMS will most likely state assumptions about the OS in + its Assumptions subclause and state security objectives for the + OS in its Environment subclause. The DBMS ST may even + instantiate those objectives for the environment in terms of + SFRs for the OS. However, there will be no specification for + the OS that mirrors the detail in the functional + specification, architecture description, or other evidence as for the DBMS. will fulfil that need. + + describes the interfaces of + the dependent TOE that make the calls to the base component + for the provision of services. These are the interfaces to + which the base component is to respond. The interface + descriptions are provided from the dependent component's + viewpoint. + + describes the interfaces + provided by the base component, which respond to the dependent + component service requests. These interfaces are mapped to the + relevant dependent component interfaces that are identified in + the reliance information. (The completeness of this mapping, + whether the base component interfaces described represent all + dependent component interfaces, is not verified here, but in + ). At the higher levels of + the subsystems providing the + interfaces are described. + + Any interfaces required by the dependent component that have + not been described for the base component are reported in the + rationale for . The rationale + also reports whether the interfaces of the base component on + which the dependent component relies were considered within + the base component evaluation. For any interfaces that were + not considered in the base component evaluation, a rationale + is provided of the impact of using the interface on the base + component TSF. + + + + + This annex contains ancillary material to further explain and + provide additional examples for the topics brought up in + families of the class. + + + A security architecture is a set of properties that the TSF + exhibits; these properties include self-protection, domain + separation, and non-bypassability. Having these properties + provides a basis of confidence that the TSF is providing its + security services. This annex provides additional material on + these properties, as well as discussion on contents of a + security architecture description. + + The remainder of this subclause first explains these properties, + then discusses the kinds of information that are needed to + describe how the TSF exhibits those properties. + + Self-protection refers to the ability of + the TSF to protect itself from manipulation from external + entities that may result in changes to the TSF. Without these + properties, the TSF might be disabled from performing its + security services. + + It is oftentimes the case that a TOE uses services or + resources supplied by other IT entities in order to perform + its functions (e.g. an application that relies upon its + underlying operating system). In these cases, the TSF does + not protect itself entirely on its own, because it depends + on the other IT entities to protect the services it + uses. + Domain separation is a property whereby the TSF + creates separate security domains for each + untrusted active entity to operate on its resources, and then + keeps those domains separated from one another so that no entity + can run in the domain of any other. For example, an operating + system TOE supplies a domain (address space, per-process + environment variables) for each process associated with + untrusted entities. + + For some TOEs such domains do not exist because all of the + actions of the untrusted entities are brokered by the TSF. A + packet-filter firewall is an example of such a TOE, where + there are no untrusted entity domains; there are only data + structures maintained by the TSF. The existence of domains, + then, is dependant upon 1) the type of TOE and 2) the SFRs + levied on the TOE. In the cases where the TOE does provide + domains for untrusted entities, this family requires that + those domains are isolated from one another such that + untrusted entities in one domain are prevented from + tampering (affecting without brokering by the TSF) from + another untrusted entity's domain. + + Non-bypassability is a property that the + security functionality of the TSF (as specified by the SFRs) + is always invoked and cannot be circumvented when + appropriate for that specific mechanism. For example, if + access control to files is specified as a capability of the + TSF via an SFR, there must be no interfaces through which + files can be accessed without invoking the TSF's access + control mechanism (an interface through which a raw disk + access takes place might be an example of such an + interface). + + As is the case with self-protection, the very nature of some + TOEs might depend upon their environments to play a role in + non-bypassability of the TSF. For example, a security + application TOE requires that it be invoked by the + underlying operating system. Similarly, a firewall depends + upon the fact that there are no direct connections between + the internal and external networks and that all traffic + between them must go through the firewall. + + + The security architecture description explains how the + properties described above are exhibited by the TSF. It + describes how domains are defined and how the TSF keeps them + separate. It describes what prevents untrusted processes + from getting to the TSF and modifying it. It describes what + ensures that all resources under the TSF's control are + adequately protected and that all actions related to the + SFRs are mediated by the TSF. It explains any role the + environment plays in any of these (e.g. presuming it gets + correctly invoked by its underlying environment, how are its + security functions invoked?). + + The security architecture description presents the TSF's + properties of self-protection, domain separation, and + non-bypassability in terms of the decomposition descriptions. + The level of this description is commensurate with the TSF + description required by the , + and requirements that are being claimed. For example, if + is the only TSF description + available, it would be difficult to provide any meaningful + security architecture description because none of the details of + any internal workings of the TSF would be available. + + However, if the TOE design were also available, even at the most + basic level (), there would be + some information available concerning the subsystems that make + up the TSF, and there would be a description of how they work to + implement self-protection, domain separation, and + non-bypassability. For example, perhaps all user interaction + with the TOE is constrained through a process that acts on that + user's behalf, adopting all of the user's security attributes; + the security architecture description would describe how such a + process comes into being, how the process's behaviour is + constrained by the TSF (so it cannot corrupt the TSF), how all + actions of that process are mediated by the TSF (thereby + explaining why the TSF cannot be bypassed), etc. + + If the available TOE design is more detailed (e.g. at the + modular level), or the implementation representation is also + available, then the security architecture description would be + correspondingly more detailed, explaining how the user's process + communicate with the TSF processes, how different requests are + processed by the TSF, what parameters are passed, what + programmatic protections (buffer overflow prevention, parameter + bounds checking, time of check/time of use checking, etc.) are + in place. Similarly, a TOE whose ST claimed the component would go into + implementation-specific detail. + + The explanations provided in the security architecture + description are expected to be of sufficient detail that one + would be able to test their accuracy. That is, simple + assertions (e.g. "The TSF keeps domains separate'') provide + no useful information to convince the reader that the TSF + does indeed create and separate domains. + + In cases where the TOE exhibits domain separation entirely on + its own, there would be a straightforward description of how + this is attained. The security architecture description would + explain the different kinds of domains that are defined by the + TSF, how they are defined (i.e. what resources are allocated + to each domain), how no resources are left unprotected, and + how the domains are kept separated so that active entities in + one domain cannot tamper with resources in another + domain. + For cases where the TOE depends upon other IT entities to play + a role in domain separation, that sharing of roles must be made + clear. For example, a TOE that is solely application software + relies upon the underlying operating system to correctly + instantiate the domains that the TOE defines; if the TOE + defines separate processing space, memory space, etc, for each + domain, it depends upon the underlying operating system to + operate correctly and benignly (e.g. allow the process to + execute only in the execution space that is requested by the + TOE software). + For example, mechanisms that implement domain separation + (e.g., memory management, protected processing modes provided + by the hardware, etc.) would be identified and described. Or, + the TSF might implement software protection constructs or + coding conventions that contribute to implementing separation + of software domains, perhaps by delineating user address space + from system address space. + The vulnerability analysis and testing (see ) activities will likely include attempts to defeat + the described TSF domain separation through the use of + monitoring or direct attack the TSF. + + + In cases where the TOE exhibits self-protection entirely + on its own, there would be a straightforward description + of how this self-protection is attained. Mechanisms that + provide domain separation to define a TSF domain that is + protected from other (user) domains would be identified + and described. + + For cases where the TOE depends upon other IT entities to + play a role in protecting itself, that sharing of roles + must be made clear. For example, a TOE that is solely + application software relies upon the underlying operating + system to operate correctly and benignly; the application + cannot protect itself against a malicious operating system + that subverts it (for example, by overwriting its + executable code or TSF data). + + The security architecture description also covers how user input + is handled by the TSF in such a way that the TSF does not + subject itself to being corrupted by that user input. For + example, the TSF might implement the notion of privilege and + protect itself by using privileged-mode routines to handle user + data. The TSF might make use of processor-based separation + mechanisms (e.g. privilege levels or rings) to separate TSF + code and data from user code and data. The TSF might implement + software protection constructs or coding conventions that + contribute to implementing separation of software, perhaps by + delineating user address space from system address space. + + For TOEs that start up in a low-function mode (for + example, a single-user mode accessible only to installers + or administrators) and then transition to the evaluated + secure configuration (a mode whereby untrusted users are + able to login and use the services and resources of the + TOE), the security architecture description also includes + an explanation of how the TSF is protected against this + initialisation code that does not run in the evaluated + configuration. For such TOEs, the security architecture + description would explain what prevents those services + that should be available only during initialisation + (e.g. direct access to resources) from being accessible in + the evaluated configuration. It would also explain what + prevents initialisation code from running while the TOE is + in the evaluated configuration. + + There must also be an explanation of how the trusted + initialisation code will maintain the integrity of the TSF + (and of its initialisation process) such that the + initialisation process is able to detect any modification + that would result in the TSF being spoofed into believe it + was in an initial secure state. + + The vulnerability analysis and testing (see ) activities will likely include + attempts to defeat the described TSF self protection + through the use of tampering, direct attack, or monitoring + of the TSF. + + + The property of non-bypassability is concerned with + interfaces that permit the bypass of the enforcement + mechanisms. In most cases this is a consequence of the + implementation, where if a programmer is writing an + interface that accesses or manipulates an object, it is + that programmer's responsibility to use interfaces that + are part of the SFR enforcement mechanism for the object + and not to try to circumvent those interfaces. For the + description pertaining to non-bypassability, then, there + are two broad areas that have to be covered. + + The first consists of those interfaces to the SFR-enforcement. + The property for these interfaces is that they contain no + operations or modes that allow them to be used to bypass the + TSF. It is likely that the evidence for and can be used in + large part to make this determination. Because non-bypassability + is the concern, if only certain operations available through + these TSFIs are documented (because they are SFR-enforcing) and + others are not, the developer should consider whether additional + information (to that presented in + and ) is necessary to make a + determination that the + SFR-supporting and SFR-non-interfering + operations of the TSFI do not afford an + untrusted entity the ability to bypass the policy being + enforced. If such information is necessary, it is included + in the security architecture description. + + The second area of non-bypassability is concerned with + those interfaces whose interactions are not associated + with SFR-enforcement. Depending on the and components + claimed, some information about these interfaces may or + may not exist in the functional specification and TOE + design documentation. The information presented for such + interfaces (or groups of interfaces) should be sufficient + so that a reader can make a determination (at the level of + detail commensurate with the rest of the evidence supplied + in the class) that the + enforcement mechanisms cannot be bypassed. + + The property that the security functionality cannot be + bypassed applies to all security functionality + equally. That is, the design description should cover + objects that are protected under the SFRs (e.g. _* components) and functionality + (e.g., audit) that is provided by the TSF. The description + should also identify the interfaces that are associated + with security functionality; this might make use of the + information in the functional specification. This + description should also describe any design constructs, + such as object managers, and their method of use. For + instance, if routines are to use a standard macro to + produce an audit record, this convention is a part of the + design that contributes to the non-bypassability of the + audit mechanism. It is important to note that + non-bypassability in this context is not an + attempt to answer the question ``could a part of the TSF + implementation, if malicious, bypass the security + functionality'', but rather to document how the + implementation does not bypass the security + functionality. + + The vulnerability analysis and testing (see ) activities will likely include + attempts to defeat the described non-bypassability by + circumventing the TSF. + + + + + The purpose in specifying the TSFIs is to provide the + necessary information to conduct testing; without knowing the + possible means interact with the TSF, one cannot adequately + test the behaviour of the TSF. + + There are two parts to specifying the TSFIs: identifying them + and describing them. Because of the diversity of possible + TOEs, and of different TSFs therein, there is no standard set + of interfaces that constitute ``TSFIs''. This annex provides + guidance on the factors that determine which interfaces are + TSFIs. + + + In order to identify the interfaces to the TSF, the parts of the + TOE that make up the TSF must first be identified. This + identification is actually a part of the analysis, but is also performed implicitly + (through identification and description of the TSFI) by the + developer in cases where is not + included in the assurance package. In this analysis, a portion + of the TOE must be considered to be in the TSF if it contributes + to the satisfaction of an SFR in the ST (in whole or in + part). This includes, for example, everything in the TOE that + contributes to TSF run-time initialisation, such as software + that runs prior to the TSF being able to protect itself because + enforcement of the SFRs has not yet begun (e.g., while booting + up). Also included in the TSF are all parts of the TOE that + contribute to the architectural principles of TSF + self-protection, domain separation, and non-bypassability (see + ). + + Once the TSF has been defined, the TSFI are identified. + The TSFI consists of all means by which external entities (or + subjects in the TOE but outside of the TSF) supply data to the TSF, + receive data from the TSF and invoke services from the TSF. + These service invocations and responses are the means of crossing + the TSF boundary. While many of these are readily apparent, others + might not be as obvious. The question that should be asked when + determining the TSFIs is: ``How can a potential attacker interact + with the TSF in an attempt to subvert the SFRs?'' The following + discussions illustrate the application of the TSFI definition in + different contexts. + + + In TOEs such as smart cards, where the adversary has not + only logical access to the TOE, but also complete physical + access to the TOE, the TSF boundary is the physical + boundary. Therefore, the exposed electrical interfaces + are considered TSFI because their manipulation could + affect the behaviour of the TSF. As such, all these + interfaces (electrical contacts) need to be described: + various voltages that might be applied, etc. + + + + The TSFIs of a TOE that performs protocol processing would + be those protocol layers to which a potential attacker has + direct access. This need not be the entire protocol stack, + but it might be. + + For example, if the TOE were some sort of a network + appliance that allowed potential attackers to affect every + level of the protocol stack (i.e. to send arbitrary + signals, arbitrary voltages, arbitrary packets, arbitrary + datagrams, etc.), then the TSF boundary exists at each + layer of the stack. Therefore, the functional + specification would have to address every protocol at + every layer of the stack. + + If, however, the TOE were a firewall that protects an + internal network from the Internet, a potential attacker + would have no means of directly manipulating the voltages + that enter the TOE; any extreme voltages would simply not + be passed though the Internet. That is, the attacker would + have access only to those protocols at the Internet layer + or above. The TSF boundary exists at each layer of the + stack. Therefore, the functional specification would have + to address only those protocols at or above the Internet + layer: it would describe each of the different + communication layers at which the firewall is exposed in + terms of what constitutes well-formed input for what might + appear on the line, and the result of both well-formed and + malformed inputs. For example, the description of the + Internet protocol layer would describe what constitutes a + well-formed IP packet and what happens when both + correctly-formed and malformed packets are + received. Likewise, the description of the TCP layer would + describe a successful TCP connection and what happens both + when successful connections are established and when + connections cannot be established or are inadvertently + dropped. Presuming the firewall's purpose is to filter + application-level commands (like FTP or telnet), the + description of the application layer would describe the + application-level commands that are recognised and + filtered by the firewall, as well as the results of + encountering unknown commands. + + The descriptions of these layers would likely reference + published communication standards (telnet, FTP, TCP, etc.) + that are used, noting which user-defined options are + chosen. + + + +
+ + + ``Wrappers'' translate complex series of interactions into + simplified common services, such as when Operating Systems + create APIs for use by applications (as shown in Figure + ). Whether the TSFIs + would be the system calls or the APIs depends upon what is + available to the application: if the application can use + the system calls directly, then the system calls are the + TSFIs. If, however, there were something that prohibits + their direct use and requires all communication through + the APIs, then the APIs would be the TSFIs. + + A Graphical User interface is similar: it translates + between machine-understandable commands and user-friendly + graphics. Similarly, the TSFIs would be the commands if + users have access to them, or the graphics (pull-down + menus, check-boxes, text fields) if the users are + constrained to using them. + + It is worth noting that, in both of these examples, if the + user is prohibited from using the more primitive + interfaces (i.e. the system calls or the commands), the + description of this restriction and of its enforcement + would be included in the Security Architecture Description + (see ). Also, the wrapper would be + part of the TSF. + + + + For a given TOE, not all of the interfaces may be + accessible. That is, the security + objectives for the operational environment (in the + Security Target) may prevent access to these interfaces or + limit access in such a way that they are practically + inaccessible. Such interfaces would not be considered + TSFIs. Some examples: + + If the security objectives for the operational + environment for the stand-alone firewall state that + ``the firewall will be operational in a server room + environment to which only trusted and trained + personnel will have access, and which will be equipped + with an interruptible power supply (against power + failure)'', physical and power interfaces will not be + accessible, since trusted and trained personnel will + not attempt to dismantle the firewall and/or disable + its power supply. If the security + objectives for the operational environment for the + software firewall (application) state that ``the OS + and the hardware will provide a security domain for + the application free from tampering by other + programs'', the interfaces through which the firewall + can be accessed by other applications on the OS + (e.g. deleting or modifying the firewall executable, + direct reading or writing to the memory space of the + firewall) will not be accessible, since the + OS/hardware part of the operational environment makes + this interface inaccessible. If the + security objectives for the operational environment + for the software firewall additionally state that the + OS and hardware will faithfully execute the commands + of the TOE, and will not tamper with the TOE in any + manner, interfaces through which the firewall obtains + primitive functionality from the OS and hardware + (executing machine code instructions, OS APIs, such as + creating, reading, writing or deleting files, + graphical APIs etc.) will not be accessible, since the + OS/hardware are the only entities that can access that + interface, and they are completely + trusted. For all of these examples, + these inaccessible interfaces would not be + TSFIs. + + + + Figure + illustrates a complex TOE: a database management system that + relies on hardware and software that is outside the TOE + boundary (referred to as the IT environment + in the rest of this discussion). To simplify this example, + the TOE is identical to the TSF. The + shaded boxes represent the TSF, while the unshaded boxes + represent IT entities in the environment. The TSF comprises + the database engine and management GUIs (represented by the + box labelled DB) and a kernel module that + runs as part of the OS that performs some security function + (represented by the box labelled PLG). The + TSF kernel module has entry points defined by the OS + specification that the OS will call to invoke some function + (this could be a device driver, or an authentication module, + etc.). The key is that this pluggable kernel module is + providing security services specified by functional + requirements in the ST. + +
+ + + The IT environment consists of the operating system itself + (represented by the box labelled OS), as + well as an external server (labelled SRV). + This external server, like the OS, provides a service that + the TSF depends on, and thus needs to be in the IT + environment. Interfaces in the figure are labelled + Ax for TSFI, and Bx for + other interfaces that would be documented in . Each of these groups of interfaces is now + discussed. + + Interface group A1 represents the most obvious set of TSFI. + These are interfaces used by users to directly access the + database and its security functionality and + resources. + + Interface group A2 represent the TSFI that the OS invokes to + obtain the functionality provided by the pluggable module. + These are contrasted with interface group B3, which + represent calls that the pluggable module makes to obtain + services from the IT environment. + + Interface group A3 represent TSFI that pass through the IT + environment. In this case, the DBMS communicates over the + network using a proprietary application-level + protocol. While the IT environment is responsible for + providing various supporting protocols (e.g., Ethernet, IP, + TCP), the application layer protocol that is used to obtain + services from the DBMS is a TSFI and must be documented as + such. The dotted line indicates return values/services from + the TSF over the network connection. + + The interfaces labelled Bx represent + interfaces to functionality in the IT Environment. These + interfaces are not TSFI and need only be discussed and + analysed when the TOE is being used in a composite + evaluation as part of the activities associated with the + class. + + + + The Example firewall is used between an internal network and + an external network. It verifies the source address of data + received (to ensure that external data is not attempting to + masquerade as originating from the internal data); if it + detects any such attempts, it saves the offending attempt to + the audit log. The administrator connects to the firewall by + establishing a telnet connection to the firewall from the + internal network. Administrator actions consist of + authenticating, changing passwords, reviewing the audit log, + and setting or changing the addresses of the internal and + external networks. + + The Example firewall presents the following interfaces to + the internal network: + + IP datagrams + Administrator Commands and the + following interfaces to the external network: + + IP datagrams + Interfaces Descriptions: IP + Datagrams + The datagrams are in the format specified by RFC 791. + + Purpose - to transmit blocks of data (``datagrams'') + from source hosts to destination hosts identified by + fixed length addresses; also provides for fragmentation + and reassembly of long datagrams, if necessary, for + transmission through small-packet networks. + Method of Use - they arrive from the lower-level + (e.g. data link) protocol. + Parameters - the following fields of the IP datagram + header: source address, destination address, + don't-fragment flag. + Parameter description - [As defined by RFC 791, + subclause 3.1 (``Internet Header Format'')] + Actions - Transmits datagrams that are not + masquerading; fragments large datagrams if necessary; + reassembles fragments into datagrams. + Error messages - (none). No reliability guaranteed + (reliability to be provided by upper-level protocols) + Undeliverable datagrams (e.g. must be fragmented for + transmission, but don't-fragment flag is set) + dropped. + Interfaces Descriptions: Administrator + Commands + The administrator commands provide a means for the + administrator to interact with the firewall. These commands + and responses ride atop a telnet (RFC 854) connection + established from any host on the internal network. Available + commands are: + + Passwd + + Purpose - sets administrator password + Method of Use - Passwd + <password> + Parameters - password + Parameter description - value of new + password + Actions - changes password to new value + supplied. There are no restrictions. + Error messages - none. + + Readaudit + + Purpose - presents the audit log to the + administrator + Method of Use - Readaudit + Parameters - none + Parameter description - none + Actions - provides the text of the audit + log + Error messages - none. + + Setintaddr + + Purpose - sets the address of the internal + address. + Method of Use - Setintaddr + <address> + Parameters - address + Parameter description - first three fields of an + IP address (as defined in RFC 791). For example: + 123.123.123. + Actions - changes the internal value of the + variable defining the internal network, the value of + which is used to judge attempted masquerades. + Error messages - ``address in use'': indicates + the identified internal network is the same as the + external network. + + Setextaddr + + Purpose - sets the address of the external address + Method of Use - Setextaddr + <address> + Parameters - address + Parameter description - first three fields of an + IP address (as defined in RFC 791). For example: + 123.123.123. + Actions - changes the internal value of the + variable defining the external network. + Error messages - ``address in use'': indicates + the identified external network is the same as the + internal network. + + + + + + + The wide variety of TOEs makes it impossible to codify + anything more specific than ``well-structured'' or ``minimum + complexity''. Judgements on structure and complexity are + expected to be derived from the specific technologies used in + the TOE. For example, software is likely to be considered + well-structured if it exhibits the characteristics cited in + the software engineering disciplines. + + This annex provides supplementary material on assessing the + structure and complexity of procedure-based software portions + of the TSF. This material is based on information readily + available in software engineering literature. For other kinds + of internals (e.g. hardware, non-procedural software such as + object-oriented code, etc.), corresponding literature on good + practises should be consulted. + + + The structure of procedural software is traditionally + assessed according to its + modularity. Software written with a modular + design aids in achieving understandability by clarifying + what dependencies a module has on other modules + (coupling) and by including in a module + only tasks that are strongly related to each other + (cohesion). The use of modular design + reduces the interdependence between elements of the TSF and + thus reduces the risk that a change or error in one module + will have effects throughout the TOE. Its use enhances + clarity of design and provides for increased assurance that + unexpected effects do not occur. Additional desirable + properties of modular decomposition are a reduction in the + amount of redundant or unneeded code. + + Minimising the amount of functionality in the TSF allows the + evaluator as well as the developer to focus only on that + functionality which is necessary for SFR enforcement, + contributing further to understandability and further + lowering the likelihood of design or implementation + errors. + + The incorporation of modular decomposition, layering and + minimisation into the design and implementation process must + be accompanied by sound software engineering + considerations. A practical, useful software system will + usually entail some undesirable coupling among modules, some + modules that include loosely-related functions, and some + subtlety or complexity in a module's design. These + deviations from the ideals of modular decomposition are + often deemed necessary to achieve some goal or constraint, + be it related to performance, compatibility, future planned + functionality, or some other factors, and may be acceptable, + based on the developer's justification for them. In applying + the requirements of this class, due consideration must be + given to sound software engineering principles; however, the + overall objective of achieving understandability must be + achieved. + + + Cohesion is the manner and degree to which the tasks + performed by a single software module are related to one + another; types of cohesion include coincidental, + communicational, functional, logical, sequential, and + temporal. These types of cohesion are characterised below, + listed in the order of decreasing desirability. + + functional cohesion - a module + with functional cohesion performs activities related + to a single purpose. A functionally cohesive module + transforms a single type of input into a single type + of output, such as a stack manager or a queue + manager. + sequential cohesion - a module + with sequential cohesion contains functions each of + whose output is input for the following function in + the module. An example of a sequentially cohesive + module is one that contains the functions to write + audit records and to maintain a running count of the + accumulated number of audit violations of a specified + type. + communicational cohesion - a + module with communicational cohesion contains + functions that produce output for, or use output from, + other functions within the module. An example of a + communicationally cohesive module is an access check + module that includes mandatory, discretionary, and + capability checks. + temporal cohesion - a module + with temporal cohesion contains functions that need to + be executed at about the same time. Examples of + temporally cohesive modules include initialisation, + recovery, and shutdown modules. + logical (or + procedural) cohesion - a module with + logical cohesion performs similar activities on + different data structures. A module exhibits logical + cohesion if its functions perform related, but + different, operations on different inputs. + coincidental cohesion - a + module with coincidental cohesion performs unrelated, + or loosely related, activities. + + + + Coupling is the manner and degree of interdependence + between software modules; types of coupling include call, + common and content coupling. These types of coupling are + characterised below, listed in the order of decreasing + desirability: + + call: two modules are call coupled if they + communicate strictly through the use of their + documented function calls; examples of call coupling + are data, stamp, and control, which are defined below. + + data: two modules are data + coupled if they communicate strictly through the + use of call parameters that represent single data + items. + stamp: two modules are stamp + coupled if they communicate through the use of + call parameters that comprise multiple fields or + that have meaningful internal structures. + control: two modules are + control coupled if one passes information that is + intended to influence the internal logic of the + other. + + common: two modules are common + coupled if they share a common data area or a common + system resource. Global variables indicate that + modules using those global variables are common + coupled. Common coupling through global variables is + generally allowed, but only to a limited degree. For + example, variables that are placed into a global area, + but are used by only a single module, are + inappropriately placed, and should be removed. Other + factors that need to be considered in assessing the + suitability of global variables are: + + The number of modules that modify a global + variable: In general, only a single module should + be allocated the responsibility for controlling + the contents of a global variable, but there may + be situations in which a second module may share + that responsibility; in such a case, sufficient + justification must be provided. It is unacceptable + for this responsibility to be shared by more than + two modules. (In making this assessment, care + should be given to determining the module actually + responsible for the contents of the variable; for + example, if a single routine is used to modify the + variable, but that routine simply performs the + modification requested by its caller, it is the + calling module that is responsible, and there may + be more than one such module). Further, as part + of the complexity determination, if two modules + are responsible for the contents of a global + variable, there should be clear indications of how + the modifications are coordinated between + them. + The number of modules that reference a global + variable: Although there is generally no limit on + the number of modules that reference a global + variable, cases in which many modules make such a + reference should be examined for validity and + necessity. + + content: two modules are content + coupled if one can make direct reference to the + internals of the other (e.g. modifying code of, or + referencing labels internal to, the other module). + The result is that some or all of the content of one + module are effectively included in the other. Content + coupling can be thought of as using unadvertised + module interfaces; this is in contrast to call + coupling, which uses only advertised module + interfaces. + + + + + Complexity is the measure of the decision points and logical + paths of execution that code takes. Software engineering + literature cites complexity as a negative characteristic of + software because it impedes understanding of the logic and + flow of the code. Another impediment to the understanding of + code is the presence of code that is unnecessary, in that it + is unused or redundant. + + The use of layering to separate levels of abstraction and + minimise circular dependencies further enables a better + understanding of the TSF, providing more assurance that the + TOE security functional requirements are accurately and + completely instantiated in the implementation. + + Reducing complexity also includes reducing or eliminating + mutual dependencies, which pertains both to modules in a + single layer and to those in separate layers. Modules that + are mutually dependent may rely on one another to formulate + a single result, which could result in a deadlock condition, + or worse yet, a race condition (e.g., time of check vs. time + of use concern), where the ultimate conclusion could be + indeterminate and subject to the computing environment at + the given instant in time. + + Design complexity minimisation is a key characteristic of a + reference validation mechanism, the purpose of which is to + arrive at a TSF that is easily understood so that it can be + completely analysed. (There are other important + characteristics of a reference validation mechanism, such as + TSF self-protection and non-bypassability; these other + characteristics are covered by requirements in the family.) + + + + + This Subclause provides additional guidance on the TDS family, + and its use of the terms ``subsystem'' and ``module''. This is + followed by a discussion of how, as more-detailed becomes + available, the requirement for the less-detailed is + reduced. + + Figure + shows that, depending on the complexity of the TSF, the + design may be described in terms of subsystems + and modules (where subsystems are at a + higher level of abstraction than modules); or it may just be + described in terms of one level of abstraction (e.g., + subsystems at lower assurance levels, + modules at higher levels). In cases where a + lower level of abstraction (modules) is presented, + requirements levied on higher-level abstractions + (subsystems) are essentially met by default. This concept is + further elaborated in the discussion on subsystems and + modules below. +
+ + The developer is expected to describe the design of the TOE + in terms of subsystems. The term + ``subsystem'' was chosen to be specifically vague so that it + could refer to units appropriate to the TOE (e.g., + subsystems, modules). subsystems can even be uneven in + scope, as long as the requirements for description of + subsystems are met. + + The first use of subsystems is to distinguish the TSF boundary; + that is, the portions of the TOE that comprise the TSF. In + general, a subsystem is part of the TSF if it has the capability + (whether by design or implementation) to affect the correct + operation of any of the SFRs. For example, for software that + depends on different hardware execution modes to provide domain + separation (see ) where + SFR-enforcing code is executed in one domain, then all + subsystems that execute in that domain would be considered part + of the TSF. Likewise, if a server outside that domain + implemented an SFR (e.g. enforced an access control policy over + objects it managed), then it too would be considered part of the + TSF. + + The second use of subsystems is to provide a structure for + describing the TSF at a level of description that, while + describing how the TSF works, does not necessarily contain + low-level implementation detail found in module descriptions + (discussed later). subsystems are described at either a high + level (lacking an abundance of implementation detail) or a + detailed level (providing more insight into the + implementation). The level of description provided for a + subsystem is determined by the degree to which that + subsystem is responsible for implementing an SFR. + + An SFR-enforcing subsystem is a subsystem + that provides mechanisms for enforcing an element of any SFR, + or directly supports a subsystem that is responsible + for enforcing an SFR. If a subsystem provides (implements) + an SFR-enforcing TSFI, then the subsystem is + SFR-enforcing. + + Subsystems can also be identified as + SFR-supporting and + SFR-non-interfering. An SFR-supporting + subsystem is one that is depended on by an SFR-enforcing + subsystem in order to implement an SFR, but does not play as + direct a role as an SFR-enforcing subsystem. An + SFR-non-interfering subsystem is one that is not depended + upon, in either a supporting or enforcing role, to implement + an SFR. + + + + A module is generally a relatively small architectural unit + that can be characterised in terms of the properties + discussed in . When both + (or above) requirements + and requirements are + present in a PP or ST, a ``module'' in terms of the requirements refers to the same + entity as a ``module'' for the requirements. Unlike subsystems, modules + describe the implementation in a level of detail that can + serve as a guide to reviewing the implementation + representation. + + It is important to note that, depending on the TOE, modules + and subsystems may refer to the same abstraction. For and (which do not require description at the + module level) the subsystem description provides the lowest + level detail available about the TSF. For (which require module + descriptions) these descriptions provide the lowest level of + detail, while the subsystem descriptions (if they exist as + separate entities) merely serve to put to the module + descriptions in context. That is, it is not necessary to + provide detailed subsystem descriptions if module + descriptions exist. In TOEs that are sufficiently simple, a + separate ``subsystem description'' is not necessary; the + requirements can be met through documentation provided by + modules. For complex TOEs, the purpose of the subsystem + description (with respect to the TSF) is to provide the + reader context so they can focus their analysis + appropriately. This difference is illustrated in Figure + . + + An SFR-enforcing module is a module that completely or partially implements + a security functional requirement (SFR) in the ST. Such modules may + implement an SFR-enforcing TSFI, but some functionality expressed in an SFR (for example, + audit and object re-use functionality) may not be directly tied to a single TSFI. As was + the case with subsystems, SFR-supporting modules are those modules that are depended upon by + an SFR-enforcing module, but are not responsible for directly implementing an SFR. + SFR-non-interfering modules are those modules that do not deal, directly or indirectly, + with the enforcement of SFRs. + + It is important to note that the determination of what + ``directly implements'' means is somewhat subjective. In the + narrowest sense of the term, it could be interpreted to mean + the one or two lines of code that actually perform a + comparison, zeroing operation, etc. that implements a + requirement. A broader interpretation might be that it + includes the module that is invoked in response to a + SFR-enforcing TSFI, and all modules that may be invoked in + turn by that module (and so on until the completion of the + call). Neither of these interpretations is particularly + satisfying, since the narrowness of the first interpretation + may lead to important modules being incorrectly categorised + as SFR supporting, while the second leads to modules that + are actually not SFR-enforcing being classified as + such. + + A description of a module should be such that one could create an implementation of the + module from the description, and the resulting implementation would be 1) identical to + the actual TSF implementation in terms of the interfaces presented, 2) identical in the + use of interfaces that are mentioned in the design, and 3) functionally equivalent to the + description of the purpose of the TSF module. For instance, RFC 793 + provides a high-level description of the TCP protocol. It is necessarily implementation + independent. While it provides a wealth of detail, it is + not + a suitable design description because it is not specific to an implementation. An actual + implementation can add to the protocol specified in the RFC, and implementation choices + (for example, the use of global data vs. local data in various parts of the implementation) + may have an impact on the analysis that is performed. The design description of the TCP + module would list the interfaces presented by the implementation (rather than just those + defined in RFC 793), as well as an algorithm description of the processing associated with + the modules implementing TCP (assuming they were part of the TSF). + + In the design, modules are described in detail in terms + of the function they provide (the purpose); the interfaces + they present (when required by the criteria); the return + values from such interfaces; the interfaces (presented by other modules) + they use (provided those interfaces are required to be also described); + and a description of how they provide their functionality using a + technique appropriate to the method used to implement the module. + + The purpose of a module should be described indicating what + function the module is providing. It should be sufficient so + that the reader could get a general idea of what the + module's function is in the architecture. + + The interfaces presented by a module are those interfaces used by + other modules to invoke the functionality provided. Interfaces include both + explicit interfaces (e.g., a calling sequence invoked by + other modules) as well as implicit interfaces (e.g., global + data manipulated by the module). Interfaces are described in terms of how + they are invoked, and any values that are returned. This description would + include a list of parameters, and descriptions of these parameters. If a parameter + were expected to take on a set of values (e.g., a ``flag'' parameter), the complete set + of values the parameter could take on that would have an effect on module processing + would be specified. Likewise, parameters representing data structures are described + such that each field of the data structure is identified and described. + Global data should be described to the extent required to understand their purpose. + The level of description required for a global data structure needs to be identical + to the one for module interfaces, where the input parameter and return values correspond + to the individual fields and their possible values in the data structure. Global data + structures may be described separate from the modules that manipulate or read them as + long as the design of the modules contain sufficient information about the global data + structures updated or the information extracted from global data structures. + + Note that different programming languages may have + additional ``interfaces'' that would be non-obvious; an + example would be operator/function overloading in C++. This + ``implicit interface'' in the class description would also + be described as part of the module design. Note that + although a module could present only one interface, it is + more common that a module presents a small set of related + interfaces. + + When it is required to describe the interfaces used by a module, it must be + clear from either the design description of the module or the purpose of the + module called, what service is expected from the module called. For example if + Module A is being described, and it uses Module B's bubble sort routine, the + description of the interaction between modules must allow to identify why + Module B's bubble sort routine is called and what this call contributes to the + implementation of the SFRs. The interface and purpose of Module B's bubble sort + routine must be described as part of the interfaces of Module B (provided the + level of ADV_TDS and the classification of Module B require a description its + interfaces) and so Module A just needs to identify what data it needs to have + sorted using this routine. An adequate description would be: "Module A invokes + Module B's interface double_bubble() to sort the usernames in + alphabetical order". + Note that if this sorting of the user names is not important for the enforcement of + any SFR (e. g. it is just done to speed up things and an algorithmically identical + implementation of Module A could also avoid to have the usernames sorted), the use of + Module B's bubble sort routine is not SFR-enforcing and it is suffcient to explain in + the description of Module A that the usernames are sorted in alphabetical order to + enhance performance. Module B may be classified as "SFR-supporting" only and the level + of ADV_TDS chosen indicates if the interfaces of SFR-supporting modules need to be + described or if its is sufficient to just describe the purpose of Module B. + + As discussed previously, the algorithmic description of the + module should describe in an algorithmic fashion the + implementation of the module. This can be done in + pseudo-code, through flow charts, or (at ) informal text. It discusses + how the module inputs and called functions are used to + accomplish the module's function. It notes changes to global + data, system state, and return values produced by the + module. It is at the level of detail that an implementation + could be derived that would be very similar to the actual + implementation of the TOE. + + It should be noted that source code does not meet the module + documentation requirements. Although the module design + describes the implementation, it is not the + implementation. The comments surrounding the source code + might be sufficient documentation if they provide an + explanation of the intent of the source code. In-line + comments that merely state what each line of code is doing + are useless because they provide no explanation of what the + module is meant to accomplish. + + In the elements below, the labels (SFR-enforcing, + SFR-supporting, and SFR-non-interfering) discussed for + subsystems and modules are used to describe the amount and + type of information that needs to be made available by the + developer. The elements have been structured so that there + is no expectation that the developer provide + only the information specified. That is, if + the developer's documentation of the TSF provides the + information in the requirements below, there is no + expectation that the developer update their documentation + and label subsystems and modules as SFR-enforcing, + SFR-supporting, and SFR-non-interfering. The primary purpose + of this labelling is to allow developers with less mature + development methodologies (and associated artifacts, such as + detailed interface and design documentation) to provide the + necessary evidence without undue cost. + + + + Because there is subjectivity in determining what is + SFR-enforcing vs. SFR-supporting (and in some cases, even + determining what is SFR-non-interfering) the following + paradigm has been adopted in this family. In early + components of the family, the developer makes a + determination about the classification of the subsystems + into SFR-enforcing, etc., supplying the appropriate + information, and there is little additional evidence for the + evaluator to examine to support this claim. As the level of + desired assurance increases, while the developer still makes + a classification determination, the evaluator obtains more + and more evidence that is used to confirm the developer's + classification. + + In order to focus the evaluator's analysis on the SFR-related + portions of the TOE, especially at lower levels of assurance, + the components of the family are levelled such that initially + detailed information is required only for SFR-enforcing + architectural entities. As the level of assurance increases, + more information is required for SFR-supporting and (eventually) + SFR-non-interfering entities. It should be noted that even when + complete information is required, it is not required that all of + this information be analysed in the same level of detail. The + focus should be in all cases on whether the + necessary information has been provided and + analysed. + + Table summarises the + information required at each of the family components for the + architectural entities to be described. + + + + + + TSF subsystem + TSF Module + + + SFR + Enforce + SFR + Support + SFR + NI + SFR + Enforce + SFR + Support + SFR + NI + + + + + + (informal + presentation) + + structure, summary of SFR-Enf. behaviour, interactions + + designation support + designation support means that + only documentation sufficient to support the + classification of the subsystem / module is + needed. + + designation support + + + + + + + (informal + presentation) + + structure, detailed description of SFR-Enf. behaviour, + summary of other behaviour, interactions + + + structure, summary of other behaviour, interactions + + designation support, interactions + + + + + + + + (informal + presentation) description, + interactions description, interactions + description, interactions + + purpose, SFR interfacesSFR interfaces means that the module description contains, + for each SFR-related interface, the returned values and the called interfaces + to other modules. + interaction, purpose + interaction, purpose + + + + (semiformal + presentation) + description, interactions + description, interactions + description, interactions + + purpose, SFR interfaces + + + purpose, SFR interfaces + + interaction, purpose + + + + + (semiformal + presentation) + description, interactions + description, interactions + description, interactions + + purpose, all interfacesAll interfaces means that the module description contains, + for each interface, the returned values and the called interfaces to other + modules. + + purpose, all interfaces + + + purpose, all interfaces + + + + + (semiformal + presentation; additional formal + presentation) + description, interactions + description, interactions + description, interactions + + purpose, all interfaces + + + purpose, all interfaces + + + purpose, all interfaces + + + + + Description Detail Levelling +
+ + + + + Formal methods provide a mathematical representation of the + TSF and its behaviour and are required by the , , and + components. There are two aspects of formal methods: the + specification language that is used for + formal expression, and the theorem prover + that mathematically proves the completeness and correctness of + the formal specification. + + A formal specification is expressed within a formal system + based upon well-established mathematical concepts. These + mathematical concepts are used to define well-defined + semantics, syntax and rules of inference. A formal system is + an abstract system of identities and relations that can be + described by specifying a formal alphabet, a formal language + over that alphabet which is based on a formal syntax, and a + set of formal rules of inference for constructing derivations + of sentences in the formal language. + + The evaluator should examine the identified formal systems to + make sure that: + + The semantics, syntax and inference rules of the + formal system are defined or a definition is + referenced. + Each formal system is accompanied by explanatory text + that provides defined semantics so that: + + the explanatory text provides defined meanings of + terms, abbreviations and acronyms that are used in a + context other than that accepted by normal + usage, + the use of a formal system and semiformal notation + use is accompanied by supporting explanatory text in + informal style appropriate for unambiguous + meaning, + the formal system is able to express rules and + characteristics of applicable SFPs, + security functionality and interfaces (providing + details of effects, exceptions and error messages) of + TSF, their subsystems or modules to be specified for + the assurance family for which the notations are + used. + the notation provides rules to determine the + meaning of syntactical valid constructs. + + Each formal system uses a formal syntax that provides + rules to unambiguously recognise constructs. + Each formal system provides proof rules which + + support logical reasoning of well-established + mathematical concepts, + help to prevent derivation of + contradictions + + If the developer uses a formal system which is already accepted + by the evaluation authority the evaluator can rely on the level + of formality and strength of the system and focus on the + instantiation of the formal system to the TOE specifications and + correspondence proofs. + + The formal style supports mathematical proofs of the security + properties based on the security features, the consistency of + refinements and the correspondence of the representations. + Formal tool support seems adequate whenever manual derivations + would otherwise become long winded and + incomprehensible. Formal tools are also apt to reduce the + error probability inherent in manual derivations. + + Examples of formal systems: + + The Z specification language is highly + expressive, and supports many different methods or styles + of formal specification. The use of Z has been + predominantly for model-oriented specification, using + schemas to formally specify + operations. See for more + information. + ACL2 is an open-source formal system + comprising a LISP-based specification language and a + theorem prover. See for + further information. + Isabelle is a popular generic theorem + proving environment that allows mathematical formulae to + be expressed in a formal language and provides tools for + proving those formulae within a logical calculus (see + e.g. for + additional information) + The B method is a formal system based + on the propositional calculus, the first order predicate + calculus with inference rules and set theory (see + e.g. for further + information). + + + + + The dependencies documented in the components of Clauses and - are the direct dependencies between the + assurance components. + + The following dependency tables for assurance components show + their direct, indirect and optional dependencies. Each of the + components that is a dependency of some assurance component is + allocated a column. Each assurance component is allocated a + row. The value in the table cell indicate whether the column + label component is directly required (indicated by a cross + ``X'') or indirectly required (indicated by a dash ``-''), by + the row label component. If no character is presented, the + component is not dependent upon another component. + + + + The purpose of this Clause is to document the philosophy that + underpins the CC approach to assurance. An understanding of this + Clause will permit the reader to understand the rationale behind + the CC Part 3 assurance requirements. + + + The CC philosophy is that the threats to security and + organisational security policy commitments should be clearly + articulated and the proposed security measures be demonstrably + sufficient for their intended purpose. + + Furthermore, measures should be adopted that reduce the + likelihood of vulnerabilities, the ability to exercise + (i.e. intentionally exploit or unintentionally trigger) a + vulnerability, and the extent of the damage that could occur + from a vulnerability being exercised. Additionally, measures + should be adopted that facilitate the subsequent + identification of vulnerabilities and the elimination, + mitigation, and/or notification that a vulnerability has been + exploited or triggered. + + + + The CC philosophy is to provide assurance based upon an + evaluation (active investigation) of the IT product that is to + be trusted. Evaluation has been the traditional means of + providing assurance and is the basis for prior evaluation + criteria documents. In aligning the existing approaches, the + CC adopts the same philosophy. The CC proposes measuring the + validity of the documentation and of the resulting IT product + by expert evaluators with increasing emphasis on scope, depth, + and rigour. + + The CC does not exclude, nor does it comment upon, the + relative merits of other means of gaining assurance. Research + continues with respect to alternative ways of gaining + assurance. As mature alternative approaches emerge from these + research activities, they will be considered for inclusion in + the CC, which is so structured as to allow their future + introduction. + + + It is assumed that there are threat agents that will + actively seek to exploit opportunities to violate security + policies both for illicit gains and for well-intentioned, + but nonetheless insecure actions. Threat agents may also + accidentally trigger security vulnerabilities, causing harm + to the organisation. Due to the need to process sensitive + information and the lack of availability of sufficiently + trusted products, there is significant risk due to failures + of IT. It is, therefore, likely that IT security breaches + could lead to significant loss. + + IT security breaches arise through the intentional + exploitation or the unintentional triggering of + vulnerabilities in the application of IT within business + concerns. + + Steps should be taken to prevent vulnerabilities arising in + IT products. To the extent feasible, vulnerabilities should + be: + + + eliminated -- that is, active steps should be taken to + expose, and remove or neutralise, all exercisable + vulnerabilities; + + + minimised -- that is, active steps should be taken to + reduce, to an acceptable residual level, the potential + impact of any exercise of a vulnerability; + + + monitored -- that is, active steps should be taken to + ensure that any attempt to exercise a residual + vulnerability will be detected so that steps can be + taken to limit the damage. + + + + + + Vulnerabilities can arise through failures in: + + + requirements -- that is, an IT product may possess all + the functions and features required of it and still + contain vulnerabilities that render it unsuitable or + ineffective with respect to security; + + + development -- that is, an IT product does not meet its + specifications and/or vulnerabilities have been + introduced as a result of poor development standards or + incorrect design choices; + + + operation -- that is, an IT product has been constructed + correctly to a correct specification but vulnerabilities + have been introduced as a result of inadequate controls + upon the operation. + + + + + + Assurance is grounds for confidence that an IT product meets + its security objectives. Assurance can be derived from + reference to sources such as unsubstantiated assertions, + prior relevant experience, or specific experience. However, + the CC provides assurance through active + investigation. Active investigation is an evaluation of the + IT product in order to determine its security + properties. + + + + Evaluation has been the traditional means of gaining + assurance, and is the basis of the CC approach. Evaluation + techniques can include, but are not limited to: + + + analysis and checking of process(es) and procedure(s); + + + checking that process(es) and procedure(s) are being + applied; + + + analysis of the correspondence between TOE design + representations; + + + analysis of the TOE design representation against the + requirements; + + + verification of proofs; + + + analysis of guidance documents; + + + analysis of functional tests developed and the results + provided; + + + independent functional testing; + + + analysis for vulnerabilities (including flaw + hypothesis); + + + penetration testing. + + + + + + + The CC philosophy asserts that greater assurance results from + the application of greater evaluation effort, and that the + goal is to apply the minimum effort required to provide the + necessary level of assurance. The increasing level of effort + is based upon: + + + scope -- that is, the effort is greater because a larger + portion of the IT product is included; + + + depth -- that is, the effort is greater because it is + deployed to a finer level of design and implementation + detail; + + + rigour -- that is, the effort is greater because it is + applied in a more structured, formal manner. + + + + + + + This annex provides an explanation of the criteria and examples of their application. This + annex does not define the criteria; + this definition can be found in CC Part 3 Section . + + This annex consists of 2 major parts: + + + Guidance for completing an independent vulnerability + analysis. This is summarised in section , and described in more + detail in section + . These sections describe how an evaluator should approach + the construction of an independent Vulnerability Analysis. + + + How to characterise and use assumed Attack Potential of an + attacker. This is described in sections to . These sections provide an example of describe + how an attack potential can be characterised and should be + used, and provide examples. + + + + + The purpose of the vulnerability assessment activity is to + determine the existence and exploitability of flaws or + weaknesses in the TOE in the operational environment. This + determination is based upon analysis performed by the + evaluator, and is supported by evaluator testing. + + At the lowest levels of the + evaluator simply performs a search of publicly available + information to identify any known weaknesses in the TOE, while + at the higher levels the evaluator performs a structured + analysis of the TOE evaluation evidence. + + There are three main factors in performing a vulnerability + analysis, namely: + + the identification of potential vulnerabilities; + + assessment to determine whether the identified potential + vulnerabilities could allow an attacker with the relevant + attack potential to violate the SFRs. + + penetration testing to determine whether the identified + potential vulnerabilities are exploitable in the operational + environment of the TOE. + + + The identification of vulnerabilities can be further + decomposed into the evidence to be searched and how hard to + search that evidence to identify potential vulnerabilities. In + a similar manner, the penetration testing can be further + decomposed into analysis of the potential vulnerability to + identify attack methods and the demonstration of the attack + methods. + + These main factors are iterative in nature, i.e. penetration + testing of potential vulnerabilities may lead to the + identification of further potential vulnerabilities. Hence, + these are performed as a single vulnerability analysis + activity. + + + + The evaluator vulnerability analysis is to determine that the + TOE is resistant to penetration attacks performed by an + attacker possessing a Basic (for and ), + Enhanced-Basic (for ), + Moderate (for ) or High (for + ) attack potential. The + evaluator first assesses the exploitability of all identified + potential vulnerabilities. This is accomplished by conducting + penetration testing. The evaluator should assume the role of + an attacker with a Basic (for + and ), Enhanced-Basic (for + ), Moderate (for ) or High (for ) attack potential when attempting to penetrate the + TOE. + + The evaluator considers potential vulnerabilities encountered + by the evaluator during the conduct of other evaluation + activities. The evaluator penetration testing determining TOE + resistance to these potential vulnerabilities should be + performed assuming the role of an attacker with a Basic (for + and ), Enhanced-Basic (for ), Moderate (for ) + or High (for ) attack + potential. + + However, vulnerability analysis should not be performed as an + isolated activity. It is closely linked with and . The evaluator + performs these other evaluation activities with a focus on + identifying potential vulnerabilities or ``areas of + concern''. Therefore, evaluator familiarity with the generic + vulnerability guidance (provided in Section ) is required. + + + The following five categories provide discussion of generic + vulnerabilities. + + + Bypassing includes any means by which an attacker could + avoid security enforcement, by: + + + exploiting the capabilities of interfaces to the TOE, + or of utilities which can interact with the TOE; + + + inheriting privileges or other capabilities that + should otherwise be denied; + + + (where confidentiality is a concern) reading sensitive + data stored or copied to inadequately protected areas. + + + + Each of the following should be considered (where + relevant) in the evaluator's independent vulnerability + analysis. + + + Attacks based on exploiting the capabilities of + interfaces or utilities generally take advantage of + the absence of the required security enforcement on + those interfaces. For example, gaining access to + functionality that is implemented at a lower level + than that at which access control is + enforced. Relevant items include: + + + changing the predefined sequence of invocation of + TSFI; + + + invoking an additional TSFI; + + + using a component in an unexpected context or for + an unexpected purpose; + + + using implementation detail introduced in less + abstract representations; + + + using the delay between time of access check and + time of use. + + + + + Changing the predefined sequence of invocation of + components should be considered where there is an + expected order in which interfaces to the TOE + (e.g. user commands) are called to invoke a TSFI + (e.g. opening a file for access and then reading data + from it). If a TSFI is invoked through one of the TOE + interfaces (e.g. an access control check), the + evaluator should consider whether it is possible to + bypass the control by performing the call at a later + point in the sequence or by missing it out altogether. + + + Executing an additional component (in the predefined + sequence) is a similar form of attack to the one + described above, but involves the calling of some + other TOE interface at some point in the sequence. It + can also involve attacks based on interception of + sensitive data passed over a network by use of network + traffic analysers (the additional component here being + the network traffic analyser). + + + Using a component in an unexpected context or for an + unexpected purpose includes using an unrelated TOE + interface to bypass the TSF by using it to achieve a + purpose that it was not designed or intended to + achieve. Covert channels are an example of this type + of attack (see for further discussion of covert + channels). The use of undocumented interfaces, which + may be insecure, also falls into this category. Such + interfaces may include undocumented support and help + facilities. + + + Using implementation detail introduced in lower + representations may allow an attacker to take + advantage of additional functions, resources or + attributes that are introduced to the TOE as a + consequence of the refinement process. Additional + functionality may include test harness code contained + in software modules and back-doors introduced during + the implementation process. + + + Using the delay between time of check and time of use + includes scenarios where an access control check is + made and access granted, and an attacker is + subsequently able to create conditions in which, had + they applied at the time the access check was made, + would have caused the check to fail. An example would + be a user creating a background process to read and + send highly sensitive data to the user's terminal, and + then logging out and logging back in again at a lower + sensitivity level. If the background process is not + terminated when the user logs off, the MAC checks + would have been effectively bypassed. + + + Attacks based on inheriting privileges are generally + based on illicitly acquiring the privileges or + capabilities of some privileged component, usually by + exiting from it in an uncontrolled or unexpected + manner. Relevant items include: + + + executing data not intended to be executable, or + making it executable; + + + generating unexpected input for a component; + + + invalidating assumptions and properties on which + lower-level components rely. + + + + + Executing data not intended to be executable, or + making it executable includes attacks involving + viruses (e.g. putting executable code or commands in a + file which are automatically executed when the file is + edited or accessed, thus inheriting any privileges the + owner of the file has). + + + Generating unexpected input for a component can have + unexpected effects which an attacker could take + advantage of. For example, if the TSF could be + bypassed if a user gains access to the underlying + operating system, it may be possible to gain such + access following the login sequence by exploring the + effect of hitting various control or escape sequences + whilst a password is being authenticated. + + + Invalidating assumptions and properties on which lower + level components rely includes attacks based on + breaking out of the constraints of an application to + gain access to an underlying operating system in order + to bypass the TSF of an application. In this case the + assumption being invalidated is that it is not + possible for a user of the application to gain such + access. A similar attack can be envisaged against an + application on an underlying database management + system: again the TSF could be bypassed if an attacker + can break out of the constraints of the application. + + + Attacks based on reading sensitive data stored in + inadequately protected areas (applicable where + confidentiality is a concern) include the following + issues which should be considered as possible means of + gaining access to sensitive data: + + + disk scavenging; + + + access to unprotected memory; + + + exploiting access to shared writable files or + other shared resources (e.g. swap files); + + + Activating error recovery to determine what access + users can obtain. For example, after a crash an + automatic file recovery system may employ a lost + and found directory for headerless files, which + are on disk without labels. If the TOE implements + mandatory access controls, it is important to + investigate at what security level this directory + is kept (e.g. at system high), and who has access + to this directory. + + + + + + There are a number of different methods through which an + evaluator may identify a back-door, including two main + techniques. Firstly, by the evaluator inadvertently + identifying during testing an interface that can be + misused. Secondly, through testing each external + interface of the TSF in a debugging mode to identify any + modules that are not called as a part of testing the + documented interfaces and then inspecting the code that is + not called to consider whether it is a back-door. + + For a software TOE where and or + higher components are included in the assurance package, + the evaluator may consider during their analysis of the + tools the libraries and packages that are linked by the + compiler at compilation stage to determine that back-doors + are not introduced at this stage. + + + + Tampering includes any attack based on an attacker + attempting to influence the behaviour of the TSF + (i.e. corruption or de-activation), for example by: + + + accessing data on whose confidentiality or integrity + the TSF relies; + + + forcing the TOE to cope with unusual or unexpected + circumstances; + + + disabling or delaying security enforcement; + + + physical modification the TOE. + + + + Each of the following should be considered (where + relevant) in the evaluator's independent vulnerability + analysis. + + + Attacks based on accessing data, whose confidentiality + or integrity are protected, include: + + + reading, writing or modifying internal data + directly or indirectly; + + + using a component in an unexpected context or for + an unexpected purpose; + + + using interfaces between components that are not + visible at a higher level of abstraction. + + + + + Reading, writing or modifying internal data directly + or indirectly includes the following types of attack + which should be considered: + + + reading ``secrets'' stored internally, such as + user passwords; + + + spoofing internal data that security enforcing + mechanisms rely upon; + + + modifying environment variables (e.g. logical + names), or data in configuration files or + temporary files. + + + + It may be possible to deceive a trusted process into + modifying a protected file that it wouldn't normally + access. + + + The evaluator should also consider the following + ``dangerous features'': + + + source code resident on the TOE along with a + compiler (for instance, it may be possible to + modify the login source code); + + + an interactive debugger and patch facility (for + instance, it may be possible to modify the + executable image); + + + the possibility of making changes at device + controller level, where file protection does not + exist; + + + diagnostic code which exists in the source code + and that may be optionally included; + + + developer's tools left in the TOE. + + + + + Using a component in an unexpected context or for an + unexpected purpose includes (for example), where the + TOE is an application built upon an operating system, + users exploiting knowledge of a word processor package + or other editor to modify their own command file + (e.g. to acquire greater privileges). + + + Using interfaces between components which are not + visible at a higher level of abstraction includes + attacks exploiting shared access to resources, where + modification of a resource by one component can + influence the behaviour of another (trusted) + component, e.g. at source code level, through the use + of global data or indirect mechanisms such as shared + memory or semaphores. + + + Attacks based on forcing the TOE to cope with unusual + or unexpected circumstances should always be + considered. Relevant items include: + + + generating unexpected input for a component; + + + invalidating assumptions and properties on which + lower-level components rely. + + + + + Generating unexpected input for a component includes + investigating the behaviour of the TOE when: + + + command input buffers overflow (possibly + ``crashing the stack'' or overwriting other + storage, which an attacker may be able to take + advantage of, or forcing a crash dump that may + contain sensitive information such as clear-text + passwords); + + + invalid commands or parameters are entered + (including supplying a read-only parameter to an + interface which expects to return data via that + parameter and supplying improperly formatted input + that should fail parsing such as SQL-injection, + format strings); + + + an end-of-file marker (e.g. CTRL-Z or CTRL-D) or + null character is inserted in an audit trail. + + + + + Invalidating assumptions and properties on which + lower-level components rely includes attacks taking + advantage of errors in the source code where the code + assumes (explicitly or implicitly) that security + relevant data is in a particular format or has a + particular range of values. In these cases the + evaluator should determine whether they can invalidate + such assumptions by causing the data to be in a + different format or to have different values, and if + so whether this could confer advantage to an attacker. + + + The correct behaviour of the TSF may be dependent on + assumptions that are invalidated under extreme + circumstances where resource limits are reached or + parameters reach their maximum value. The evaluator + should consider (where practical) the behaviour of the + TOE when these limits are reached, for example: + + + changing dates (e.g. examining how the TOE behaves + when a critical date threshold is passed); + + + filling disks; + + + exceeding the maximum number of users; + + + filling the audit log; + + + saturating security alarm queues at a console; + + + overloading various parts of a multi-user TOE + which relies heavily upon communications + components; + + + swamping a network, or individual hosts, with + traffic; + + + filling buffers or fields. + + + + + Attacks based on disabling or delaying security + enforcement include the following items: + + + using interrupts or scheduling functions to + disrupt sequencing; + + + disrupting concurrence; + + + using interfaces between components which are not + visible at a higher level of abstraction. + + + + + Using interrupts or scheduling functions to disrupt + sequencing includes investigating the behaviour of the + TOE when: + + + a command is interrupted (with CTRL-C, CTRL-Y, + etc.); + + + a second interrupt is issued before the first is + acknowledged. + + + + + The effects of terminating security critical processes + (e.g. an audit daemon) should be explored. Similarly, + it may be possible to delay the logging of audit + records or the issuing or receipt of alarms such that + it is of no use to an administrator (since the attack + may already have succeeded). + + + Disrupting concurrence includes investigating the + behaviour of the TOE when two or more subjects attempt + simultaneous access. It may be that the TOE can cope + with the interlocking required when two subjects + attempt simultaneous access, but that the behaviour + becomes less well defined in the presence of further + subjects. For example, a critical security process + could be put into a resource-wait state if two other + processes are accessing a resource which it requires. + + + Using interfaces between components which are not + visible at a higher level of abstraction may provide a + means of delaying a time-critical trusted process. + + + Physical attacks can be categorised into physical + probing, physical manipulation, physical modification, + and substitution. + + + Physical probing by penetrating the TOE targeting + internals of the TOE, e.g. reading at internal + communication interfaces, lines or memories. + + + Physical manipulation can be with the TOE + internals aiming at internal modifications of the + TOE (e.g. by using optical fault induction as an + interaction process), at the external interfaces + of the TOE (e.g. by power or clock glitches) and + at the TOE environment (e.g. by modifying + temperature). + + + Physical modification of TOE internal security + enforcing attributes to inherit privileges or + other capabilities that should be denied in + regular operation. Such modifications can be + caused, e.g., by optical fault induction. Attacks + based on physical modification may also yield a + modification of the TSF itself, e.g. by causing + faults at TOE internal program data transfers + before execution. Note, that such kind of + bypassing by modifying the TSF itself can + jeopardise every TSF unless there are other + measures (possibly environmental measures) that + prevent an attacker from gaining physical access + to the TOE. + + + Physical substitution to replace the TOE with + another IT entity, during delivery or operation of + the TOE. Substitution during delivery of the TOE + from the development environment to the user + should be prevented through application of secure + delivery procedures (such as those considered + under ). Substitution of the TOE during + operation may be considered through a combination + of user guidance and the operational environment, + such that the user is able to be confident that + they are interacting with the TOE. + + + + + + + + Direct attack includes the identification of any + penetration tests necessary to test the strength of + permutational or probabilistic mechanism and other + mechanisms to ensure they withstand direct attack. + + For example, it may be a flawed assumption that a + particular implementation of a pseudo-random number + generator will possess the required entropy necessary to + seed the security mechanism. + + Where a probabilistic or permutational mechanism relies on + selection of security attribute value (e.g. selection of + password length) or entry of data by a human user + (e.g. choice of password), the assumptions made should + reflect the worst case. + + Probabilistic or permutational mechanisms should be + identified during examination of evaluation evidence + required as input to this sub-activity (security target, + functional specification, TOE design and implementation + representation subset) and any other TOE (e.g. guidance) + documentation may identify additional probabilistic or + permutational mechanisms. + + Where the design evidence or guidance includes assertions + or assumptions (e.g. about how many authentication + attempts are possible per minute), the evaluator should + independently confirm that these are correct. This may be + achieved through testing or through independent + analysis. + + Direct attacks reliant upon a weakness in a cryptographic + algorithm should not be considered under , as this is outside the scope + of the CC. Correctness of the implementation of the + cryptographic algorithm is considered during the and + activities. + + + + Information is an abstract view on relation between the + properties of entities, i.e. a signal contains information + for a system, if the TOE is able to react to this + signal. The TOE resources processes and stores information + represented by user data. Therefore: + + + information may flow with the user data between + subjects by internal TOE transfer or export from the TOE; + + + information may be generated and passed to other user + data; + + + information may be gained through monitoring the + operations on data representing the information. + + + + The information represented by user data may be + characterised by security attributes like ``classification + level'' having values, for example unclassified, + confidential, secret, top secret, to control operations to + the data. This information and therefore the security + attributes may be changed by operations e.g. may describe decrease of the + level by ``sanitarisation'' or increase of level by + combination of data. This is one aspects of an information + flow analysis focused on controlled operations of + controlled subjects on controlled objects. + + The other aspect is the analysis of illicit + information flow. This aspect is more + general than the direct access to objects containing user + data addressed by the + family. An unenforced + signalling channel carrying information under control of + the information flow control policy can also be caused by + monitoring of the processing of any object containing or + related to this information (e.g. side channels). An + enforced signalling channels + may be identified in terms of the subjects manipulating + resources and the subject or user that observe such + manipulation. Classically, covert channels have been + identified as timing or storage channels, according to the + resource being modified or modulated. As for other + monitoring attacks, the use of the TOE is in accordance + with the SFRs. + + Covert channels are normally applicable in the case when + the TOE has unobservability AND multi-level separation + policy requirements. Covert channels may be routinely + spotted during vulnerability analysis and design + activities, and should therefore be tested. However, + generally such monitoring attacks are only identified + through specialised analysis techniques commonly referred + to as ``covert channel analysis''. These techniques have + been the subject of much research and there are many + papers published on this subject. Guidance for the + conduct of covert channel analysis should be sought from + the evaluation authority. + + Unenforced information flow monitoring + attacks include passive analysis techniques aiming at + disclosure of sensitive internal data of the TOE by + operating the TOE in the way that corresponds to the + guidance documents. + + Side Channel Analysis includes crypt analytical techniques + based on physical leakage of the TOE. Physical leakage can + occur by timing information, power consumption or power + emanation during computation of a TSF. Timing information + can be collected also by a remote-attacker (having network + access to the TOE), power based information channels + requires that the attacker is in the near-by environment + of the TOE. + + Eavesdropping techniques include interception of all forms + of energy, e.g., electromagnetic or optical emanation of + computer displays, not necessarily in the near-field of + the TOE. + + Monitoring also includes exploits of protocol flaws, e.g., + an attack on SSL implementation. + + + + Misuse may arise from: + + + incomplete guidance documentation; + + + unreasonable guidance; + + + unintended misconfiguration of the TOE; + + + forced exception behaviour of the TOE. + + + + If the guidance documentation is incomplete the user may + not know how to operate the TOE in accordance with the + SFRs. The evaluator should apply familiarity with the TOE + gained from performing other evaluation activities to + determine that the guidance is complete. In particular, + the evaluator should consider the functional + specification. The TSF described in this document should + be described in the guidance as required to permit secure + administration and use through the TSFI available to human + users. In addition, the different modes of operation + should be considered to ensure that guidance is provided + for all modes of operation. + + The evaluator may, as an aid, prepare an informal mapping + between the guidance and these documents. Any omissions in + this mapping may indicate incompleteness. + + The guidance is considered to be unreasonable if it makes + demands on the TOE's usage or operational environment that + are inconsistent with the ST or unduly onerous to maintain + security. + + A TOE may use a variety of ways to assist the consumer in + effectively using that TOE in accordance with the SFRs and + prevent unintentional misconfiguration. A TOE may employ + functionality (features) to alert the consumer when the + TOE is in a state that is inconsistent with the SFRs, + whilst other TOEs may be delivered with enhanced guidance + containing suggestions, hints, procedures, etc. on using + the existing security features most effectively; for + instance, guidance on using the audit feature as an aid + for detecting when the SFRs are being compromised; namely + insecure. + + The evaluator considers the TOE's functionality, its + purpose and security objectives for the operational + environment to arrive at a conclusion of whether or not + there is reasonable expectation that use of the guidance + would permit transition into an insecure state to be + detected in a timely manner. + + The potential for the TOE to enter into insecure states + may be determined using the evaluation deliverables, such + as the ST, the functional specification and any other + design representations provided as evidence for components + included in the assurance package for the TOE (e.g. the + TOE/TSF design specification if a component from is included). + + Instances of forced exception behaviour of the TSF could + include, but are not limited to, the following: + + + behaviour of the TOE when start-up, close-down or error + recovery is activated; + + + behaviour of the TOE under extreme circumstances + (sometimes termed overload or asymptotic behaviour), + particularly where this could lead to the + de-activation or disabling of parts of the TSF; + + + any potential for unintentional misconfiguration or + insecure use arising from attacks noted in the section + on tampering above. + + + + + + + Potential vulnerabilities may be identified by the evaluator + during different activities. They may become apparent during + an evaluation activity or they may be identified as a result + of analysis of evidence to search for + vulnerabilities. + + + The encountered identification of vulnerabilities is where + potential vulnerabilities are identified by the evaluator + during the conduct of evaluation activities, i.e. the + evidence are not being analysed with the express aim of + identifying potential vulnerabilities. + + The encountered method of identification is dependent on the + evaluator's experience and knowledge; which is monitored and + controlled by the evaluation authority. It is not reproducible + in approach, but will be documented to ensure repeatability of + the conclusions from the reported potential + vulnerabilities. + + There are no formal analysis criteria required for this + method. Potential vulnerabilities are identified from the + evidence provided as a result of knowledge and + experience. However, this method of identification is not + constrained to any particular subset of evidence. + + Evaluator is assumed to have knowledge of the TOE-type + technology and known security flaws as documented in the + public domain. The level of knowledge assumed is that + which can be gained from a security e-mail list relevant + to the TOE type, the regular bulletins (bug, vulnerability + and security flaw lists) published by those organisations + researching security issues in products and technologies + in widespread use. This knowledge is not expected to + extend to specific conference proceedings or detailed + theses produced by university research for or . However, to ensure the knowledge applied is + up to date, the evaluator may need to perform a search of + public domain material. + + For to the search of publicly + available information is expected to include conference + proceeding and theses produced during research activities + by universities and other relevant organisations. + + Examples of how these may arise (how the evaluator may + encounter potential vulnerabilities): + + + while the evaluator is examining some evidence, it + sparks a memory of a potential vulnerability + identified in a similar product type, that the + evaluator believes to also be present in the TOE under + evaluation; + + + while examining some evidence, the evaluator spots a + flaw in the specification of an interface, that + reflects a potential vulnerability. + + + This may include becoming aware of a potential + vulnerability in a TOE through reading about generic + vulnerabilities in a particular product type in an IT + security publication or on a security e-mail list to which + the evaluator is subscribed. + + Attack methods can be developed directly from these + potential vulnerabilities. Therefore, the encountered + potential vulnerabilities are collated at the time of + producing penetration tests based on the evaluator's + vulnerability analysis. There is no explicit action for + the evaluator to encounter potential + vulnerabilities. Therefore, the evaluator is directed + through an implicit action specified in and .*.4E. + + Current information regarding public domain + vulnerabilities and attacks may be provided to the + evaluator by, for example, an evaluation authority. This + information is to be taken into account by the evaluator + when collating encountered vulnerabilities and attack + methods when developing penetration tests. + + + + The following types of analysis are presented in terms of + the evaluator actions. + + + The unstructured analysis to be performed by the + evaluator (for ) + permits the evaluator to consider the generic + vulnerabilities (as discussed in ). The evaluator will also apply their + experience and knowledge of flaws in similar technology + types. + + + + During the conduct of evaluation activities the + evaluator may also identify areas of concern. These are + specific portions of the TOE evidence that the evaluator + has some reservation about, although the evidence meets + the requirements for the activity with which the + evidence is associated. For example, a particular + interface specification looks particularly complex, and + therefore may be prone to error either in the + development of the TOE or in the operation of the + TOE. There is no potential vulnerability apparent at + this stage, further investigation is required. This is + beyond the bounds of encountered, as further + investigation is required. + + Difference between potential vulnerability and area of + concern: + + + Potential vulnerability - The evaluator knows a + method of attack that can be used to exploit the + weakness or the evaluator knows of vulnerability + information that is relevant to the TOE. + + + Area of concern - The evaluator may be able to + discount concern as a potential vulnerability based + on information provided elsewhere. While reading + interface specification, the evaluator identifies + that due to the extreme (unnecessary) complexity of + an interface a potential vulnerability may lay + within that area, although it is not apparent + through this initial examination. + + + The focused approach to the identification of + vulnerabilities is an analysis of the evidence with the + aim of identifying any potential vulnerabilities evident + through the contained information. It is an unstructured + analysis, as the approach is not predetermined. This + approach to the identification of potential + vulnerabilities can be used during the independent + vulnerability analysis required by . + + This analysis can be achieved through different + approaches, that will lead to commensurate levels of + confidence. None of the approaches have a rigid format + for the examination of evidence to be performed. + + The approach taken is directed by the results of the + evaluator's assessment of the evidence to determine it + meets the requirements of the / + sub-activities. Therefore, the investigation of the + evidence for the existence of potential vulnerabilities + may be directed by any of the following: + + + areas of concern identified during examination of + the evidence during the conduct of evaluation + activities; + + + reliance on particular functionality to provide + separation, identified during the analysis of the + architectural design (as in ), requiring further analysis to + determine it cannot be bypassed; + + + representative examination of the evidence to + hypothesise potential vulnerabilities in the + TOE. + + The evaluator will report what actions were taken to + identify potential vulnerabilities in the + evidence. However, the evaluator may not be able to + describe the steps in identifying potential + vulnerabilities before the outset of the + examination. The approach will evolve as a result of the + outcome of evaluation activities. + + The areas of concern may arise from examination of any + of the evidence provided to satisfy the SARs specified + for the TOE evaluation. The information publicly + accessible is also considered. + + The activities performed by the evaluator can be + repeated and the same conclusions, in terms of the level + of assurance in the TOE, can be reached although the + steps taken to achieve those conclusions may vary. As + the evaluator is documenting the form the analysis took, + the actual steps taken to achieve those conclusions are + also reproducible. + + + + The methodical analysis approach takes the form of a + structured examination of the evidence. This method + requires the evaluator to specify the structure and form + the analysis will take (i.e. the manner in which the + analysis is performed is predetermined, unlike the + focused identification method). The method is specified + in terms of the information that will be considered and + how/why it will be considered. This approach to the + identification of potential vulnerabilities can be used + during the independent vulnerability analysis required + by and . + + This analysis of the evidence is deliberate and + pre-planned in approach, considering all evidence + identified as an input into the analysis. + + All evidence provided to satisfy the () assurance requirements specified in the + assurance package are used as input to the potential + vulnerability identification activity. + + The ``methodical'' descriptor for this analysis has been + used in an attempt to capture the characterisation that + this identification of potential vulnerabilities is to + take an ordered and planned approach. A ``method'' or + ``system'' is to be applied in the examination. The + evaluator is to describe the method to be used in terms + of what evidence will be considered, the information + within the evidence that is to be examined, the manner + in which this information is to be considered; and the + hypothesis that is to be generated. + + The following provide some examples that a hypothesis + may take: + + + consideration of malformed input for interfaces + available to an attacker at the external interfaces; + + + examination of a security mechanism, such as domain + separation, hypothesising internal buffer overflows + leading to degradation of separation; + + + analysis to identify any objects created in the TOE + implementation representation that are then not + fully controlled by the TSF, and could be used by an + attacker to undermine the SFRs. + + + + For example, the evaluator may identify that interfaces + are a potential area of weakness in the TOE and specify + an approach to the analysis that ``all interface + specifications provided in the functional specification + and TOE design will be analysed to hypothesise potential + vulnerabilities'' and go on to explain the methods used + in the hypothesis. + + This identification method will provide a plan of attack + of the TOE, that would be performed by an evaluator + completing penetration testing of potential + vulnerabilities in the TOE. The rationale for the method + of identification would provide the evidence for the + coverage and depth of exploitation determination that + would be performed on the TOE. + + + + + + + + Attack potential is used by a PP/ST author during the + development of the PP/ST, in consideration of the threat + environment and the selection of assurance components. This + may simply be a determination that the attack potential + possessed by the assumed attackers of the TOE is generically + characterised as Basic, Enhanced-Basic, Moderate or + High. Alternatively, the PP/ST may wish to specify + particular levels of individual factors assumed to be + possessed by attackers. (e.g. the attackers are assumed to + be experts in the TOE technology type, with access to + specialised equipment.) + + The PP/ST author considers the threat profile developed during a + risk assessment (outside the scope of the CC, but used as an + input into the development of the PP/ST in terms of the Security + Problem Definition or in the case of low assurance STs, the + requirements statement). Consideration of this threat profile in + terms of one of the approaches discussed in the following + sections will permit the specification of the attack potential + the TOE is to resist. + + + + Attack potential is especially considered by the evaluator + in two distinct ways during the ST evaluation and the + vulnerability assessment activities. + + Attack potential is used by an evaluator during the conduct + of the vulnerability analysis sub-activity to determine + whether or not the TOE is resistant to attacks assuming a + specific attack potential of an attacker. If the evaluator + determines that a potential vulnerability is exploitable in + the TOE, they have to confirm that it is exploitable + considering all aspects of the intended environment, + including the attack potential assumed by an + attacker. + + Therefore, using the information provided in the threat + statement of the Security Target, the evaluator determines + the minimum attack potential required by an attacker to + effect an attack, and arrives at some conclusion about the + TOE's resistance to attacks. Table demonstrates the relationship between this + analysis and attack potential. + + + + + Vulnerability Component + TOE resistant to attacker with + attack potential of: + Residual vulnerabilities only + exploitable by attacker with attack potential + of: + + + + + VAN.5 + High + Beyond High + + + VAN.4 + Moderate + High + + + VAN.3 + Enhanced-Basic + Moderate + + + VAN.2 + Basic + Enhanced-Basic + + + VAN.1 + Basic + Enhanced-Basic + + + + Vulnerability testing and attack potential +
+ + The ``beyond high'' entry in the residual vulnerabilities + column of the above table represents those potential + vulnerabilities that would require an attacker to have an + attack potential greater than that of ``high'' in order to + exploit the potential vulnerability. A vulnerability + classified as residual in this instance reflects the fact + that a known weakness exists in the TOE, but in the current + operational environment, with the assumed attack potential, + the weakness cannot be exploited. + + At any level of attack potential a potential vulnerability + may be deemed ``infeasible'' due to a countermeasure in the + operational environment that prevents the vulnerability from + being exploited. + + A vulnerability analysis applies to all TSFI, including ones + that access probabilistic or permutational mechanisms. No + assumptions are made regarding the correctness of the design + and implementation of the TSFI; nor are constraints placed + on the attack method or the attacker's interaction with the + TOE - if an attack is possible, then it is to be considered + during the vulnerability analysis. As shown in Table , successful evaluation + against a vulnerability assurance component reflects that + the TSF is designed and implemented to protect against the + required level of threat. + + It is not necessary for an evaluator to perform an attack + potential calculation for each potential vulnerability. In + some cases it is apparent when developing the attack method + whether or not the attack potential required to develop and + run the attack method is commensurate with that assumed of + the attacker in the operational environment. For any + vulnerabilities for which an exploitation is determined, the + evaluator performs an attack potential calculation to + determine that the exploitation is appropriate to the level + of attack potential assumed for the attacker. + + The approach described below is to be applied whenever it is + necessary to calculate attack potential, unless the evaluation + authority provides mandatory guidance that an alternative + approach is to be applied. The values given in Tables and + below are not mathematically proven. Therefore, the values given + in these example tables may need to be adjusted according to the + technology type and specific environments. The evaluator should + seek guidance from the evaluation authority. + + + + + + Attack potential is a function of expertise, resources and + motivation. There are multiple methods of representing and + quantifying these factors. Also, there may be other factors + that are applicable for particular TOE types. + + + Motivation is an attack potential factor that can be used + to describe several aspects related to the attacker and + the assets the attacker desires. Firstly, motivation can + imply the likelihood of an attack - one can infer from a + threat described as highly motivated that an attack is + imminent, or that no attack is anticipated from an + un-motivated threat. However, except for the two extreme + levels of motivation, it is difficult to derive a + probability of an attack occurring from motivation. + + Secondly, motivation can imply the value of the asset, + monetarily or otherwise, to either the attacker or the + asset holder. An asset of very high value is more likely + to motivate an attack compared to an asset of little + value. However, other than in a very general way, it is + difficult to relate asset value to motivation because the + value of an asset is subjective - it depends largely upon + the value an asset holder places on it. + + Thirdly, motivation can imply the expertise and resources + with which an attacker is willing to effect an attack. One + can infer that a highly motivated attacker is likely to + acquire sufficient expertise and resources to defeat the + measures protecting an asset. Conversely, one can infer + that an attacker with significant expertise and resources + is not willing to effect an attack using them if the + attacker's motivation is low. + + During the course of preparing for and conducting an + evaluation, all three aspects of motivation are at some + point considered. The first aspect, likelihood of attack, + is what may inspire a developer to pursue an + evaluation. If the developer believes that the attackers + are sufficiently motivated to mount an attack, then an + evaluation can provide assurance of the ability of the TOE + to thwart the attacker's efforts. Where the operational + environment is well defined, for example in a system + evaluation, the level of motivation for an attack may be + known, and will influence the selection of + countermeasures. + + Considering the second aspect, an asset holder may believe + that the value of the assets (however measured) is + sufficient to motivate attack against them. Once an + evaluation is deemed necessary, the attacker's motivation + is considered to determine the methods of attack that may + be attempted, as well as the expertise and resources used + in those attacks. Once examined, the developer is able to + choose the appropriate assurance level, in particular the + requirement components, + commensurate with the attack potential for the + threats. During the course of the evaluation, and in + particular as a result of completing the vulnerability + assessment activity, the evaluator determines whether or + not the TOE, operating in its operational environment, is + sufficient to thwart attackers with the identified + expertise and resources. + + It may be possible for a PP author to quantify the + motivation of an attacker, as the PP author has greater + knowledge of the operational environment in which the TOE + (conforming to the requirements of the PP) is to be + placed. Therefore, the motivation could form an explicit + part of the expression of the attack potential in the PP, + along with the necessary methods and measures to quantify + the motivation. + + + + + This section examines the factors that determine attack + potential, and provides some guidelines to help remove some + of the subjectivity from this aspect of the evaluation + process. + + + The determination of the attack potential for an attack + corresponds to the identification of the effort required to + create the attack, and to demonstrate that it can be + successfully applied to the TOE (including setting up or + building any necessary test equipment), thereby exploiting the + vulnerability in the TOE. The demonstration that the attack can + be successfully applied needs to consider any difficulties in + expanding a result shown in the laboratory to create a useful + attack. For example, where an experiment reveals some bits or + bytes of a confidential data item (such as a key), it is + necessary to consider how the remainder of the data item would + be obtained (in this example some bits might be measured + directly by further experiments, while others might be found by + a different technique such as exhaustive search). It may not be + necessary to carry out all of the experiments to identify the + full attack, provided it is clear that the attack actually + proves that access has been gained to a TOE asset, and that the + complete attack could realistically be carried out in + exploitation according to the + component targeted. In some cases the only way to prove that an + attack can realistically be carried out in exploitation + according to the component + targeted is to perform completely the attack and + then rate it based upon the resources actually required. + One of the outputs from the identification of a potential + vulnerability is assumed to be a script that gives a + step-by-step description of how to carry out the attack that can + be used in the exploitation of the vulnerability on another + instance of the TOE. + + In many cases, the evaluators will estimate the parameters + for exploitation, rather than carry out the full + exploitation. The estimates and their rationale will be + documented in the ETR. + + + + The following factors should be considered during analysis + of the attack potential required to exploit a + vulnerability: + + + Time taken to identify and exploit ( + Elapsed Time); + + + Specialist technical expertise required ( + Specialist Expertise); + + + Knowledge of the TOE design and operation ( + Knowledge of the TOE); + + + + Window of opportunity; + + + + IT hardware/software or other + equipment required for + exploitation. + + + + In many cases these factors are not independent, but may be + substituted for each other in varying degrees. For example, + expertise or hardware/software may be a substitute for time. A + discussion of these factors follows. (The levels of each factor + are discussed in increasing order of magnitude.) When it is the + case, the less ``expensive'' combination is considered in the + exploitation phase. + Elapsed time is the total amount + of time taken by an attacker to identify that a particular + potential vulnerability may exist in the TOE, to develop an + attack method and to sustain effort required to mount the attack + against the TOE. When considering this factor, the worst case + scenario is used to estimate the amount of time required. The + identified amount of time is as follows: + less than one day;between one day and one week;between one week and two weeks;between two weeks and one month;each additional month up to 6 months leads to an + increased value;more than 6 months. + + Specialist expertise refers + to the level of generic knowledge of the underlying + principles, product type or attack methods (e.g. Internet + protocols, Unix operating systems, buffer overflows). The + identified levels are as follows: + + + Laymen are unknowledgeable compared to experts or + proficient persons, with no particular expertise; + + + Proficient persons are knowledgeable in that they are + familiar with the security behaviour of the product or + system type; + + + Experts are familiar with the underlying algorithms, + protocols, hardware, structures, security behaviour, + principles and concepts of security employed, + techniques and tools for the definition of new + attacks, cryptography, classical attacks for the + product type, attack methods, etc. implemented in the + product or system type. + + + The level ``Multiple Expert'' is introduced to allow for + a situation, where different fields of expertise are + required at an Expert level for distinct steps of an + attack. + + It may occur that several types of expertise are + required. By default, the higher of the different + expertises factors is chosen. In very specific cases, the + ``multiple expert'' level could be used but it should be + noted that the expertise must concern fields that are + strictly different like for example HW manipulation and + cryptography. + + + Knowledge of the TOE refers to + specific expertise in relation to the TOE. This is + distinct from generic expertise, but not unrelated to + it. Identified levels are as follows: + + + Public information concerning the TOE (e.g. as gained + from the Internet); + + + Restricted information concerning the TOE + (e.g. knowledge that is controlled within the + developer organisation and shared with other + organisations under a non-disclosure agreement) + + + Sensitive information about the TOE (e.g. knowledge + that is shared between discreet teams within the + developer organisation, access to which is constrained + only to members of the specified teams); + + + Critical information about the TOE (e.g. knowledge + that is known by only a few individuals, access to + which is very tightly controlled on a strict need to + know basis and individual undertaking). + + + + The knowledge of the TOE may graduate according to design + abstraction, although this can only be done on a TOE by + TOE basis. Some TOE designs may be public source (or + heavily based on public source) and therefore even the + design representation would be classified as public or at + most restricted, while the implementation representation + for other TOEs is very closely controlled as it would give + an attacker information that would aid an attack and is + therefore considered to be sensitive or even + critical. + + It may occur that several types of knowledge are + required. In such cases, the higher of the different + knowledge factors is chosen. + + + Window of opportunity + + (Opportunity) is also an important consideration, and has + a relationship to the Elapsed Time + factor. Identification or exploitation of a + vulnerability may require considerable amounts of access + to a TOE that may increase the likelihood of + detection. Some attack methods may require considerable + effort off-line, and only brief access to the TOE to + exploit. Access may also need to be continuous, or over a + number of sessions. + + For some TOEs the Window of + opportunity may equate to the number of + samples of the TOE that the attacker can obtain. This is + particularly relevant where attempts to penetrate the + TOE and undermine the SFRs may result in the destruction + of the TOE preventing use of that TOE sample for further + testing, e.g. hardware devices. Often in these cases + distribution of the TOE is controlled and so the + attacker must apply effort to obtain further samples of + the TOE. + + For the purposes of this discussion: + + + unnecessary/unlimited access means that the attack + doesn't need any kind of opportunity to be realised + because there is no risk of being detected during + access to the TOE and it is no problem to access the + number of TOE samples for the attack; + + easy means that access is required for less than a day + and that the number of TOE samples required to perform + the attack is less than ten; + + moderate means that access is required for less than a + month and that the number of TOE samples required to + perform the attack is less than one hundred; + + difficult means that access is required for at least a + month or that the number of TOE samples required to + perform the attack is at least one hundred; + + none means that the opportunity window is not + sufficient to perform the attack (the length for which + the asset to be exploited is available or is sensitive + is less than the opportunity length needed to perform + the attack - for example, if the asset key is changed + each week and the attack needs two weeks); another + case is, that a sufficient number of TOE samples + needed to perform the attack is not accessible to the + attacker - for example if the TOE is a hardware and + the probability to destroy the TOE during the attack + instead of being successful is very high and the + attacker has only access to one sample of the + TOE. + + Consideration of this factor may result in determining + that it is not possible to complete the exploit, due to + requirements for time availability that are greater than + the opportunity time. + + + IT hardware/software or other equipment + refers to the equipment required to identify + or exploit a vulnerability. + + + Standard equipment is readily available to the + attacker, either for the identification of a + vulnerability or for an attack. This equipment may be + a part of the TOE itself (e.g. a debugger in an + operating system), or can be readily obtained + (e.g. Internet downloads, protocol analyser or simple + attack scripts). + + + Specialised equipment is not readily available to the attacker, + but could be acquired without undue effort. This could include + purchase of moderate amounts of equipment (e.g. power analysis + tools, use of hundreds of PCs linked across the Internet would + fall into this category), or development of more extensive + attack scripts or programs. If clearly different test benches + consisting of specialised equipment are required for distinct + steps of an attack this would be rated as bespoke. + + + Bespoke equipment is not readily available to the + public as it may need to be specially produced + (e.g. very sophisticated software), or because the + equipment is so specialised that its distribution is + controlled, possibly even restricted. Alternatively, + the equipment may be very expensive. + + The level ``Multiple Bespoke'' is introduced to allow + for a situation, where different types of bespoke + equipment are required for distinct steps of an + attack. + + Specialist expertise and Knowledge of the + TOE are concerned with the information + required for persons to be able to attack a TOE. There + is an implicit relationship between an attacker's + expertise (where the attacker may be one or more persons + with complementary areas of knowledge) and the ability + to effectively make use of equipment in an attack. The + weaker the attacker's expertise, the lower the potential + to use equipment (IT hardware/software or other + equipment). Likewise, the greater the expertise, the + greater the potential for equipment to be used in the + attack. Although implicit, this relationship between + expertise and the use of equipment does not always + apply, for instance, when environmental measures prevent + an expert attacker's use of equipment, or when, through + the efforts of others, attack tools requiring little + expertise to be effectively used are created and freely + distributed (e.g. via the Internet). + + + + Table identifies the + factors discussed in the previous section and associates + numeric values with the total value of each factor. + + Where a factor falls close to the boundary of a range the + evaluator should consider use of an intermediate value to those + in the table. For example, if twenty samples are required to + perform the attack then a value between one and four may be + selected for that factor, or if the design is based on a + publicly available design but the developer has made some + alterations then a value between zero and three should be + selected according to the evaluator's view of the impact of + those design changes. The table is intended as a guide. + + The ``**'' specification in the table in considering + Window of Opportunity is not + to be seen as a natural progression from the timescales + specified in the preceding ranges associated with this + factor. This specification identifies that for a + particular reason the potential vulnerability cannot be + exploited in the TOE in its intended operational + environment. For example, access to the TOE may be + detected after a certain amount of time in a TOE with a + known environment (i.e. in the case of a system) where + regular patrols are completed, and the attacker could not + gain access to the TOE for the required two weeks + undetected. However, this would not be applicable to a TOE + connected to the network where remote access is possible, + or where the physical environment of the TOE is + unknown. + + + + + + Factor + + + Value + + + + + + + Elapsed Time + + + + + + <= one day + + 0 + + + + <= one week + + 1 + + + + <= two weeks + + 2 + + + + <= one month + + 4 + + + + <= two months + + 7 + + + + <= three months + + 10 + + + + <= four months + + 13 + + + + <= five months + + 15 + + + + <= six months + + 17 + + + + > six months + + 19 + + + + Expertise + + + + + + Layman + + 0 + + + + Proficient + + + 3*When several proficient persons are + required to complete the attack path, the + resulting level of expertise still remains + ``proficient'' (which leads to a 3 + rating). + + + + Expert + + 6 + + + + Multiple experts + + 8 + + + + Knowledge of TOE + + + + + + Public + + 0 + + + + Restricted + + 3 + + + + Sensitive + + 7 + + + + Critical + + 11 + + + + Window of Opportunity + + + + + + Unnecessary / unlimited access + + 0 + + + + Easy + + 1 + + + + Moderate + + 4 + + + + Difficult + + 10 + + + + None + + + **Indicates that the attack path is not + exploitable due to other measures in the + intended operational environment of the + TOE. + + + + + Equipment + + + + + + Standard + + 0 + + + + Specialised + + 4If clearly different test benches + consisting of specialised equipment are required + for distinct steps of an attack, this should be + rated as bespoke. + + + + Bespoke + + 7 + + + + Multiple bespoke + + 9 + + + + + Calculation of attack potential +
+ + To determine the resistance of the TOE to the potential + vulnerabilities identified the following steps should be + applied: + + + Define the possible attack scenarios {AS1, AS2, ..., + ASn} for the TOE in the operational + environment. + + For each attack scenario, perform a theoretical + analysis and calculate the relevant attack potential + using Table . + + For each attack scenario, if necessary, perform + penetration tests in order to confirm or to disprove + the theoretical analysis. + + Divide all attack scenarios {AS1, AS2, ..., ASn} into + two groups: + + + the attack scenarios having been successful + (i.e. those that have been used to successfully + undermine the SFRs), and + + the attack scenarios that have been demonstrated + to be unsuccessful. + + + + For each successful attack scenario, apply Table and determine, whether + there is a contradiction between the resistance of the + TOE and the chosen + assurance component, see the last column of Table . + + Should one contradiction be found, the vulnerability + assessment will fail, e.g. the author of the ST chose + the component and an + attack scenario with an attack potential of 21 points + (high) has broken the security of the TOE. In this + case the TOE is resistant to attacker with attack + potential 'Moderate', this contradicts to , hence, the vulnerability + assessment fails. + + The ``Values'' column of Table indicates the range of attack potential values + (calculated using Table ) of an + attack scenario that results in the SFRs being + undermined. + + + + + + Values + + + Attack potential required to exploit scenario: + + + TOE resistant to attackers with attack potential + of: + + + Meets assurance components:: + + + Failure of components: + + + + + + + 0-9 + + Basic + + No rating + + - + + , , , , + + + + + 10-13 + + Enhanced-Basic + + Basic + + , + + , , + + + + 14-19 + + Moderate + + Enhanced-Basic + + , , + + , + + + + 20-24 + + High + + Moderate + + , , , + + + + + + =>25 + + Beyond High + + High + + , , , , + + + - + + + + Rating of vulnerabilities and TOE + resistance +
+ + An approach such as this cannot take account of every + circumstance or factor, but should give a better + indication of the level of resistance to attack required + to achieve the standard ratings. Other factors, such as + the reliance on unlikely chance occurrences are not + included in the basic model, but can be used by an + evaluator as justification for a rating other than those + that the basic model might indicate. + + It should be noted that whereas a number of + vulnerabilities rated individually may indicate high + resistance to attack, collectively the combination of + vulnerabilities may indicate that overall a lower rating + is applicable. The presence of one vulnerability may make + another easier to exploit. + + If a PP/ST author wants to use the attack potential table for + the determination of the level of attack the TOE should + withstand (selection of Vulnerability analysis () component), he should proceed as + follows: For all different attack scenarios (i.e. for all + different types of attacker and/or different types of attack the + author has in mind) which must not violate the SFRs, several + passes through Table should be + made to determine the different values of attack potential + assumed for each such unsuccessful attack scenario. The PP/ST + author then chooses the highest value of them in order to + determine the level of the TOE resistance to be claimed from + Table : the TOE resistance must + be at least equal to this highest value determined. For + example, the highest value of attack potentials of all attack + scenarios, which must not undermine the TOE security policy, + determined in such a way is Moderate; hence, the TOE resistance + shall be at least Moderate (i.e. Moderate or High); therefore, + the PP/ST author can choose either (for Moderate) or + (for High) as the appropriate assurance component. + + + + + + + + Mechanisms subject to direct attack are often vital for system + security and developers often strengthen these mechanisms. As + an example, a TOE might use a simple pass number + authentication mechanism that can be overcome by an attacker + who has the opportunity to repeatedly guess another user's + pass number. The system can strengthen this mechanism by + restricting pass numbers and their use in various ways. During + the course of the evaluation an analysis of this direct attack + could proceed as follows: + + Information gleaned from the ST and design evidence reveals + that identification and authentication provides the basis upon + which to control access to network resources from widely + distributed terminals. Physical access to the terminals is not + controlled by any effective means. The duration of access to a + terminal is not controlled by any effective means. Authorised + users of the system choose their own pass numbers when + initially authorised to use the system, and thereafter upon + user request. The system places the following restrictions on + the pass numbers selected by the user: + + + the pass number must be at least four and no greater than + six digits long; + + + consecutive numerical sequences are disallowed (such as + 7,6,5,4,3); + + + repeating digits is disallowed (each digit must be + unique). + + + + Guidance provided to the users at the time of pass number + selection is that pass numbers should be as random as possible + and should not be affiliated with the user in some way - a + date of birth, for instance. + + The pass number space is calculated as follows: + + + Patterns of human usage are important considerations that + can influence the approach to searching a password + space. Assuming the worst case scenario and the user + chooses a number comprising only four digits, the number + of pass number permutations assuming that each digit must + be unique is: + + + The number of possible increasing sequences is seven, as + is the number of decreasing sequences. The pass number + space after disallowing sequences is: + + + + Based on further information gleaned from the design evidence, + the pass number mechanism is designed with a terminal locking + feature. Upon the sixth failed authentication attempt the + terminal is locked for one hour. The failed authentication + count is reset after five minutes so that an attacker can at + best attempt five pass number entries every five minutes, or + 60 pass number entries every hour. + + On average, an attacker would have to enter 2513 pass numbers, + over 2513 minutes, before entering the correct pass number. The + average successful attack would, as a result, occur in slightly + less than: + + Using the approach to calculate the attack potential, described + in the previous section, identifies that it is possible that a + layman can defeat the mechanism within days (given easy access + to the TOE), with the use of standard equipment, and with no + knowledge of the TOE, giving a value of 1. Given the resulting + sum, 1, the attack potential required to effect a successful + attack is not rated, as it falls below that considered to be + Basic. + + + + + Table describes the + relationship between the composition assurance levels and the + assurance classes, families and components. + + + + The Composed Assurance Packages (CAPs) provide an increasing + scale that balances the level of assurance obtained with the + cost and feasibility of acquiring that degree of assurance for + composed TOEs. + + It is important to note that there are only a small number of + families and components from CC Part 3 included in the + CAPs. This is due to their nature of building upon evaluation + results of previously evaluated entities (base components and + dependent components), and is not to say that these do not + provide meaningful and desirable assurances. + + + CAPs are to be applied to composed TOEs, which are comprised + of components that have been (are going through) component TOE + evaluation (see ). The + individual components will have been certified to an EAL or + another assurance package specified in the ST. It is expected + that a basic level of assurance in a composed TOE will be + gained through application of EAL1, which can be achieved with + information about the components that is generally available + in the public domain. (EAL1 can be applied as specified + within to both component and composed TOEs.) CAPs provide an + alternative approach to obtaining higher levels of assurance + for a composed TOE than application of the EALs above + EAL1. + + While a dependent component can be evaluated using a + previously evaluated and certified base component to satisfy + the IT platform requirements in the environment, this does not + provide any formal assurance of the interactions between the + components or the possible introduction of vulnerabilities + resulting from the composition. Composed assurance packages + consider these interactions and, at higher levels of + assurance, ensure that the interface between the components + has itself been the subject of testing. A vulnerability + analysis of the composed TOE is also performed to consider the + possible introduction of vulnerabilities as a result of + composing the components. + + Table represents a summary + of the CAPs. The columns represent a hierarchically ordered + set of CAPs, while the rows represent assurance families. Each + number in the resulting matrix identifies a specific assurance + component where applicable. + + As outlined in the next Subclause, three hierarchically + ordered composed assurance packages are defined in the CC for + the rating of a composed TOE's assurance. They are + hierarchically ordered inasmuch as each CAP represents more + assurance than all lower CAPs. The increase in assurance from + CAP to CAP 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 increases result in + greater analysis of the composition to identify the impact on + the evaluation results gained for the individual component + TOEs. + + These CAPs consist of an appropriate combination of assurance + components as described in Clause of this CC Part 3. More + precisely, each CAP includes no more than one component of + each assurance family and all assurance dependencies of every + component are addressed. + + The CAPs only consider resistance against an attacker with an + attack potential up to Enhanced-Basic. This is due to the level + of design information that can be provided through the , limiting some of the factors + associated with attack potential (knowledge of the composed TOE) + and subsequently affecting the rigour of vulnerability analysis + that can be performed by the evaluator. Therefore, the level of + assurance in the composed TOE is limited, although the assurance + in the individual components within the composed TOE may be much + higher. +
+ + + + The following Subclauses provide definitions of the CAPs, + highlighting differences between the specific requirements and + the prose characterisations of those requirements using bold + type. + + + + + + Unlike the CC, where each element maintains the last digit of + its identifying symbol for all components within the family, + the CEM may introduce new work units when a CC evaluator + action element changes from sub-activity to sub-activity; as a + result, the last digit of the work unit's identifying symbol + may change although the work unit remains unchanged. + + Any methodology-specific evaluation work required that is not + derived directly from CC requirements is termed + task or sub-task. + + + + All work unit and sub-task verbs are preceded by the auxiliary + verb shall and by presenting both the verb + and the shall in + + bold italic type face. The + auxiliary verb shall is used only when the + provided text is mandatory and therefore only within the work + units and sub-tasks. The work units and sub-tasks contain + mandatory activities that the evaluator must perform in order + to assign verdicts. + + Guidance text accompanying work units and sub-tasks gives + further explanation on how to apply the CC words in an + evaluation. The verb usage is in accordance with ISO + definitions for these verbs. The auxiliary verb + should is used when the described method is + strongly preferred. All other auxiliary verbs, including + may, are used where the described method(s) + is allowed but is neither recommended nor strongly preferred; + it is merely explanation. + + The verbs check, examine, + report and record are used + with a precise meaning within this part of the CEM and the + Clause should be + referenced for their definitions. + + + + Material that has applicability to more than one sub-activity + is collected in one place. Guidance whose applicability is + widespread (across activities and EALs) has been collected + into . Guidance that + pertains to multiple sub-activities within a single activity + has been provided in the introduction to that activity. If + guidance pertains to only a single sub-activity, it is + presented within that sub-activity. + + + + There are direct relationships between the CC structure + (i.e. class, family, component and element) and the structure + of the CEM. Figure illustrates the correspondence + between the CC constructs of class, family and evaluator + action elements and CEM activities, sub-activities and + actions. However, several CEM work units may result from the + requirements noted in CC developer action and content and + presentation elements.
+ + + + For the purposes of this document, the following terms and + definitions apply. + Terms which are presented in bold-faced type are themselves + defined in this Subclause. + action + + evaluator action element of the CC Part 3 + + These actions are either explicitly stated as evaluator + actions or implicitly derived from developer actions (implied + evaluator actions) within the CC Part 3 assurance components. + + activity + + application of an assurance class of the CC Part 3 + + check + + generate a verdict by a simple comparison + + Evaluator expertise is not required. The statement + that uses this verb describes what is mapped. + + evaluation deliverable + + any resource required from the sponsor or developer by the + evaluator or evaluation authority to perform one or more evaluation or + evaluation oversight activities + + evaluation evidence + tangible evaluation deliverable + evaluation technical report + + report that documents the overall verdict and its + justification, produced by the evaluator and submitted to an + evaluation authority + examine + + generate a verdict by analysis using + evaluator expertise + + The statement that uses this verb identifies what is analysed + and the properties for which it is analysed. + + interpretation + clarification or amplification of a CC, CEM or + scheme requirement + methodology + + system of principles, procedures and processes applied to IT + security evaluations + + observation report + + report written by the evaluator requesting a clarification + or identifying a problem during the evaluation + + overall verdict + pass or fail statement issued by an + evaluator with respect to the result of an + evaluation + + oversight verdict + + statement issued by an evaluation authority confirming or + rejecting an overall verdict based on the + results of evaluation oversight activities + + record + + retain a written description of procedures, events, + observations, insights and results in sufficient detail to + enable the work performed during the evaluation to be + reconstructed at a later time + + report + + include evaluation results and supporting material in the + Evaluation Technical Report or an + Observation Report + scheme + + set of rules, established by an evaluation authority, + defining the evaluation environment, including criteria and + methodology required to conduct IT security + evaluations + + sub-activity + + application of an assurance component of the CC Part 3 + + Assurance families are not explicitly addressed in the CEM + because evaluations are conducted on a single assurance + component from an assurance family. + + tracing + + simple directional relation between two sets of + entities, which shows which entities in the first set + correspond to which entities in the second + + verdict + pass, fail or inconclusive statement issued + by an evaluator with respect to a CC evaluator action element, + assurance component, or class + + Also see overall verdict. + + work unit + + most granular level of evaluation work + + Each CEM action comprises one or more work units, which are + grouped within the CEM action by CC content and presentation + of evidence or developer action element. The work units are + presented in the CEM in the same order as the CC elements + from which they are derived. Work units are identified in + the left margin by a symbol such as . In this symbol, the + string + indicates the CC component (i.e. the CEM sub-activity), and + the final digit (2) indicates that this is + the second work unit in the + sub-activity. + + + + The target audience for the Common Methodology for Information + Technology Security Evaluation (CEM) is primarily evaluators + applying the CC and certifiers confirming evaluator actions; + evaluation sponsors, developers, PP/ST authors and other parties + interested in IT security may be a secondary audience. + + The CEM recognises that not all questions concerning IT security + evaluation will be answered herein and that further + interpretations will be needed. Individual schemes will + determine how to handle such interpretations, although these may + be subject to mutual recognition agreements. A list of + methodology-related activities that may be handled by individual + schemes can be found in . + + + + + Clause defines the + conventions used in the CEM. + + Clause + describes general evaluation tasks with no verdicts associated + with them as they do not map to CC evaluator action + elements. + + Clause addresses the work + necessary for reaching an evaluation result on a PP. + + Clauses to define the evaluation activities, organised by + Assurance Classes. + + covers the basic + evaluation techniques used to provide technical evidence of + evaluation results. + + provides an explanation + of the Vulnerability Analysis criteria and examples of their + application + + + + + The following referenced documents are indispensable for the + application of this document. For dated references, only the + edition cited applies. For undated references, the latest + edition of the referenced document (including any amendments) + applies. + + CC + + Common Criteria for Information Technology Security + Evaluation, Version _CCVERSION_, revision _CCREVISION_, + _CCDATE_. + + + + + + The Common Methodology for Information Technology Security + Evaluation (CEM) is a companion document to the Common Criteria + for Information Technology Security Evaluation (CC). The CEM + defines the minimum actions to be performed by an evaluator in + order to conduct a CC evaluation, using the criteria and + evaluation evidence defined in the CC. + The CEM does not define evaluator actions for certain high + assurance CC components, where there is as yet no generally + agreed guidance. + + + + CEM + + Common Methodology for Information Technology Security + Evaluation + + + + ETR + + Evaluation Technical Report + + + + OR + + Observation Report + + + + + + + Table describes the + relationship between the evaluation assurance levels and the + assurance classes, families and components.
+ + + + 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. + + + Table 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 Subclause, 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 Clause of this CC Part 3. More + precisely, each EAL includes no more than one 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. +
+ + + + The following Subclauses provide definitions of the EALs, + highlighting differences between the specific requirements and + the prose characterisations of those requirements using bold + type. + + + + + + The objective of this clause is to cover general guidance + used to provide technical evidence of evaluation results. The + use of such general guidance helps in achieving objectivity, + repeatability and reproducibility of the work performed by the + evaluator. + + + + This Subclause provides general guidance on sampling. Specific + and detailed information is given in those work units under + the specific evaluator action elements where sampling has to + be performed. + + Sampling is a defined procedure of an evaluator whereby some + subset of a required set of evaluation evidence is examined + and assumed to be representative for the entire set. It allows + the evaluator to gain enough confidence in the correctness of + particular evaluation evidence without analysing the whole + evidence. The reason for sampling is to conserve resources + while maintaining an adequate level of assurance. Sampling of + the evidence can provide two possible outcomes: + + + The subset reveals no errors, allowing the evaluator to + have some confidence that the entire set is correct. + + + The subset reveals errors and therefore the validity of + the entire set is called into question. Even the + resolution of all errors that were found may be + insufficient to provide the evaluator the necessary + confidence and as a result the evaluator may have to + increase the size of the subset, or stop using sampling + for this particular evidence. + + + + Sampling is a technique which can be used to reach a reliable + conclusion if a set of evidence is relatively homogeneous in + nature, e.g. if the evidence has been produced during a well + defined process. + + Sampling in the cases identified in the CC, and in cases + specifically covered in CEM work items, is recognised as a + cost-effective approach to performing evaluator + actions. Sampling in other areas is permitted only in + exceptional cases, where performance of a particular activity + in its entirety would require effort disproportionate to the + other evaluation activities, and where this would not add + correspondingly to assurance. In such cases a rationale for + the use of sampling in that area will need to be made. Neither + the fact that the TOE is large and complex, nor that it has + many security functional requirements, is sufficient + justification, since evaluations of large, complex TOEs can be + expected to require more effort. Rather it is intended that + this exception be limited to cases such as that where the TOE + development approach yields large quantities of material for a + particular CC requirement that would normally all need to be + checked or examined, and where such an action would not be + expected to raise assurance correspondingly. + + Sampling needs to be justified taking into account the + possible impact on the security objectives and threats of the + TOE. The impact depends on what might be missed as a result of + sampling. Consideration also needs to be given to the nature + of the evidence to be sampled, and the requirement not to + diminish or ignore any security functions. + + It should be recognised that sampling of evidence directly + related to the implementation of the TOE (e.g. developer test + results) requires a different approach to sampling, then + sampling related to the determination of whether a process is + being followed. In many cases the evaluator is required to + determine that a process is being followed, and a sampling + strategy is recommended. The approach for sampling a + developer's test results will differ. This is because the + former case is concerned with ensuring that a process is in + place, and the latter deals with determining correct + implementation of the TOE. Typically, larger sample sizes + should be analysed in cases related to the correct + implementation of the TOE than would be necessary to ensure + that a process is in place. + + In certain cases it may be appropriate for the evaluator to + give greater emphasis to the repetition of developer + testing. For example if the independent tests left for the + evaluator to perform would be only superficially different + from those included in an extensive developer test set + (possibly because the developer has performed more testing + than necessary to satisfy the + and criteria) then it would + be appropriate for the evaluator to give greater focus to the + repetition of developer tests. Note that this does not + necessarily imply a requirement for a high percentage sample + for repetition of developer tests; indeed, given an extensive + developer test set, the evaluator may be able to justify a low + percentage sample. + + Where the developer has used an automated test suite to + perform functional testing, it will usually be easier for the + evaluator to re-run the entire test suite rather than repeat + only a sample of developer tests. However the evaluator does + have an obligation to check that the automatic testing does + not give misrepresentative results. The implication is thus + that this check must be performed for a sample of the + automatic test suite, with the principles for selecting some + tests in preference to others and ensuring a sufficient sample + size applying equally in this case. + + The following principles should be followed whenever sampling + is performed: + + + Sampling should not be random, rather it should be chosen + such that it is representative of all of the evidence. The + sample size and composition must always be justified. + + + When sampling relates to the correct implementation of the + TOE, the sample should be representative of all aspects + relevant to the areas that are sampled. In particular, the + selection should cover a variety of components, + interfaces, developer and operational sites (if more than + one is involved) and hardware platform types (if more than + one is involved). The sample size should be commensurate + with the cost effectiveness of the evaluation and will + depend on a number of TOE dependent factors (e.g. the size + and complexity of the TOE, the amount of documentation). + + + Also, when sampling relates to specifically gaining + evidence that the developer testing is repeatable and + reproducible the sample used must be sufficient to + represent all distinct aspects of developer testing, such + as different test regimes. The sample used must be + sufficient to detect any systematic problem in the + developer's functional testing process. The evaluator + contribution resulting from the combination of repeating + developer tests and performing independent tests must be + sufficient to address the major points of concern for the + TOE. + + + Where sampling relates to gaining evidence that a process + (e.g. visitor control or design review) the evaluator + should sample sufficient information to gain reasonable + confidence that the procedure is being followed. + + + The sponsor and developer should not be informed in + advance of the exact composition of the sample, subject to + ensuring timely delivery of the sample and supporting + deliverable, e.g. test harnesses and equipment to the + evaluator in accordance with the evaluation schedule. + + + The choice of the sample should be free from bias to the + degree possible (one should not always choose the first or + last item). Ideally the sample selection should be done by + someone other than the evaluator. + + + + Errors found in the sample can be categorised as being either + systematic or sporadic. If the error is systematic, the + problem should be corrected and a complete new sample + taken. If properly explained, sporadic errors might be solved + without the need for a new sample, although the explanation + should be confirmed. The evaluator should use judgement in + determining whether to increase the sample size or use a + different sample. + + + + In general it is possible to perform the required evaluation + activities, sub-activities, and actions in any order or in + parallel. However, there are different kinds of dependencies + which have to be considered by the evaluator. This Subclause + provides general guidance on dependencies between different + activities, sub-activities, and actions. + + + For some cases the different assurance classes may recommend + or even require a sequence for the related activities. A + specific instance is the ST activity. The ST evaluation + activity is started prior to any TOE evaluation activities + since the ST provides the basis and context to perform + them. However, a final verdict on the ST evaluation may not + be possible until the TOE evaluation is complete, since + changes to the ST may result from activity findings during + the TOE evaluation. + + + + Dependencies identified between components in CC Part 3 have + to be considered by the evaluator. Most dependencies are + one way, e.g. claims a + dependency on and . There are also instances of + mutual dependencies, where both components depend on each + other. An example of this is and . + + A sub-activity can be assigned a pass verdict normally only + if all those sub-activities are successfully completed on + which it has a one-way dependency. For example, a pass + verdict on can normally + only be assigned if the sub-activities related to and are assigned a pass verdict too. In the case + of mutual dependency the ordering of these components is + down to the evaluator deciding which sub-activity to perform + first. Note this indicates that pass verdicts can normally + only be assigned once both sub-activities have been + successful. + + So when determining whether a sub-activity will impact + another sub-activity, the evaluator should consider whether + this activity depends on potential evaluation results from + any dependent sub-activities. Indeed, it may be the case + that a dependent sub-activity will impact this sub-activity, + requiring previously completed evaluator actions to be + performed again. + + A significant dependency effect occurs in the case of + evaluator-detected flaws. If a flaw is identified as a + result of conducting one sub-activity, the assignment of a + pass verdict to a dependent sub-activity may not be possible + until all flaws related to the sub-activity upon which it + depends are resolved. + + + + It may be the case, that results which are generated by the + evaluator during one action are used for performing another + action. For example, actions for completeness and + consistency cannot be completed until the checks for content + and presentation have been completed. This means for example + that the evaluator is recommended to evaluate the PP/ST + rationale after evaluating the constituent parts of the + PP/ST. + + + + + + The assurance class includes + requirements for + + + the application of configuration management, ensuring + that the integrity of the TOE is preserved; + + + measures, procedures, and standards concerned with + secure delivery of the TOE, ensuring that the security + protection offered by the TOE is not compromised during + the transfer to the user, + + + security measures, used to protect the development + environment. + + + + A development site visit is a useful means whereby the + evaluator determines whether procedures are being followed + in a manner consistent with that described in the + documentation. + + Reasons for visiting sites include: + + + to observe the use of the CM system as described in the + CM plan; + + + to observe the practical application of delivery + procedures as described in the delivery documentation; + + + to observe the application of security measures during + development and maintenance of the TOE as described in + the development security documentation. + + + + Specific and detailed information is given in work units for + those activities where site visits are performed: + + + .n with n>=3 + (especially work unit = = ); + + + (especially work unit + ); + + + (especially work unit + = ). + + + + + + During an evaluation it is often necessary that the + evaluator will meet the developer more than once and it is a + question of good planning to combine the site visit with + another meeting to reduce costs. For example one might + combine the site visits for configuration management, for + the developer's security and for delivery. It may also be + necessary to perform more than one site visit to the same + site to allow the checking of all development phases. It + should be considered that development could occur at + multiple facilities within a single building, multiple + buildings at the same site, or at multiple sites. + + The first site visit should be scheduled early during the + evaluation. In the case of an evaluation which starts during + the development phase of the TOE, this will allow corrective + actions to be taken, if necessary. In the case of an + evaluation which starts after the development of the TOE, an + early site visit could allow corrective measures to be put + in place if serious deficiencies in the applied procedures + emerge. This avoids unnecessary evaluation effort. + + Interviews are also a useful means of determining whether the + written procedures reflect what is done. In conducting such + interviews, the evaluator aims to gain a deeper understanding of + the analysed procedures at the development site, how they are + used in practise and whether they are being applied as described + in the provided evaluation evidence. Such interviews complement + but do not replace the examination of evaluation + evidence. + + As a first step preparing the site visits the evaluators + should perform the evaluator work units concerning the + assurance class excluding the + aspects describing the results of the site visit. Based on + the information provided by the relevant developer + documentation and the remaining open questions which were + not answered by the documentation the evaluators compile a + check list of the questions which are to be resolved by the + site visits. + + The first version of the evaluation report concerning the + class and the check list serves + as input for the consultation with the evaluation authority + concerning the site visits. + + The check list serve as a guide line for the site visits, + which questions are to be answered by inspection of the + relevant measures, their application and results, and by + interviews. Where appropriate, sampling is used for gaining + the required level of confidence (see Subclause ). + + The results of the site visits are recorded and serve as + input for the final version of the evaluation report + concerning the assurance class . + + Other approaches to gain confidence should be considered + that provide an equivalent level of assurance (e.g. to + analyse evaluation evidence). Any decision not to make a + visit should be determined in consultation with the + evaluation authority. Appropriate security criteria and a + methodology should be based on other standards of the + Information Security Management Systems area. + + + + In the following some keywords are provided, which topics + should be checked during an audit. + + Basic + + + Items of the configuration list, including TOE, source + code, run time libraries, design documentation, + development tools (). + + + Tracking of design documentation, source code, user + guidance to different versions of the TOE. + + + Integration of the configuration system in the design + and development process, test planning, test analysis + and quality management procedures. + + + + Test analysis + + + Tracking of test plans and results to specific + configurations and versions of the TOE. + + + + Access control to development systems + + + Policies for access control and logging. + + + Policies for project specific assignment and changing + of access rights. + + + + Clearance + + + Policies for clearance of the TOE and user guidance to + the customer. + + + Policies for testing and approving of components and + the TOE before deployment. + + + + + + Infrastructure + + + Security measures for physical access control to the + development site and rationale for the effectiveness + of these measures. + + + + Organisational measures + + + Organisational structure of the company in respect of + the security of the development environment. + + + Organisational separation between development, + production, testing and quality assurance. + + + + Personal measures + + + Measures for education of the personnel in respect of + development security. + + + Measures and legal agreements of non disclosure of + internal information. + + + + Access control + + + Assignment of secured objects (for instance TOE, + source code, run time libraries, design documentation, + development tools, user guidance) and security + policies. + + + Policies and responsibilities concerning the access + control and the handling of authentication + information. + + + Policies for logging of any kind access to the + development site and protection of the logging data. + + + + Input, processing and output of data + + + Security measures for protection of output and output + devices (printer, plotter and displays). + + + Securing of local networks and communication + connections. + + + + Storage, transfer and destruction of documents and data + media. + + + Policies for handling of documents and data media. + + + Policies and responsibilities for destruction of + sorted out documents and logging of these events. + + + + Data protection + + + Policies and responsibilities for data and information + protection (e.g. for performing backups). + + + + Contingency plan + + + Practises in case of emergency and responsibilities. + + + Documentation of the contingency measures concerning + access control. + + + Information of the personnel about applicable + practises in extreme cases. protection (e.g. for + performing backups). + + + + + + + The examples of checklists for site visits consist in tables + for the preparation of an audit and for the presentation of + the results of an audit. + + The checklist structure given in the following is + preliminary. Dependent on the concrete contents of the new + guideline, changes might become necessary. + The checklist is divided into three subclauses according + to the subjects indicated in the introduction (Subclause ). + + + Configuration management system. + + + Delivery procedures. + + + Security measures during development. + + + These subclauses correspond to the actual CC class , especially the families .n with n>=3, and . + The subclauses are subdivided further into rows + corresponding to the relevant work units of the CEM. + + The columns of the checklist contain in turn + + + a consecutive number, + + + the referenced work unit, + + + the references to the corresponding developer + documentation, + + + the explicit reproduction of the developer measures, + + + special remarks and questions to be clarified on the + visit (beyond the standard evaluator task to verify the + application of the indicated measures), + + + the result of the examinations during the visit. + + + If it is decided to have separate checklists for + preparation and reporting of the audit, the result column is + omitted in the preparation list and the remarks and + questions column is omitted in the reporting list. The + remaining columns should be identical in both lists. +
+ + Example of a checklist at EAL 4 (extract) + + + + + + A. Examination of the CM system ( and ) + + + + + No. + + + Work Unit + + + Developer Documentation + + + Measures + + + Questions and Remarks + + + Result + + + + + + + A.1 + + + , + + + + ``Configuration Management System'', ch. ... + + + The system automatically managing the source code + files is capable of administering user profiles and + graded access rights, and of checking identification + and authentication of users. + + + Does reading or updating of a source code file + require a user authentication? + + + If a user has not the right to access a confidential + document, it is not even displayed to him in the + file list. + + + + + ... + + + ... + + + ... + + + ... + + + ... + + + ... + + + + + + + + + B. Examination of the Delivery Procedures () + + + + + No. + + + Work Unit + + + Developer Documentation + + + Measures + + + Questions and Remarks + + + Result + + + + + + + B.1 + + + , + + + + ``Delivery of the TOE'', ch. ... + + + The software is transmitted PGP-signed and encrypted + to the customer. + + + --- + + + The evaluators have checked the process and found it + as described, additionally a checksum is + transmitted. + + + + + ... + + + ... + + + ... + + + ... + + + ... + + + ... + + + + + + + + + C. Examination of the organisational and + infrastructural developer security + (, + , + ) + + + + + No. + + + Work Unit + + + Developer Documentation + + + Measures + + + Questions and Remarks + + + Result + + + + + + + C.1 + + + , + + + + ``Security of the development environment'', + ch. ... (Premises) + + + The premises are protected by security fencing. + + + Is the fencing sufficiently strong and high to + prevent an easy intrusion into the premises? + + + The evaluators considered the fencing to be + sufficiently strong and high. + + + + + C.2 + + + , + + + + ``Security of the development environment'', + ch. ... (Building) + + + The building has the following access possibilities: + The main entrance which is surveyed by the reception + and is closed if the reception is not manned. And an + access in the goods reception which is secured by + two roller shutters. + + + Is the listing of the access possibilities complete? + + + Beyond the indicated access possibilities, there is + an emergency exit that cannot be opened from the + outside. The roller shutters mentioned before can be + operated only from inside. + + + + + ... + + + ... + + + ... + + + ... + + + ... + + + ... + + + + +
+ + + + + This CEM describes the minimum technical work that evaluations + conducted under oversight (scheme) bodies must + perform. However, it also recognises (both explicitly and + implicitly) that there are activities or methods upon which + mutual recognition of evaluation results do not rely. For the + purposes of thoroughness and clarity, and to better delineate + where the CEM ends and an individual scheme's methodology + begins, the following matters are left up to the discretion of + the schemes. Schemes may choose to provide the following, + although they may choose to leave some unspecified. (Every + effort has been made to ensure this list is complete; + evaluators encountering a subject neither listed here nor + addressed in the CEM should consult with their evaluation + schemes to determine under whose auspices the subject + falls.) + + The matters that schemes may choose to specify include: + + + what is required in ensuring that an evaluation was done + sufficiently - every scheme has a means of verifying the + technical competence, understanding of work and the work + of its evaluators, whether by requiring the evaluators to + present their findings to the oversight body, by requiring + the oversight body to redo the evaluator's work, or by + some other means that assures the scheme that all + evaluation bodies are adequate and comparable; + + + process for disposing of evaluation evidence upon + completion of an evaluation; + + + any requirements for confidentiality (on the part of the + evaluator and the non-disclosure of information obtained + during evaluation); + + + the course of action to be taken if a problem is + encountered during the evaluation (whether the evaluation + continues once the problem is remedied, or the evaluation + ends immediately and the remedied product must be + re-submitted for evaluation); + + + any specific (natural) language in which documentation + must be provided; + + + any recorded evidence that must be submitted in the ETR - + this CEM specifies the minimum to be reported in an ETR; + however, individual schemes may require additional + information to be included; + + + any additional reports (other than the ETR) required from + the evaluators -for example, testing reports; + + + any specific ORs that may be required by the scheme, + including the structure, recipients, etc. of any such ORs; + + + any specific content structure of any written report as a + result from an ST evaluation - a scheme may have a + specific format for all of its reports detailing results + of an evaluation, be it the evaluation of a TOE or of an + ST; + + + any additional PP/ST identification information required; + + + any activities to determine the suitability of + explicitly-stated requirements in an ST; + + + any requirements for provision of evaluator evidence to + support re-evaluation and re-use of evidence; + + + any specific handling of scheme identifiers, logos, + trademarks, etc.; + + + any specific guidance in dealing with cryptography; + + + handling and application of scheme, national and + international interpretations; + + + a list or characterisations of suitable alternative + approaches to testing where testing is infeasible; + + + the mechanism by which an evaluation authority can determine what + steps an evaluator took while testing; + + + preferred test approach (if any): at internal interface or + at external interface; + + + a list or characterisation of acceptable means of + conducting the evaluator's vulnerability analysis + (e.g. flaw hypothesis methodology); + + + information regarding any vulnerabilities and weaknesses + to be considered. + + + + + + + + The following annexes through provide the application notes for the functional + classes defined in the main body of this part of the CC. + + + For the purposes of this document, the terms, definitions, + symbols and abbreviated terms given in CC Part 1 apply. + + + Security functional components, as defined in this CC Part 2, are + the basis for the security functional requirements expressed in a + Protection Profile (PP) or a Security Target (ST). These + requirements describe the desired security behaviour expected of a + Target of Evaluation (TOE) and are intended to meet the security + objectives as stated in a PP or an ST. These requirements describe + security properties that users can detect by direct interaction + (i.e. inputs, outputs) with the IT or by the IT response to + stimulus. + + Security functional components express security requirements + intended to counter threats in the assumed operating environment + of the TOE and/or cover any identified organisational security + policies and assumptions. + + The audience for this CC Part 2 includes consumers, developers, + and evaluators of secure IT products. CC Part 1 + Chapter provides additional + information on the target audience of the CC, and on the use of + the CC by the groups that comprise the target audience. These + groups may use this part of the CC as follows: + + + Consumers, who use this CC Part 2 when selecting components to + express functional requirements to satisfy the security + objectives expressed in a PP or ST. CC Part 1 Section provides more detailed + information on the relationship between security objectives + and security requirements. + + + Developers, who respond to actual or perceived consumer + security requirements in constructing a TOE, may find a + standardised method to understand those requirements in this + part of the CC. They can also use the contents of this part of + the CC as a basis for further defining the TOE security + functionality and mechanisms that comply with those + requirements. + + + Evaluators, who use the functional requirements defined in + this part of the CC in verifying that the TOE functional + requirements expressed in the PP or ST satisfy the IT security + objectives and that all dependencies are accounted for and + shown to be satisfied. Evaluators also should use this part of + the CC to assist in determining whether a given TOE satisfies + stated requirements. + + + + + + The CC and the associated security functional requirements + described herein are not meant to be a definitive answer to all + the problems of IT security. Rather, the CC offers a set of well + understood security functional requirements that can be used to + create trusted products reflecting the needs of the market. These + security functional requirements are presented as the current + state of the art in requirements specification and + evaluation. + + This part of the CC does not presume to include all possible + security functional requirements but rather contains those that + are known and agreed to be of value by the CC Part 2 authors at + the time of release. + + Since the understanding and needs of consumers may change, the + functional requirements in this part of the CC will need to be + maintained. It is envisioned that some PP/ST authors may have + security needs not (yet) covered by the functional requirement + components in CC Part 2. In those cases the PP/ST author may + choose to consider using functional requirements not taken from + the CC (referred to as extensibility), as explained in annexes + and + of + CC Part 1. + + + + Clause + describes the paradigm used in the security functional + requirements of CC Part 2. + + Clause + introduces the catalogue of CC Part 2 functional components + while clauses through describe the functional classes. + + provides explanatory information for potential + users of the functional components including a complete cross + reference table of the functional component dependencies. + + through provide the explanatory information for the + functional classes. This material must be seen as normative + instructions on how to apply relevant operations and select + appropriate audit or documentation information; the use of the + auxiliary verb should means that the instruction is strongly + preferred, but others may be justifiable. Where different + options are given, the choice is left to the PP/ST + author. + + Those who author PPs or STs should refer to clause 2 of CC Part + 1 for relevant structures, rules, and guidance: + + + CC Part 1, clause + defines the terms used in the CC. + + + CC Part 1, annex defines the + structure for STs. + + + CC Part 1, annex defines the + structure for PPs. + + + + + + The following referenced documents are indispensable for the + application of this document. For dated references, only the + edition cited applies. For undated references, the latest edition + of the referenced document (including any amendments) applies.CC + Common Criteria for Information Technology Security + Evaluation, Version _CCVERSION_, revision _CCREVISION_, + _CCDATE_. Part 1: Introduction and general model. + + + This part of the CC defines the required structure and content + of security functional components for the purpose of security + evaluation. It includes a catalogue of functional components + that will meet the common security functionality requirements + of many IT products. + + + This chapter describes the paradigm used in the security + functional requirements of this part of the CC. Key concepts + discussed are highlighted in bold/italics. This section is not + intended to replace or supersede any of the terms found in CC Part + 1, chapter . + + This part of the CC is a catalogue of security functional + components that can be specified for a Target of + Evaluation (TOE). A TOE is a set of software, firmware + and/or hardware possibly accompanied by user and administrator + guidance documentation. A TOE may contain resources such as + electronic storage media (e.g. main memory, disk space), + peripheral devices (e.g. printers), and computing capacity (e.g. + CPU time) that can be used for processing and storing + information and is the subject of an evaluation. + + TOE evaluation is concerned primarily with ensuring that a defined + set of security functional requirements (SFRs) is + enforced over the TOE resources. The SFRs define the rules by + which the TOE governs access to and use of its resources, and thus + information and services controlled by the TOE. + + The SFRs may define multiple Security Function Policies + (SFPs) to represent the rules that the TOE must enforce. Each such SFP + must specify its scope of control, by defining the subjects, + objects, resources or information, and operations to which it applies. All + SFPs are implemented by the TSF (see below), whose mechanisms enforce the + rules defined in the SFRs and provide necessary capabilities. + + Those portions of a TOE that must be relied on for the correct + enforcement of the SFRs are collectively referred to as the + TOE Security Functionality (TSF). The TSF consists of + all hardware, software, and firmware of a TOE that is either + directly or indirectly relied upon for security enforcement. + + The TOE may be a monolithic product containing hardware, firmware, + and software. + + Alternatively a TOE may be a distributed product that consists + internally of multiple separated parts. Each of these parts of the + TOE provides a particular service for the TOE, and is connected to + the other parts of the TOE through an internal communication + channel. This channel can be as small as a processor bus, + or may encompass a network internal to the TOE. + + When the TOE consists of multiple parts, each part of the TOE may + have its own part of the TSF which exchanges user and TSF data + over internal communication channels with other parts of the + TSF. This interaction is called internal TOE + transfer. In this case the separate parts of the TSF + abstractly form the composite TSF, which enforces the SFRs. + + TOE interfaces may be localised to the particular TOE, or they may + allow interaction with other IT products over external + communication channels. These external interactions with + other IT products may take two forms: + + + The SFRs of the other ``trusted IT product'' and the SFRs of + the TOE have been administratively coordinated and the other + trusted IT product is assumed to enforce its SFRs correctly + (e. g. by being separately evaluated). Exchanges of + information in this situation are called inter-TSF + transfers, as they are between the TSFs of distinct + trusted products. + + + The other IT product may not be trusted, it may be called an + ``untrusted IT product''. Therefore its SFRs are either + unknown or their implementation is not viewed as + trustworthy. TSF mediated exchanges of information in this + situation are called transfers outside of the + TOE, as there is no TSF (or its policy characteristics + are unknown) on the other IT product. + + + The set of interfaces, whether interactive (man-machine + interface) or programmatic (application programming interface), + through which resources are accessed that are mediated by the TSF, + or information is obtained from the TSF, is referred to as the + TSF Interface (TSFI). The TSFI defines the boundaries + of the TOE functionality that provide for the enforcement of the + SFRs. + + Users are outside of the TOE. However, in order to request that + services be performed by the TOE that are subject to rules + defined in the SFRs, users interact with the TOE through the + TSFIs. There are two types of users of interest to CC Part 2: + human users and external IT + entities. Human users may further be differentiated as + local human users, meaning they interact directly + with the TOE via TOE devices (e.g. workstations), or + remote human users, meaning they interact + indirectly with the TOE through another IT product. + + A period of interaction between users and the TSF is referred to + as a user session. Establishment of user sessions can + be controlled based on a variety of considerations, for example: + user authentication, time of day, method of accessing the TOE, and + number of allowed concurrent sessions (per user or in total). + + This part of the CC uses the term authorised to + signify a user who possesses the rights and/or privileges + necessary to perform an operation. The term authorised + user, therefore, indicates that it is allowable for a user + to perform a specific operation or a set of operations as defined + by the SFRs. + + To express requirements that call for the separation of + administrator duties, the relevant security functional + components (from family ) + explicitly state that administrative roles are + required. A role is a pre-defined set of rules establishing the + allowed interactions between a user operating in that role and + the TOE. A TOE may support the definition of any number of + roles. For example, roles related to the secure operation of a + TOE may include ``Audit Administrator'' and ``User Accounts + Administrator''. + + TOEs contain resources that may be used for the + processing and storing of information. The primary goal of the TSF + is the complete and correct enforcement of the SFRs over the + resources and information that the TOE controls. + + TOE resources can be structured and utilised in many different + ways. However, CC Part 2 makes a specific distinction that allows + for the specification of desired security properties. All entities + that can be created from resources can be characterised in one of + two ways. The entities may be active, meaning that they are the + cause of actions that occur internal to the TOE and cause + operations to be performed on information. Alternatively, the + entities may be passive, meaning that they are either the + container from which information originates or to which + information is stored. + + Active entities in the TOE that perform operations on objects are + referred to as subjects. Several types of subjects + may exist within a TOE: + + + those acting on behalf of an authorised user (e.g. UNIX + processes); + + + those acting as a specific functional process that may in turn + act on behalf of multiple users (e.g. functions as might be + found in client/server architectures); or + + + those acting as part of the TOE itself (e.g. processes not + acting on behalf of a user). + + + + CC Part 2 addresses the enforcement of the SFRs over types of + subjects as those listed above. + + Passive entities in the TOE that contain or receive information + and upon which subjects perform operations are called + objects. In the case where a subject (an active + entity) is the target of an operation (e.g. interprocess + communication), a subject may also be acted on as an object. + + Objects can contain information. This concept is + required to specify information flow control policies as addressed + in the FDP class. + + Users, subjects, information, objects, sessions and resources + controlled by rules in the SFRs may possess certain + attributes that contain information that is used by + the TOE for its correct operation. Some attributes, such as file + names, may be intended to be informational or may be used to + identify individual resources while others, such as access control + information, may exist specifically for the enforcement of the + SFRs. These latter attributes are generally referred to as + ``security attributes''. The word attribute will be + used as a shorthand in some places of this part of the CC for the + word ``security attribute''. However, no matter what the intended + purpose of the attribute information, it may be necessary to have + controls on attributes as dictated by the SFRs. + + Data in a TOE is categorised as either user data or TSF + data. Figure depicts this + relationship. User Data is information stored in TOE + resources that can be operated upon by users in accordance with + the SFRs and upon which the TSF places no special meaning. For + example, the content of an electronic mail message is user + data. TSF Data is information used by the TSF in making decisions + as required by the SFRs. TSF Data may be influenced + by users if allowed by the SFRs. Security attributes, + authentication data, TSF internal status variables used by the + rules defined in the SFRs or used for the protection of the TSF + and access control list entries are examples of TSF data. + + There are several SFPs that apply to data protection such as + access control SFPs and information flow + control SFPs. The mechanisms that implement access control + SFPs base their policy decisions on attributes of the users, + resources, subjects, objects, sessions, TSF status data and + operations within the scope of control. These attributes are used + in the set of rules that govern operations that subjects may + perform on objects. + + The mechanisms that implement information flow control SFPs base + their policy decisions on the attributes of the subjects and + information within the scope of control and the set of rules that + govern the operations by subjects on information. The attributes + of the information, which may be associated with the attributes of + the container or may be derived from the data in the container, + stay with the information as it is processed by the TSF. +
+ + Two specific types of TSF data addressed by CC Part 2 can be, but + are not necessarily, the same. These are authentication + data and secrets. + + Authentication data is used to verify the claimed identity of a + user requesting services from a TOE. The most common form of + authentication data is the password, which depends on being kept + secret in order to be an effective security mechanism. However, + not all forms of authentication data need to be kept + secret. Biometric authentication devices (e.g. fingerprint + readers, retinal scanners) do not rely on the fact that the data + is kept secret, but rather that the data is something that only + one user possesses and that cannot be forged. + + The term secrets, as used in CC Part 2, while applicable to + authentication data, is intended to also be applicable to other + types of data that must be kept secret in order to enforce a + specific SFP. For example, a trusted channel mechanism that + relies on cryptography to preserve the confidentiality of + information being transmitted via the channel can only be as + strong as the method used to keep the cryptographic keys secret + from unauthorised disclosure. + + Therefore, some, but not all, authentication data needs to be kept + secret and some, but not all, secrets are used as authentication + data. Figure shows this relationship + between secrets and authentication data. In the Figure the types + of data typically encountered in the authentication data and the + secrets sections are indicated. +
+ + + + + This clause provides an overview of the evaluation process + and defines the tasks an evaluator is intended to perform when + conducting an evaluation. + + Each evaluation, whether of a PP or TOE (including ST), + follows the same process, and has four evaluator tasks in + common: the input task, the output task, the evaluation + sub-activities, and the demonstration of the technical + competence to the evaluation authority task. + + The input task and the output tasks, which are related to + management of evaluation evidence and to report generation, + are entirely described in this clause. Each task has + associated sub-tasks that apply to, and are normative for all + CC evaluations (evaluation of a PP or a TOE). + + The evaluation sub-activities are only introduced in this + clause, and fully described in the following clauses. + + In contrast to the evaluation sub-activities, input and output + tasks have no verdicts associated with them as they do not map + to CC evaluator action elements; they are performed in order + to ensure conformance with the universal principles and to + comply with the CEM. + + The demonstration of the technical competence to the + evaluation authority task may be fulfilled by the evaluation + authority analysis of the output tasks results, or may include + the demonstration by the evaluators of their understanding of + the inputs for the evaluation sub-activities. This task has no + associated evaluator verdict, but has an evaluator authority + verdict. The detailed criteria to pass this task are left to + the discretion of the evaluation authority, as noted in Annex + . + + + + + This subclause presents the general model of the methodology + and identifies: + + + roles and responsibilities of the parties involved in + the evaluation process; + + + the general evaluation model. + + + + + + The general model defines the following roles: sponsor, + developer, evaluator and evaluation authority. + + The sponsor is responsible for requesting and supporting an + evaluation. This means that the sponsor establishes the + different agreements for the evaluation (e.g. commissioning + the evaluation). Moreover, the sponsor is responsible for + ensuring that the evaluator is provided with the evaluation + evidence. + + The developer produces the TOE and is responsible for + providing the evidence required for the evaluation + (e.g. training, design information), on behalf of the + sponsor. + + The evaluator performs the evaluation tasks required in the + context of an evaluation: the evaluator receives the + evaluation evidence from the developer on behalf of the + sponsor or directly from the sponsor, performs the + evaluation sub-activities and provides the results of the + evaluation assessment to the evaluation authority. + + The evaluation authority establishes and maintains the + scheme, monitors the evaluation conducted by the evaluator, + and issues certification/validation reports as well as + certificates based on the evaluation results provided by the + evaluator. + + + + To prevent undue influence from improperly affecting an + evaluation, some separation of roles is required. This + implies that the roles described above are fulfilled by + different entities, except that the roles of developer and + sponsor may be satisfied by a single entity. + + Moreover, some evaluations (e.g. EAL1 evaluation) may not + require the developer to be involved in the project. In this + case, it is the sponsor who provides the TOE to the + evaluator and who generates the evaluation evidence. + + + + The evaluation process consists of the evaluator performing + the evaluation input task, the evaluation output task and + the evaluation sub-activities. Figure provides an overview of + the relationship between these tasks and + sub-activities. +
+ + The evaluation process may be preceded by a preparation + phase where initial contact is made between the sponsor and + the evaluator. The work that is performed and the + involvement of the different roles during this phase may + vary. It is typically during this step that the evaluator + performs a feasibility analysis to assess the likelihood of + a successful evaluation. + + + + The evaluator assigns verdicts to the requirements of the CC + and not to those of the CEM. The most granular CC structure + to which a verdict is assigned is the evaluator action + element (explicit or implied). A verdict is assigned to an + applicable CC evaluator action element as a result of + performing the corresponding CEM action and its constituent + work units. Finally, an evaluation result is assigned, as + described in CC Part 1, Clause . +
+ + The CEM recognises three mutually exclusive verdict states: + + + Conditions for a pass verdict are + defined as an evaluator completion of the CC evaluator + action element and determination that the requirements + for the PP, ST or TOE under evaluation are met. The + conditions for passing the element are defined as: + + + the constituent work units of the related CEM + action, and; + + + all evaluation evidence required for performing + these work units is coherent, that is it can be + fully and completely understood by the evaluator, + and + + + all evaluation evidence required for performing + these work units does not have any obvious internal + inconsistencies or inconsistencies with other + evaluation evidence. Note that obvious means here + that the evaluator discovers this inconsistency + while performing the work units: the evaluator + should not undertake a full consistency analysis + across the entire evaluation evidence every time a + work unit is performed. + + + + + Conditions for a fail verdict are + defined as an evaluator completion of the CC evaluator + action element and determination that the requirements + for the PP, ST, or TOE under evaluation are not met, or + that the evidence is incoherent, or an obvious + inconsistency in the evaluation evidence has been found; + + + All verdicts are initially inconclusive + and remain so until either a pass or + fail verdict is assigned. + + + + The overall verdict is pass if and only if + all the constituent verdicts are also + pass. In the example illustrated in Figure + , if the verdict for one + evaluator action element is fail then the + verdicts for the corresponding assurance component, + assurance class, and overall verdict are also + fail. + + + + + + The objective of this task is to ensure that the evaluator + has available the correct version of the evaluation evidence + necessary for the evaluation and that it is adequately + protected. Otherwise, the technical accuracy of the + evaluation cannot be assured, nor can it be assured that the + evaluation is being conducted in a way to provide repeatable + and reproducible results. + + + + The responsibility to provide all the required evaluation + evidence lies with the sponsor. However, most of the + evaluation evidence is likely to be produced and supplied by + the developer, on behalf of the sponsor. + + Since the assurance requirements apply to the entire TOE, + all evaluation evidence pertaining to all parts of the TOE + is to be made available to the evaluator. The scope and + required content of such evaluation evidence is independent + of the level of control that the developer has over each of + the parts of the TOE. For example, if design is required, + then the requirements will + apply to all subsystems that are part of the TSF. In + addition, assurance requirements that call for procedures to + be in place (for example, + and ) will also apply to the + entire TOE (including any part produced by another + developer). + + It is recommended that the evaluator, in conjunction with + the sponsor, produce an index to required evaluation + evidence. This index may be a set of references to the + documentation. This index should contain enough information + (e.g. a brief summary of each document, or at least an + explicit title, indication of the subclauses of interest) to + help the evaluator to find easily the required + evidence. + + It is the information contained in the evaluation evidence + that is required, not any particular document + structure. Evaluation evidence for a sub-activity may be + provided by separate documents, or a single document may + satisfy several of the input requirements of a + sub-activity. + + The evaluator requires stable and formally-issued versions + of evaluation evidence. However, draft evaluation evidence + may be provided during an evaluation, for example, to help + an evaluator make an early, informal assessment, but is not + used as the basis for verdicts. It may be helpful for the + evaluator to see draft versions of particular appropriate + evaluation evidence, such as: + + + test documentation, to allow the evaluator to make an + early assessment of tests and test procedures; + + + design documents, to provide the evaluator with + background for understanding the TOE design; + + + source code or hardware drawings, to allow the evaluator + to assess the application of the developer's standards. + + + + Draft evaluation evidence is more likely to be encountered + where the evaluation of a TOE is performed concurrently with + its development. However, it may also be encountered during + the evaluation of an already-developed TOE where the + developer has had to perform additional work to address a + problem identified by the evaluator (e.g. to correct an + error in design or implementation) or to provide evaluation + evidence of security that is not provided in the existing + documentation (e.g. in the case of a TOE not originally + developed to meet the requirements of the CC). + + + + + The evaluator shall perform configuration control of the + evaluation evidence. + + The CC implies that the evaluator is able to identify and + locate each item of evaluation evidence after it has been + received and is able to determine whether a specific + version of a document is in the evaluator's + possession. + + The evaluator shall protect the evaluation evidence from + alteration or loss while it is in the evaluator's + possession. + + + + Schemes may wish to control the disposal of evaluation + evidence at the conclusion of an evaluation. The disposal + of the evaluation evidence should be achieved by one or + more of: + + + returning the evaluation evidence; + + + archiving the evaluation evidence; + + + destroying the evaluation evidence. + + + + + + An evaluator may have access to sponsor and developer + commercially-sensitive information (e.g. TOE design + information, specialist tools), and may have access to + nationally-sensitive information during the course of an + evaluation. Schemes may wish to impose requirements for + the evaluator to maintain the confidentiality of the + evaluation evidence. The sponsor and evaluator may + mutually agree to additional requirements as long as these + are consistent with the scheme. + + Confidentiality requirements affect many aspects of + evaluation work, including the receipt, handling, storage + and disposal of evaluation evidence. + + + + + + The evaluation sub-activities vary depending whether it is a + PP or a TOE evaluation. Moreover, in the case of a TOE + evaluation, the sub-activities depend upon the selected + assurance requirements. + + + + + The objective of this Subclause is to describe the Observation + Report (OR) and the Evaluation Technical Report + (ETR). Schemes may require additional evaluator reports such + as reports on individual units of work, or may require + additional information to be contained in the OR and the + ETR. The CEM does not preclude the addition of information + into these reports as the CEM specifies only the minimum + information content. + + Consistent reporting of evaluation results facilitates the + achievement of the universal principle of repeatability and + reproducibility of results. The consistency covers the type and + the amount of information reported in the ETR and OR. ETR and OR + consistency among different evaluations is the responsibility of + the evaluation authority. + + The evaluator performs the two following sub-tasks in order + to achieve the CEM requirements for the information content + of reports: + + + write OR sub-task (if needed in the context of the + evaluation); + + + write ETR sub-task. + + + + + + The evaluator delivers the ETR to the evaluation authority, + as well as any ORs as they become available. Requirements + for controls on handling the ETR and ORs are established by + the scheme which may include delivery to the sponsor or + developer. The ETR and ORs may include sensitive or + proprietary information and may need to be sanitised before + they are given to the sponsor. + + + + In this version of the CEM, the requirements for the + provision of evaluator evidence to support re-evaluation and + re-use have not been explicitly stated. Where information + for re-evaluation or re-use is required by the sponsor, the + scheme under which the evaluation is being performed should + be consulted. + + + + ORs provide the evaluator with a mechanism to request a + clarification (e.g. from the evaluation authority on the application of a + requirement) or to identify a problem with an aspect of the + evaluation. + + In the case of a fail verdict, the evaluator shall provide + an OR to reflect the evaluation result. Otherwise, the + evaluator may use ORs as one way of expressing clarification + needs. + + For each OR, the evaluator shall report the following: + + + the identifier of the PP or TOE evaluated; + + + the evaluation task/sub-activity during which the + observation was generated; + + + the observation; + + + the assessment of its severity (e.g. implies a fail + verdict, holds up progress on the evaluation, requires a + resolution prior to evaluation being completed); + + + the identification of the organisation responsible for + resolving the issue; + + + the recommended timetable for resolution; + + + the assessment of the impact on the evaluation of + failure to resolve the observation. + + + + The intended audience of an OR and procedures for handling the + report depend on the nature of the report's content and on the + scheme. Schemes may distinguish different types of ORs or define + additional types, with associated differences in required + information and distribution (e.g. evaluation ORs to evaluation authorities + and sponsors). + + + + + The evaluator shall provide an ETR to present technical + justification of the verdicts. + + The CEM defines the ETR's minimum content requirement; + however, schemes may specify additional content and + specific presentational and structural requirements. For + instance, schemes may require that certain introductory + material (e.g. disclaimers and copyright Clauses) be + reported in the ETR. + + The reader of the ETR is assumed to be familiar with + general concepts of information security, the CC, the CEM, + evaluation approaches and IT. + + The ETR supports the evaluation authority to confirm that + the evaluation was done to the required standard, but it + is anticipated that the documented results may not provide + all of the necessary information, so additional + information specifically requested by the scheme may be + necessary. This aspect is outside the scope of the + CEM. + + + + This Subclause describes the minimum content of the ETR for + a PP evaluation. The contents of the ETR are portrayed in + Figure ; this figure + may be used as a guide when constructing the structural + outline of the ETR document. +
+ + + The evaluator shall report evaluation scheme + identifiers. + + Evaluation scheme identifiers (e.g. logos) are the + information required to unambiguously identify the + scheme responsible for the evaluation oversight. + + The evaluator shall report ETR configuration control + identifiers. + + The ETR configuration control identifiers contain + information that identifies the ETR (e.g. name, date and + version number). + + The evaluator shall report PP configuration control + identifiers. + + PP configuration control identifiers (e.g. name, date and + version number) are required to identify what is being evaluated + in order for the evaluation authority to verify that the verdicts have been + assigned correctly by the evaluator. + + The evaluator shall report the identity of the + developer. + + The identity of the PP developer is required to identify + the party responsible for producing the PP. + + The evaluator shall report the identity of the + sponsor. + + The identity of the sponsor is required to identify the + party responsible for providing evaluation evidence to + the evaluator. + + The evaluator shall report the identity of the + evaluator. + + The identity of the evaluator is required to identify + the party performing the evaluation and responsible for + the evaluation verdicts. + + + + The evaluator shall report the evaluation methods, + techniques, tools and standards used. + + The evaluator references the evaluation criteria, + methodology and interpretations used to evaluate the + PP. + + The evaluator shall report any constraints on the + evaluation, constraints on the handling of evaluation + results and assumptions made during the evaluation that + have an impact on the evaluation results. + + The evaluator may include information in relation to + legal or statutory aspects, organisation, + confidentiality, etc. + + + + The evaluator shall report a verdict and a supporting + rationale for each assurance component that constitutes + an activity, as a result of + performing the corresponding CEM action and its + constituent work units. + + The rationale justifies the verdict using the CC, the + CEM, any interpretations and the evaluation evidence + examined and shows how the evaluation evidence does or + does not meet each aspect of the criteria. It contains a + description of the work performed, the method used, and + any derivation of results. The rationale may provide + detail to the level of a CEM work unit. + + + + The evaluator shall report the conclusions of the + evaluation, in particular the overall verdict as defined + in CC Part 1 Clause , and determined by application + of the verdict assignment described in . + + The evaluator provides recommendations that may be useful for + the evaluation authority. These recommendations may include shortcomings of + the PP discovered during the evaluation or mention of features + which are particularly useful. + + + + The evaluator shall report for each item of evaluation + evidence the following information: + + + the issuing body (e.g. the developer, the sponsor); + + + the title; + + + the unique reference (e.g. issue date and version + number). + + + + + + The evaluator shall report any acronyms or abbreviations + used in the ETR. + + Glossary definitions already defined by the CC or CEM + need not be repeated in the ETR. + + + + The evaluator shall report a complete list that uniquely + identifies the ORs raised during the evaluation and + their status. + + For each OR, the list should contain its identifier as + well as its title or a brief summary of its + content. + + + + + This Subclause describes the minimum content of the ETR for + a TOE evaluation. The contents of the ETR are portrayed in + Figure ; this figure + may be used as a guide when constructing the structural + outline of the ETR document. +
+ + + The evaluator shall report evaluation scheme + identifiers. + + Evaluation scheme identifiers (e.g. logos) are the + information required to unambiguously identify the + scheme responsible for the evaluation oversight. + + The evaluator shall report ETR configuration control + identifiers. + + The ETR configuration control identifiers contain + information that identifies the ETR (e.g. name, date and + version number). + + The evaluator shall report ST and TOE configuration + control identifiers. + + ST and TOE configuration control identifiers identify + what is being evaluated in order for the evaluation authority to + verify that the verdicts have been assigned correctly by + the evaluator. + + If the ST claims that the TOE conforms to the + requirements of one or more PPs, the ETR shall report + the reference of the corresponding PPs. + + The PPs reference contains information that uniquely + identifies the PPs (e.g. title, date, and version + number). + + The evaluator shall report the identity of the + developer. + + The identity of the TOE developer is required to + identify the party responsible for producing the + TOE. + + The evaluator shall report the identity of the + sponsor. + + The identity of the sponsor is required to identify the + party responsible for providing evaluation evidence to + the evaluator. + + The evaluator shall report the identity of the + evaluator. + + The identity of the evaluator is required to identify + the party performing the evaluation and responsible for + the evaluation verdicts. + + + + The evaluator shall report a high level description of + the TOE and its major components based on the evaluation + evidence described in the CC assurance family entitled + , where + applicable. + + The intent of this Subclause is to characterise the degree + of architectural separation of the major components. If + there is no requirement + in the ST, this is not applicable and is considered to + be satisfied. + + + + The evaluator shall report the evaluation methods, + techniques, tools and standards used. + + The evaluator may reference the evaluation criteria, + methodology and interpretations used to evaluate the TOE + or the devices used to perform the tests. + + The evaluator shall report any constraints on the + evaluation, constraints on the distribution of + evaluation results and assumptions made during the + evaluation that have an impact on the evaluation + results. + + The evaluator may include information in relation to + legal or statutory aspects, organisation, + confidentiality, etc. + + + + For each activity on which the TOE is evaluated, the + evaluator shall report: + + + the title of the activity considered; + + + a verdict and a supporting rationale for each + assurance component that constitutes this activity, + as a result of performing the corresponding CEM + action and its constituent work units. + + + + The rationale justifies the verdict using the CC, the + CEM, any interpretations and the evaluation evidence + examined and shows how the evaluation evidence does or + does not meet each aspect of the criteria. It contains a + description of the work performed, the method used, and + any derivation of results. The rationale may provide + detail to the level of a CEM work unit. + + The evaluator shall report all information specifically + required by a work unit. + + For the and activities, work units that identify + information to be reported in the ETR have been + defined. + + + + The evaluator shall report the conclusions of the + evaluation, which will relate to whether the TOE has + satisfied its associated ST, in particular the overall + verdict as defined in CC Part 1 Clause , and determined by + application of the verdict assignment described in . + + The evaluator provides recommendations that may be useful for + the evaluation authority. These recommendations may include shortcomings of + the IT product discovered during the evaluation or mention of + features which are particularly useful. + + + + The evaluator shall report for each item of evaluation + evidence the following information: + + + the issuing body (e.g. the developer, the sponsor); + + + the title; + + + the unique reference (e.g. issue date and version + number). + + + + + + The evaluator shall report any acronyms or abbreviations + used in the ETR. + + Glossary definitions already defined by the CC or CEM + need not be repeated in the ETR. + + + + The evaluator shall report a complete list that uniquely + identifies the ORs raised during the evaluation and + their status. + + For each OR, the list should contain its identifier as + well as its title or a brief summary of its + content. + + + + + + + The CC permits comparability between the results of independent + security evaluations. The CC does so by providing a common set + of requirements for the security functionality of IT products + and for assurance measures applied to these IT products during a + security evaluation. These IT products may be implemented in + hardware, firmware or software. + The evaluation process establishes a level of confidence that + the security functionality of these IT products and the + assurance measures applied to these IT products meet these + requirements. The evaluation results may help consumers to + determine whether these IT products fulfil their security needs. + The CC is useful as a guide for the development, evaluation + and/or procurement of IT products with security functionality. + The CC is intentionally flexible, enabling a range of evaluation + methods to be applied to a range of security properties of a + range of IT products. Therefore users of the standard are + cautioned to exercise care that this flexibility is not + misused. For example, using the CC in conjunction with + unsuitable evaluation methods, irrelevant security properties, + or inappropriate IT products, may result in meaningless + evaluation results. + Consequently, the fact that an IT product has been evaluated has + meaning only in the context of the security properties that were + evaluated and the evaluation methods that were used. Evaluation + authorities are advised to carefully check the products, + properties and methods to determine that an evaluation will + provide meaningful results. Additionally, purchasers of + evaluated products are advised to carefully consider this + context to determine whether the evaluated product is useful and + applicable to their specific situation and needs. + The CC addresses protection of assets from unauthorised + disclosure, modification, or loss of use. The categories of + protection relating to these three types of failure of security + are commonly called confidentiality, integrity, and + availability, respectively. The CC may also be applicable + to aspects of IT security outside of these three. The CC + is applicable to risks arising from human activities (malicious + or otherwise) and to risks arising from non-human + activities. Apart from IT security, the CC may be applied + in other areas of IT, but makes no claim of applicability in + these areas. + Certain topics, because they involve specialised techniques or + because they are somewhat peripheral to IT security, are + considered to be outside the scope of the CC. Some of these are + identified below. + + The CC does not contain security evaluation criteria + pertaining to administrative security measures not related + directly to the IT security functionality. However, it is + recognised that significant security can often be achieved + through or supported by administrative measures such as + organisational, personnel, physical, and procedural + controls. + + The evaluation of some technical physical aspects of IT + security such as electromagnetic emanation control is not + specifically covered, although many of the concepts + addressed will be applicable to that area. + + The CC does not address the evaluation methodology + under which the criteria should be applied. This methodology + is given in the CEM. + + The CC does not address the administrative and legal + framework under which the criteria may be applied by + evaluation authorities. However, it is expected that the CC + will be used for evaluation purposes in the context of such + a framework. + + The procedures for use of evaluation results in + accreditation are outside the scope of the CC. Accreditation + is the administrative process whereby authority is granted + for the operation of an IT product (or collection thereof) + in its full operational environment including all of its + non-IT parts. The results of the evaluation process are an + input to the accreditation process. However, as other + techniques are more appropriate for the assessments of + non-IT related properties and their relationship to the IT + security parts, accreditors should make separate provisions + for those aspects. + + The subject of criteria for the assessment of the inherent + qualities of cryptographic algorithms is not covered in the + CC. Should independent assessment of mathematical properties + of cryptography be required, the evaluation scheme under + which the CC is applied must make provision for such + assessments. + + ISO terminology, such as "can", "informative", "may", + "normative", "shall" and "should" used throughout the document + are defined in the ISO/IEC Directives, Part 2. Note that the + term "should" has an additional meaning applicable when using + this standard. See the note below. The following definition is + given for the use of ``should'' in the CC. + should + + within normative text, ``should'' indicates ``that among + several possibilities one is recommended as particularly + suitable, without mentioning or excluding others, or that a + certain course of action is preferred but not necessarily + required.'' (ISO/IEC Directives, Part 2). + + The CC interprets ``not necessarily required'' to mean + that the choice of another possibility requires a justification + of why the preferred option was not chosen. + + This part of the CC establishes the general concepts and + principles of IT security evaluation and specifies the general + model of evaluation given by various parts of the standard which + in its entirety is meant to be used as the basis for evaluation + of security properties of IT products. + Part one provides an overview of all parts of the CC + standard. It describes the various parts of the standard; + defines the terms and abbreviations to be used in all parts of + the standard; establishes the core concept of a Target of + Evaluation (TOE); the evaluation context and describes the + audience to which the evaluation criteria are addressed. An + introduction to the basic security concepts necessary for + evaluation of IT products is given. + It defines the various operations by which the functional and + assurance components given in CC Part 2 and CC Part 3 may be + tailored through the use of permitted operations. + The key concepts of protection profiles (PP), packages of + security requirements and the topic of conformance are specified + and the consequences of evaluation, evaluation results are + described. This part of the CC gives guidelines for the + specification of Security Targets (ST) and provides a + description of the organization of components throughout the + model. General information about the evaluation methodology are + given in the CEM and the scope of evaluation schemes is + provided. + The following referenced documents are indispensable for the + application of this CC part 1. For dated references, only the + edition cited applies. For undated references, the latest + edition of the referenced document (including any amendments) + applies.CC-2 + Common Criteria for Information Technology Security + Evaluation, Version _CCVERSION_, revision _CCREVISION_, + _CCDATE_. Part 2: Functional security components. + CC-3 + Common Criteria for Information Technology Security + Evaluation, Version _CCVERSION_, revision _CCREVISION_, + _CCDATE_. Part 3: Assurance security components. + CEM + Common Methodology for Information Technology Security + Evaluation, Version _CCVERSION_, revision _CCREVISION_, + _CCDATE_. + + For the purpose of the CC, the following terms and definitions + apply. + This Clause contains only + those terms which are used in a specialised way throughout the + CC. Some combinations of common terms used in the CC, while not + meriting inclusion in this Clause , are explained for clarity in the context + where they are used. + adverse actions + + actions performed by a threat agent on an asset + + assets + + entities that the owner of the TOE presumably places value upon + + assignment + + the specification of an identified parameter in a component + (of the CC) or requirement + + assurance + + grounds for confidence that a TOE meets the SFRs + + attack potential + + measure of the effort to be expended in attacking a TOE, + expressed in terms of an attacker's expertise, resources and + motivation + + augmentation + + addition of one or more requirement(s) to a package + + authentication data + + information used to verify the claimed identity of a user + + authorised user + + TOE user who may, in accordance with the SFRs, perform an operation + + class + + set of CC families that share a common focus + + coherent + + logically ordered and having discernible meaning + + For documentation, this addresses both the actual text and + the structure of the document, in terms of whether it is + understandable by its target audience. + + complete + + property where all necessary parts of an entity have been provided + + In terms of documentation, this means that all relevant + information is covered in the documentation, at such a level + of detail that no further explanation is required at that + level of abstraction. + + component + + smallest selectable set of elements on which requirements + may be based + + composed assurance package + + assurance package consisting of requirements drawn from + CC Part 3 (predominately from the class), representing a point on the CC + predefined composition assurance scale + + confirm + + declare that something has been reviewed in detail with an + independent determination of sufficiency + + The level of rigour required depends on the nature of the subject + matter. This term is only applied to evaluator actions. + + connectivity + + property of the TOE allowing interaction with IT entities + external to the TOE + + This includes exchange of data by wire or by wireless means, + over any distance in any environment or configuration. + + consistent + + relationship between two or more entities such that there + are no apparent contradictions between these entities + + counter, verb + + meet an attack where the impact of a particular threat is + mitigated but not necessarily eradicated + + demonstrable conformance + + relation between an ST and a PP, where the ST provides a + solution which solves the generic security problem in the PP + + The PP and the ST may contain entirely different statements + that discuss different entities, use different concepts + etc. Demonstrable conformance is also suitable for a TOE + type where several similar PPs already exist, thus allowing + the ST author to claim conformance to these PPs + simultaneously, thereby saving work. + + demonstrate + + provide a conclusion gained by an analysis which is less + rigorous than a ``proof'' + + dependency + + relationship between components such that if a requirement + based on the depending component is included in a PP, ST or + package, a requirement based on the component that is + depended upon must normally also be included in the PP, ST + or package + + describe + + provide specific details of an entity + + determine + + affirm a particular conclusion based on independent analysis + with the objective of reaching a particular conclusion + + The usage of this term implies a truly independent analysis, + usually in the absence of any previous analysis having been + performed. Compare with the terms ``confirm'' or + ``verify'' which imply that an analysis has already been + performed which needs to be reviewed + + development environment + + environment in which the TOE is developed + + element + + indivisible statement of a security need + + ensure + + guarantee a strong causal relationship between an action and + its consequences + + When this term is preceded by the word ``help'' it indicates + that the consequence is not fully certain, on the basis of + that action alone. + + evaluation + + assessment of a PP, an ST or a TOE, against defined criteria + + evaluation assurance level + + set of assurance requirements drawn from CC Part 3, + representing a point on the CC predefined assurance scale, + that form an assurance package + + evaluation authority + + body that sets the standards and monitors the quality of + evaluations conducted by bodies within a specific community + and implements the CC for that community by means of an + evaluation scheme + + evaluation scheme + + administrative and regulatory framework under which the CC + is applied by an evaluation authority within a specific + community + + exhaustive + + characteristic of a methodical approach taken to perform an + analysis or activity according to an unambiguous plan + + This term is used in the CC with respect to conducting an + analysis or other activity. It is related to ``systematic'' + but is considerably stronger, in that it indicates not only + that a methodical approach has been taken to perform the + analysis or activity according to an unambiguous plan, but + that the plan that was followed is sufficient to ensure that + all possible avenues have been exercised. + + explain + + give argument accounting for the reason for taking a course + of action + + This term differs from both ``describe'' and + ``demonstrate''. It is intended to answer the question + ``Why?'' without actually attempting to argue that the + course of action that was taken was necessarily optimal. + + extension + + 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 + + external entity + + human or IT entity possibly interacting with the TOE from + outside of the TOE boundary + + family + + set of components that share a similar goal but differ in + emphasis or rigour + + formal + + expressed in a restricted syntax language with defined + semantics based on well-established mathematical concepts + + guidance documentation + + documentation that describes the delivery, preparation, + operation, management and/or use of the TOE + + identity + + representation uniquely identifying entities (e.g. a user, a + process or a disk) within the context of the TOE + + An example of such a representation is a string. For a human + user, the representation can be the full or abbreviated name + or a (still unique) pseudonym. + + informal + + expressed in natural language + + inter TSF transfers + + communicating data between the TOE and the security + functionality of other trusted IT products + + internal communication channel + + communication channel between separated parts of the TOE + + internal TOE transfer + + communicating data between separated parts of the TOE + + internally consistent + + no apparent contradictions exist between any aspects of an + entity + + In terms of documentation, this means that there can be no + statements within the documentation that can be taken to + contradict each other. + + iteration + + use of the same component to express two or more distinct + requirements + + justification + + analysis leading to a conclusion + + ``Justification'' is more rigorous than a + demonstration. This term requires significant rigour in + terms of very carefully and thoroughly explaining every step + of a logical argument. + + object + + passive entity in the TOE, that contains or receives + information, and upon which subjects perform operations + + operation (on a component of the CC) + + modification or repetition of a component + + Allowed operations on components are assignment, iteration, + refinement and selection. + + operation (on an object) + + specific type of action performed by a subject on an object + + operational environment + + environment in which the TOE is operated + + organisational security policy + + set of security rules, procedures, or guidelines for an + organisation + + A policy may pertain to a specific operational environment. + + package + + named set of either security functional or security + assurance requirements + + An example of a package is ``EAL 3''. + + Protection Profile evaluation + + assessment of a PP against defined criteria + + Protection Profile + + implementation-independent statement of security needs for a + TOE type + + prove + + show correspondence by formal analysis in its mathematical + sense + + It is completely rigorous in all ways. Typically, ``prove'' + is used when there is a desire to show correspondence + between two TSF representations at a high level of rigour. + + refinement + + addition of details to a component + + role + + predefined set of rules establishing the allowed + interactions between a user and the TOE + + secret + + information that must be known only to authorised users + and/or the TSF in order to enforce a specific SFP + + secure state + + state in which the TSF data are consistent and the TSF + continues correct enforcement of the SFRs + + security attribute + + property of subjects, users (including external IT + products), objects, information, sessions and/or resources + that is used in defining the SFRs and whose values are used + in enforcing the SFRs + + security function policy + + set of rules describing specific security behaviour enforced + by the TSF and expressible as a set of SFRs + + security objective + + statement of an intent to counter identified threats and/or + satisfy identified organisation security policies and/or + assumptions + + security problem + + statement which in a formal manner defines the nature and + scope of the security that the TOE is intended to address + + This statement consists of a combination of: + + threats to be countered by the TOE, + + the OSPs enforced by the TOE, and + + the assumptions that are upheld for the TOE and its + operational environment. + + security requirement + + requirement, stated in a standardised language, which is + meant to contribute to achieving the security objectives for + a TOE + + Security Target + + implementation-dependent statement of security needs for a + specific identified TOE + + selection + + specification of one or more items from a list in a component + + semiformal + + expressed in a restricted syntax language with defined semantics + + specify + + provide specific details about an entity in a rigorous and precise manner + + strict conformance + + hierarchical relationship between a PP and an ST where all + the requirements in the PP also exist in the ST + + This relation can be roughly defined as ``the ST shall + contain all statements that are in the PP, but may contain + more''. Strict conformance is expected to be used for + stringent requirements that are to be adhered to in a single + manner. + + ST evaluation + + assessment of an ST against defined criteria + + subject + + active entity in the TOE that performs operations on objects + + target of evaluation + + set of software, firmware and/or hardware possibly + accompanied by guidance + + threat agent + + entity that can adversely act on assets + + TOE evaluation + + assessment of a TOE against defined criteria + + TOE resource + + anything useable or consumable in the TOE + + 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 + + trace, verb + + perform an informal correspondence analysis between two + entities with only a minimal level of rigour + + transfers outside of the TOE + + TSF mediated communication of data to entities not under the + control of the TSF + + translation + + describes the process of describing security requirements in + a standardised language. + + use of the term translation in this context is not literal + and does not imply that every SFR expressed in standardised + language can also be translated back to the security + objectives. + + trusted channel + + a means by which a TSF and another trusted IT product can + communicate with necessary confidence + + trusted IT product + + IT product, other than the TOE, which has its security + functional requirements administratively coordinated with + the TOE and which is assumed to enforce its security + functional requirements correctly + + An example of a trusted IT product would be one that has + been separately evaluated. + + trusted path + + means by which a user and a TSF can communicate with the + necessary confidence + + TSF data + + data for the operation of the TOE upon which the enforcement + of the SFR relies + + TSF interface + + means by which external entities (or subjects in the TOE but + outside of the TSF) supply data to the TSF, receive data + from the TSF and invoke services from the TSF + + user + + see external entity + + user data + + data for the user, that does not affect the operation of the TSF + + verify + + rigorously review in detail with an independent + determination of sufficiency + + Also see ``confirm''. This term has more rigorous + connotations. The term ``verify'' is used in the context + of evaluator actions where an independent effort is required + of the evaluator. + + The following terms are used in the requirements for software + internal structuring. Some of these are derived from the + IEEE Std 610.12-1990, + Standard glossary of software engineering terminology, + Institute of Electrical and Electronics Engineers. + administrator + + entity that has a level of trust with respect to all + policies implemented by the TSF + + Not all PPs or STs assume the same level of trust for + administrators. Typically administrators are assumed to + adhere at all times to the policies in the ST of the + TOE. Some of these policies may be related to the + functionality of the TOE, others may be related to the + operational environment. + + call tree + + identifies the modules in a system in diagrammatic form + showing which modules call one another + + Adapted from + cohesion + + module strength + + manner and degree to which the tasks performed by a single + software module are related to one another + + Types of cohesion include coincidental, communicational, + functional, logical, sequential, and temporal. These types + of cohesion are described by the relevant term entry. + + coincidental cohesion + + module with the characteristic of performing unrelated, or + loosely related, activities + + See ``cohesion''. + + communicational cohesion + + module containing functions that produce output for, or use + output from, other functions within the module + + See ``cohesion''. + An example of a communicationally cohesive module is an + access check module that includes mandatory, + discretionary, and capability checks. + complexity + + measure of how difficult software is to understand, and thus + to analyse, test, and maintain + + Reducing complexity is the ultimate goal for using modular + decomposition, layering and minimisation. Controlling + coupling and cohesion contributes significantly to this + goal. + A good deal of effort in the software engineering field + has been expended in attempting to develop metrics to + measure the complexity of source code. Most of these + metrics use easily computed properties of the source code, + such as the number of operators and operands, the + complexity of the control flow graph (cyclomatic + complexity), the number of lines of source code, the ratio + of comments to executable code, and similar + measures. Coding standards have been found to be a useful + tool in generating code that is more readily understood. + The family calls for a complexity + analysis in all components. It is expected that the + developer will provide support for the claims that there + has been a sufficient reduction in complexity. This + support could include the developer's programming + standards, and an indication that all modules meet the + standard (or that there are some exceptions that are + justified by software engineering arguments). It could + include the results of tools used to measure some of the + properties of the source code, or it could include other + support that the developer finds appropriate. + coupling + + manner and degree of interdependence between software modules + + Types of coupling include call, common and content + coupling. These are characterised below: + + call coupling + + relationship between two modules + + Examples of call coupling are data, stamp, and control: + + call coupling (data) + + relationship between two modules communicating strictly + through the use of call parameters that represent single + data items. + + See ``call coupling'' + + call coupling (stamp) + + relationship between two modules through the use of call + parameters that comprise multiple fields or that have + meaningful internal structures. + + See ``call coupling'' + + call coupling (control) + + relationship between two modules if one passes information + that is intended to influence the internal logic of the + other. + + See ``call coupling'' + + common coupling + + relationship between two modules sharing a common data area + or other common system resource + + Global variables indicate that modules using those global + variables are common coupled. Common coupling through global + variables is generally allowed, but only to a limited + degree. + For example, variables that are placed into a global area, + but are used by only a single module, are inappropriately + placed, and should be removed. Other factors that need to + be considered in assessing the suitability of global + variables are: + + The number of modules that modify a global variable: + In general, only a single module should be allocated + the responsibility for controlling the contents of a + global variable, but there may be situations in which + a second module may share that responsibility; in such + a case, sufficient justification must be provided. It + is unacceptable for this responsibility to be shared + by more than two modules. (In making this assessment, + care should be given to determining the module + actually responsible for the contents of the variable; + for example, if a single routine is used to modify the + variable, but that routine simply performs the + modification requested by its caller, it is the + calling module that is responsible, and there may be + more than one such module). Further, as part of the + complexity determination, if two modules are + responsible for the contents of a global variable, + there should be clear indications of how the + modifications are coordinated between them. + + The number of modules that reference a global + variable: Although there is generally no limit on the + number of modules that reference a global variable, + cases in which many modules make such a reference + should be examined for validity and necessity. + + content coupling + + relationship between two modules where one makes direct + reference to the internals of the other + + Examples include modifying code of, or referencing labels + internal to, the other module. The result is that some or + all of the content of one module are effectively included in + the other. Content coupling can be thought of as using + unadvertised module interfaces; this is in contrast to call + coupling, which uses only advertised module interfaces. + + domain separation + + security architecture property whereby the TSF defines + separate security domains for each user and for the TSF and + ensures that no user process can affect the contents of a + security domain of another user or of the TSF + + functional cohesion + + functional property of a module which performs activities + related to a single purpose + + A functionally cohesive module transforms a single type of + input into a single type of output, such as a stack manager or + a queue manager. See also ``cohesion''. + + interaction + + general communication-based activity between entities + + interface + + means of interaction with a component or module + + layering + + design technique where separate groups of modules (the + layers) are hierarchically organised to have separate + responsibilities such that one layer depends only on layers + below it in the hierarchy for services, and provides its + services only to the layers above it + + Strict layering adds the constraint that each layer receives + services only from the layer immediately beneath it, and + provides services only to the layer immediately above it. + + logical cohesion + + procedural cohesion + + characteristics of a module performing similar activities on + different data structures + + A module exhibits logical cohesion if its functions perform + related, but different, operations on different inputs. See + also ``cohesion''. + + modular decomposition + + process of breaking a system into components to facilitate + design, development and evaluation + + non-bypassability (of the TSF) + + security architecture property whereby all SFR-related + actions are mediated by the TSF + + procedural cohesion + + See ``logical cohesion'' + + security domain + + collection of resources to which an active entity has access + privileges + + sequential cohesion + + module containing functions each of whose output is input + for the following function in the module + + An example of a sequentially cohesive module is one that + contains the functions to write audit records and to + maintain a running count of the accumulated number of audit + violations of a specified type. + + software engineering + + application of a systematic, disciplined, quantifiable + approach to the development and maintenance of software; + that is, the application of engineering to software + + As with engineering practices in general, some amount of + judgement must be used in applying engineering + principles. Many factors affect choices, not just the + application of measures of modular decomposition, layering, + and minimisation. For example, a developer may design a + system with future applications in mind that will not be + implemented initially. The developer may choose to include + some logic to handle these future applications without fully + implementing them; further, the developer may include some + calls to as-yet unimplemented modules, leaving call + stubs. The developer's justification for such deviations + from well-structured programs will have to be assessed using + judgement, as well as the application of good software + engineering discipline. + + temporal cohesion + + characteristics of a module containing functions that need + to be executed at about the same time + + Adapted from . Examples of temporally + cohesive modules include initialisation, recovery, and + shutdown modules. + + TSF self-protection + + security architecture property whereby the TSF cannot be + corrupted by non-TSF code or entities + + installation + + procedure performed by a human user embedding the TOE in its + operational environment and putting it into an operational + state + + This operation is performed normally only once, after + receipt and acceptance of the TOE. The TOE is expected to be + progressed to a configuration allowed by the ST. If similar + processes have to be performed by the developer they are + denoted as ``generation'' throughout . If + the TOE requires an initial start-up that does not need to + be repeated regularly, this process would be classified as + installation. + + operation + + usage phase of the TOE including ``normal usage'', + administration and maintenance of the TOE after delivery and + preparation + + preparation + + activity in the life-cycle phase of a product, comprising + the customer's acceptance of the delivered TOE and its + installation which may include such things as booting, + initialisation, start-up and progressing the TOE to a state + ready for operation + + acceptance criteria + + criteria to be applied when performing the acceptance + procedures (e.g. successful document review, or successful + testing in the case of software, firmware or hardware) + + acceptance procedures + + procedures followed in order to accept newly created or + modified configuration items as part of the TOE, or to move + them to the next step of the life-cycle + + These procedures identify the roles or individuals + responsible for the acceptance and the criteria to be + applied in order to decide on the acceptance. + There are several types of acceptance situations some of + which may overlap: + + acceptance of an item into the configuration + management system for the first time, in particular + inclusion of software, firmware and hardware + components from other manufacturers into the TOE + (``integration''); + + progression of configuration items to the next + life-cycle phase at each stage of the construction of + the TOE (e.g. module, subsystem, quality control of + the finished TOE); + + subsequent to transports of configuration items (for + example parts of the TOE or preliminary products) + between different development sites; + + subsequent to the delivery of the TOE to the consumer. + + configuration management + + discipline applying technical and administrative direction + and surveillance to: identify and document the functional + and physical characteristics of a configuration item, + control changes to those characteristics, record and report + change processing and implementation status, and verify + compliance with specified requirements. + + CM documentation + + all CM documentation including CM output, CM list + (configuration list), CM system records, CM plan and CM + usage documentation + + configuration management evidence + + everything that may be used to establish confidence in the + correct operation of the CM system + + For example, CM output, rationales provided by the + developer, observations, experiments or interviews made by + the evaluator during a site visit. + + configuration item + + object managed by the CM system during the TOE development + + These may be either parts of the TOE or objects related to + the development of the TOE like evaluation documents or + development tools. CM items may be stored in the CM system + directly (for example files) or by reference (for example + hardware parts) together with their version. + + configuration list + + configuration management output document listing all + configuration items for a specific product together with the + exact version of each configuration management item relevant + for a specific version of the complete product + + This list allows distinguishing the items belonging to the + evaluated version of the product from other versions of + these items belonging to other versions of the product. The + final configuration management list is a specific document + for a specific version of a specific product. (Of course the + list can be an electronic document inside of a configuration + management tool. In that case it can be seen as a specific + view into the system or a part of the system rather than an + output of the system. However, for the practical use in an + evaluation the configuration list will probably be delivered + as a part of the evaluation documentation.) The + configuration list defines the items that are under the + configuration management requirements of . + + configuration management output + + results, related to configuration management, produced or + enforced by the configuration management system + + These configuration management related results could occur + as documents (for example filled paper forms, configuration + management system records, logging data, hard-copies and + electronic output data) as well as actions (for example + manual measures to fulfil configuration management + instructions). Examples of such configuration management + outputs are configuration lists, configuration management + plans and/or behaviours during the product life-cycle. + + configuration management plan + + description of how the configuration management system is + used for the TOE + + The objective of issuing a configuration management plan is + that staff members can see clearly what they have to + do. From the point of view of the overall configuration + management system this can be seen as an output document + (because it may be produced as part of the application of + the configuration management system). From the point of view + of the concrete project it is a usage document because + members of the project team use it in order to understand + the steps that they have to perform during the project. The + configuration management plan defines the usage of the + system for the specific product; the same system may be used + to a different extent for other products. That means the + configuration management plan defines and describes the + output of the configuration management system of a company + which is used during the TOE development. + + configuration management system + + set of procedures and tools (including their documentation) + used by a developer to develop and maintain configurations + of his products during their life-cycles + + Configuration management systems may have varying degrees of + rigour and function. At higher levels, configuration + management systems may be automated, with flaw remediation, + change controls, and other tracking mechanisms. + + configuration management system records + + output produced during the operation of the configuration + management system documenting important configuration + management activities + + Examples of configuration management system records are + configuration management item change control forms or + configuration management item access approval forms. + + configuration management tools + + manually operated or automated tools realising or supporting + a configuration management system + + For example tools for the version management of the parts of + the TOE. + + configuration management usage documentation + + part of the configuration management system, which + describes, how the configuration management system is + defined and applied by using for example handbooks, + regulations and/or documentation of tools and procedures + + delivery + + transmission of the finished TOE from the production + environment into the hands of the customer + + This product life-cycle phase may include packaging and + storage at the development site, but does not include + transportations of the unfinished TOE or parts of the TOE + between different developers or different development + sites. + + developer + + organisation responsible for the development of the TOE + + development + + product life-cycle phase which is concerned with generating + the implementation representation of the TOE + + Throughout the requirements, development + and related terms (developer, develop) are meant in the more + general sense to comprise development and production. + + development tools + + tools (including test software, if applicable) supporting + the development and production of the TOE + + For example for a software TOE, development tools are + usually programming languages, compilers, linkers and + generating tools. + + implementation representation + + least abstract representation of the TSF, specifically the + one that is used to create the TSF itself without further + design refinement + + Source code that is then compiled or a hardware drawing that + is used to build the actual hardware are examples of parts + of an implementation representation. + + life-cycle + + sequence of stages of existence of an object (for example a + product or a system) in time + + life-cycle definition + + definition of the life-cycle model + + life cycle model + + description of the stages and their relations to each other + that are used in the management of the life-cycle of a + certain object, how the sequence of stages looks like and + which high level characteristics the stages have + + production + + production life-cycle phase follows the development phase + and consists of transforming the implementation + representation into the implementation of the TOE, i.e. into + a state acceptable for delivery to the customer + + This phase may comprise manufacturing, integration, + generation, internal transports, storage, and labelling of + the TOE. +
+ covert channel + + enforced, illicit signalling channel that allows a user to + surreptitiously contravene the multi-level separation policy + and unobservability requirements of the TOE + + encountered potential vulnerabilities + + potential weakness in the TOE identified by the evaluator + while performing evaluation activities that could be used to + violate the SFRs + + exploitable vulnerability + + weakness in the TOE that can be used to violate the SFRs in + the operational environment for the TOE + + monitoring attacks + + generic category of attack methods that includes passive + analysis techniques aiming at disclosure of sensitive + internal data of the TOE by operating the TOE in the way + that corresponds to the guidance documents + + potential vulnerability + + suspected, but not confirmed, weakness + + Suspicion is by virtue of a postulated attack path to + violate the SFRs. + + residual vulnerability + + weakness that cannot be exploited in the operational + environment for the TOE, but that could be used to violate + the SFRs by an attacker with greater attack potential than + is anticipated in the operational environment for the TOE + + vulnerability + + weakness in the TOE that can be used to violate the SFRs in + some environment + + base component + + entity in a composed TOE, which has itself been the subject + of an evaluation, providing services and resources to a + dependent component + + compatible (components) + + property of a component able to provide the services + required by the other component, through the corresponding + interfaces of each component, in consistent operational + environments + + component TOE + + successfully evaluated TOE that is part of another composed + TOE + + composed TOE + + TOE comprised solely of two or more components that have + been successfully evaluated + + dependent component + + entity in a composed TOE, which is itself the subject of an + evaluation, relying on the provision on services by a base + component + + functional interface + + external interface providing a user with access to + functionality of the TOE which is not directly involved in + enforcing security functional requirements + + In a composed TOE these are the interfaces provided by the + base component that are required by the dependent component + to support the operation of the composed TOE. + + The following abbreviations are used in one or more parts of the + CC:API + Application Programming Interface + CAP + Composed Assurance Package + CC + Common Criteria + CCRAArrangement on the + Recognition of Common Criteria Certificates in the field of IT + Security + CM + Configuration Management + DAC + Discretionary Access Control + EAL + Evaluation Assurance Level + GHz + Gigahertz + GUI + Graphical User Interface + IC + Integrated Circuit + IOCTL + Input Output Control + IP + Internet Protocol + IT + Information Technology + MB + Mega Byte + OS + Operating System + OSP + Organisational Security Policy + PC + Personal Computer + PCI + Peripheral Component Interconnect + PKI + Public Key Infrastructure + PP + Protection Profile + RAM + Random Access Memory + RPC + Remote Procedure Call + SAR + Security Assurance Requirement + SFR + Security Functional Requirement + SFP + Security Function Policy + SPD + Security Problem Definition + ST + Security Target + TCP + Transmission Control Protocol + TOE + Target of Evaluation + TSF + TOE Security Functionality + TSFI + TSF Interface + VPN + Virtual Private Network + + This Clause introduces the main concepts of the CC. It + identifies the concept ``TOE'', the target audience of the CC, + and the approach taken to present the material in the remainder + of the CC. + The CC is flexible in what to evaluate and is therefore not + tied to the boundaries of IT products as commonly + understood. Therefore in the context of evaluation, the CC + uses the term ``TOE'' (Target of Evaluation). + A TOE is defined as a set of software, firmware and/or + hardware possibly accompanied by guidance. + While there are cases where a TOE consists of an IT product, + this need not be the case. The TOE may be an IT product, a + part of an IT product, a set of IT products, a unique + technology that may never be made into a product, or a + combination of these. + As far as the CC is concerned, the precise relation + between the TOE and any IT products is only important in one + aspect: the evaluation of a TOE containing only part of an IT + product should not be misrepresented as the evaluation of the + entire IT product. + Examples of TOEs include: + + A software application; + + An operating system; + + A software application in combination with an operating + system; + + A software application in combination with an operating + system and a workstation; + + An operating system in combination with a workstation; + + A smart card integrated circuit; + + The cryptographic co-processor of a smart card integrated + circuit; + + A Local Area Network including all terminals, servers, + network equipment and software; + + A database application excluding the remote client + software normally associated with that database + application. + + In the CC, a TOE can occur in several + representations, such as (for a software TOE): + + a list of files in a configuration management system; + + a single master copy, that has just been compiled; + + a box containing a CD-ROM and a manual, ready to be shipped to a customer; + + an installed and operational version. + + All of these are considered to be a TOE: and wherever the + term ``TOE'' is used in the remainder of the CC, the + context determines the representation that is meant. + In general, IT products can be configured in many ways: + installed in different ways, with different options enabled + or disabled. As, during a CC evaluation, it will be + determined whether a TOE meets certain requirements, this + flexibility in configuration may lead to problems, as all + possible configurations of the TOE must meet the + requirements. For these reasons, it is often the case that + the guidance part of the TOE strongly constrains the + possible configurations of the TOE. That is: the guidance of + the TOE may be different from the general guidance of the IT + product. + An example is an operating system IT product. This product + can be configured in many ways (e.g. types of users, number + of users, types of external connections allowed/disallowed, + options enabled/disabled etc.). + If the same IT product is to be a TOE, and is evaluated + against a reasonable set of requirements, the configuration + should be much more tightly controlled, as many options + (e.g. allow all types of external connections or the system + administrator does not need to be authenticated) will lead + to a TOE not meeting the requirements. + For this reason, there would normally be a difference + between the guidance of the IT product (allowing many + configurations) and the guidance of the TOE (allowing only + one or only configurations that do not differ in + security-relevant ways). + Note that if the guidance of the TOE still allows more than + one configuration, these configurations are collectively + called ``the TOE'' and each such configuration must meet the + requirements levied on the TOE. + There are three groups with a general interest in evaluation + of the security properties of TOEs: consumers, developers and + evaluators. The criteria presented in this CC part 1 have been + structured to support the needs of all three groups. They are + all considered to be the principal users of the CC. The + three groups can benefit from the criteria as explained in the + following paragraphs. + The CC is written to ensure that evaluation fulfils + the needs of the consumers as this is the fundamental + purpose and justification for the evaluation process. + Consumers can use the results of evaluations to help decide + whether a TOE fulfils their security needs. These security + needs are typically identified as a result of both risk + analysis and policy direction. Consumers can also use the + evaluation results to compare different TOEs. + The CC gives consumers, especially in consumer groups + and communities of interest, an implementation-independent + structure, termed the Protection Profile (PP), in which to + express their security requirements in an unambiguous + manner. + The CC is intended to support developers in preparing + for and assisting in the evaluation of their TOEs and in + identifying security requirements to be satisfied by those + TOEs. These requirements are contained in an + implementation-dependent construct termed the Security + Target (ST). This ST may be based on one or more PPs to show + that the ST conforms to the security requirements from + consumers as laid down in those PPs. + The CC can then be used to determine the + responsibilities and actions to provide evidence that is + necessary to support the evaluation of the TOE against these + requirements. It also defines the content and presentation + of that evidence. + The CC contains criteria to be used by evaluators + when forming judgements about the conformance of TOEs to + their security requirements. The CC describes the set + of general actions the evaluator is to carry out. Note that + the CC does not specify procedures to be followed in + carrying out those actions. More information on these + procedures may be found in Subclause . + While the CC is oriented towards specification and + evaluation of the IT security properties of TOEs, it may + also be useful as reference material to all parties with an + interest in or responsibility for IT security. Some of the + additional interest groups that can benefit from information + contained in the CC are: + + system custodians and system security officers + responsible for determining and meeting organisational + IT security policies and requirements; + + auditors, both internal and external, responsible for + assessing the adequacy of the security of an IT solution + (which may consist of or contain a TOE); + + security architects and designers responsible for the + specification of security properties of IT products; + + accreditors responsible for accepting an IT solution for + use within a particular environment; + + sponsors of evaluation responsible for requesting and + supporting an evaluation; and + + evaluation authorities responsible for the management + and oversight of IT security evaluation programmes. + + The CC is presented as a set of distinct but related + parts as identified below. Terms used in the description of + the parts are explained in Clause . + Part 1, Introduction and general model is the + introduction to the CC. It defines the general concepts + and principles of IT security evaluation and presents a + general model of evaluation. + Part 2, Security functional components + establishes a set of functional components that serve as + standard templates upon which to base functional + requirements for TOEs. CC Part 2 catalogues the set of + functional components and organises them in families and + classes. + Part 3, Security assurance components + establishes a set of assurance components that serve as + standard templates upon which to base assurance + requirements for TOEs. CC Part 3 catalogues the set of + assurance components and organises them into families and + classes. CC Part 3 also defines evaluation criteria for + PPs and STs and presents seven pre-defined assurance + packages which are called the Evaluation Assurance Levels + (EALs). + + In support of the three parts of the CC listed above, + other documents have been published, the CEM provides + the methodology for IT security evaluation using the CC + as a basis. It is anticipated that other documents will be + published, including technical rationale material and guidance + documents. + The following table presents, for the three key target + audience groupings, how the parts of the CC will be of + interest. + Consumers + + Developers + + Evaluators + + Part 1 + + Use for background information and + are obliged to use for reference purposes. Guidance + structure for PPs. + + Use for background information and reference + purposes. Are obliged to use for the development of + security specifications for TOEs. + + Are obliged to use for reference purposes and for + guidance in the structure for PPs and STs. + + Part 2 + + Use for guidance and reference when formulating + statements of requirements for a TOE. + + Are obliged to use for reference when interpreting + statements of functional requirements and formulating + functional specifications for TOEs. + + Are obliged to use for reference when interpreting + statements of functional requirements. + + Part 3 + + Use for guidance when determining required levels of + assurance. + + Use for reference when interpreting statements of + assurance requirements and determining assurance + approaches of TOEs. + + Use for reference when interpreting statements of + assurance requirements. + Road map to the Common Criteria
+ In order to achieve greater comparability between evaluation + results, evaluations should be performed within the framework + of an authoritative evaluation scheme that sets the standards, + monitors the quality of the evaluations and administers the + regulations to which the evaluation facilities and evaluators + must conform. + The CC does not state requirements for the regulatory + framework. However, consistency between the regulatory + frameworks of different evaluation authorities will be + necessary to achieve the goal of mutual recognition of the + results of such evaluations. + A second way of achieving greater comparability between + evaluation results is using a common methodology to achieve + these results. For the CC, this methodology is given in + the CEM. + Use of a common evaluation methodology contributes to the + repeatability and objectivity of the results but is not by + itself sufficient. Many of the evaluation criteria require the + application of expert judgement and background knowledge for + which consistency is more difficult to achieve. In order to + enhance the consistency of the evaluation findings, the final + evaluation results may be submitted to a certification + process. + The certification process is the independent inspection of the + results of the evaluation leading to the production of the + final certificate or approval, which is normally publicly + available. The certification process is a means of gaining + greater consistency in the application of IT security + criteria. + The evaluation schemes and certification processes are the + responsibility of the evaluation authorities that run such + schemes and processes and are outside the scope of the CC. + This clause presents the general concepts used throughout the + CC, including the context in which the concepts are to be used + and the CC approach for applying the concepts. CC Part 2 and CC + Part 3, which are obliged to be consulted by users of the CC + Part 1, expand on the use of these concepts and assume that the + approach described is used. Further, for users of the CC who + intend to perform evaluation activities the CEM is + applicable. This clause assumes some knowledge of IT security + and does not propose to act as a tutorial in this area. + The CC discusses security using a set of security + concepts and terminology. An understanding of these concepts and + the terminology is a prerequisite to the effective use of + the CC. However, the concepts themselves are quite + general and are not intended to restrict the class of IT + security problems to which the CC is applicable. + Security is concerned with the protection of assets. Assets + are entities that someone places value upon. Examples of + assets include: + contents of a file or a server;the authenticity of votes cast in an election;the availability of an electronic commerce + process;the ability to use an expensive printer;access to a classified facility. + but given that value is highly subjective, almost anything can + be an asset. + The environment(s) in which these assets are located is called + the operational environment. Examples of (aspects of) + operational environments are: + + the computer room of a bank; + + a computer network connected to the Internet; + + a LAN; + + a general office environment. + + Many assets are in the form of information that is stored, + processed and transmitted by IT products to meet requirements + laid down by owners of the information. Information owners may + require that availability, dissemination and modification of + any such information are strictly controlled and that the + assets are protected from threats by countermeasures. Figure + illustrates these + high level concepts and relationships.
+ Safeguarding assets of interest is the responsibility of + owners who place value on those assets. Actual or presumed + threat agents may also place value on the assets and seek to + abuse assets in a manner contrary to the interests of the + owner. Examples of threat agents include hackers, malicious + users, non-malicious users (who sometimes make errors), + computer processes and accidents. + The owners of the assets will perceive such threats as + potential for impairment of the assets such that the value of + the assets to the owners would be reduced. Security-specific + impairment commonly includes, but is not limited to: loss of + asset confidentiality, loss of asset integrity and loss of + asset availability. + These threats therefore give rise to risks to the assets, + based on the likelihood of a threat being realised and the + impact on the assets when that threat is + realised. Subsequently countermeasures are imposed to reduce + the risks to assets. These countermeasures may consist of IT + countermeasures (such as firewalls and smart cards) and non-IT + countermeasures (such as guards and procedures). See also + ISO/IEC 27001 and ISO/IEC 27002 for a more general discussion + on security countermeasures (controls). + Owners of assets may be (held) responsible for those assets + and therefore should be able to defend the decision to accept + the risks of exposing the assets to the threats. + Two important elements in defending this decision are being + able to demonstrate that: + + the countermeasures are sufficient: if the countermeasures do what + they claim to do, the threats to the assets are countered; + + the countermeasures are correct: the countermeasures do + what they claim to do. + + Many owners of assets lack the knowledge, expertise or + resources necessary to judge sufficiency and correctness of + the countermeasures, and they may not wish to rely solely on + the assertions of the developers of the countermeasures. These + consumers may therefore choose to increase their confidence in + the sufficiency and correctness of some or all of their + countermeasures by ordering an evaluation of these + countermeasures.
+ In an evaluation, sufficiency of the countermeasures is + analysed through a construct called the Security Target. In + this Subclause a simplified view on this construct is + provided: a more detailed and complete description may be + found in . + The Security Target begins with describing the assets and + the threats to those assets. The Security Target then + describes the countermeasures (in the form of Security + Objectives) and demonstrates that these countermeasures are + sufficient to counter these threats: if the countermeasures + do what they claim to do, the threats are countered. + The Security Target then divides these countermeasures in + two groups: + + the security objectives for the TOE: these describe the + countermeasure(s) for which correctness will be + determined in the evaluation; + + the security objectives for the Operational Environment: + these describe the countermeasures for which correctness + will not be determined in the evaluation. + + The reasons for this division are: + + The CC is only suitable for assessing the + correctness of IT countermeasures. Therefore the non-IT + countermeasures (e.g. human security guards, procedures) + are always in the Operational Environment. + + Assessing correctness of countermeasures costs time and + money, possibly making it infeasible to assess the + correctness of all IT countermeasures. + + The correctness of some IT countermeasures may already + have been assessed in another evaluation. It is + therefore not cost-effective to assess this correctness + again. + + For the TOE (the IT countermeasures whose correctness will + be assessed during the evaluation), the Security Target + requires a further detailing of the security objectives for + the TOE in Security Functional Requirements (SFRs). These + SFRs are formulated in a standardised language (described in + CC Part 2) to ensure exactness and facilitate comparability. + In summary, the Security Target demonstrates that: + + The SFRs meet the security objectives for the TOE; + + The security objectives for the TOE and the security + objectives for the operational environment counter the + threats; + + And therefore, the SFRs and the security objectives for + the operational environment counter the threats. + + From this it follows that a correct TOE (meeting the SFRs) + in combination with a correct operational environment + (meeting the security objectives for the operational + environment) will counter the threats. In the next two + subclauses correctness of the TOE and correctness of the + operational environment are discussed separately. + A TOE may be incorrectly designed and implemented, and may + therefore contain errors that lead to vulnerabilities. By + exploiting these vulnerabilities, attackers may still damage + and/or abuse the assets. + These vulnerabilities may arise from accidental errors made + during development, poor design, intentional addition of + malicious code, poor testing etc. + To determine correctness of the TOE, various activities can + be performed such as: + + testing the TOE; + + examining various design representations of the TOE; + + examining the physical security of the development + environment of the TOE. + + The Security Target provides a structured description of + these activities to determine correctness in the form of + Security Assurance Requirements (SARs). These SARs are + formulated in a standardised language (described in CC Part + 3) to ensure exactness and facilitate comparability. + If the SARs are met, there exists assurance in the + correctness of the TOE and the TOE is therefore less likely + to contain vulnerabilities that can be exploited by + attackers. The amount of assurance that exists in the + correctness of the TOE is determined by the SARs themselves: + a few ``weak'' SARs will lead to a little assurance, a lot + of ``strong'' SARs will lead to a lot of assurance. + The operational environment may also be incorrectly designed + and implemented, and may therefore contain errors that lead + to vulnerabilities. By exploiting these vulnerabilities, + attackers may still damage and/or abuse the assets. + However, in the CC, no assurance is obtained + regarding the correctness of the operational + environment. Or, in other words, the operational environment + is not evaluated (see the next Subclause). + As far as the evaluation is concerned, the operational + environment is assumed to be a 100% correct instantiation of + the security objectives for the operational environment. + This does not preclude a consumer of the TOE from using + other methods to determine the correctness of his + operational environment, such as: + + If, for an OS TOE, the security objectives for the + operational environment state ``The operational + environment shall ensure that entities from an untrusted + network (e.g. the Internet) can only access the TOE by + ftp'', the consumer could select an evaluated firewall, + and configure it to only allow ftp access to the TOE; + + If the security objectives for the operational + environment state ``The operational environment shall + ensure that all administrative personnel will not behave + maliciously'', the consumer could adapt his contracts + with administrative personnel to include punitive + sanctions for malicious behaviour, but this + determination is not part of a CC evaluation. + + The CC recognises two types of evaluation: an ST/TOE + evaluation, which is described below, and an evaluation of + PPs, which is defined in CC Part 3. In many places, + the CC uses the term evaluation (without qualifiers) to + refer to an ST/TOE evaluation. + In the CC an ST/TOE evaluation proceeds in two steps: + + An ST evaluation: where the sufficiency of the TOE and the + operational environment are determined; + + A TOE evaluation: where the correctness of the TOE is + determined. As said earlier, the TOE evaluation does not + assess correctness of the operational environment. + + The ST evaluation is carried out by applying the Security + Target evaluation criteria (which are defined in CC Part 3) to + the Security Target. The precise method to apply the criteria is determined by the evaluation + methodology that is used. + The TOE evaluation is more complex. The principal inputs to a + TOE evaluation are: the evaluation evidence, which includes + the TOE and ST, but will usually also include input from the + development environment, such as design documents or developer + test results. + The TOE evaluation consists of applying the SARs (from the + Security Target) to the evaluation evidence. The precise + method to apply a specific SAR is determined by the evaluation + methodology that is used. + How the results of applying the SARs are documented, and what + reports need to be generated and in what detail, is determined + by both the evaluation methodology that is used and the + evaluation scheme under which the evaluation is carried out. + The result of the TOE evaluation process is either: + + A statement that not all SARs have been met and that + therefore there is not the specified level of assurance + that the TOE meets the SFRs as stated in the ST; + + A statement that all SARs have been met, and that + therefore there is the specified level of assurance that + the TOE meets the SFRs as stated in the ST. + + The TOE evaluation may be carried out after TOE development + has finished, or in parallel with TOE development. + The method of stating ST/TOE evaluation results is described + in Clause . These results also + identify the PP(s) and package(s) to which the TOE claims + conformance, and these constructs are described in the next + Clause. + The CC functional and assurance components may be used exactly + as defined in CC Part 2 and CC Part 3, or they may be tailored + through the use of permitted operations. When using + operations, the PP/ST author should be careful that the + dependency needs of other requirements that depend on this + requirement are satisfied. The permitted operations are + selected from the following set: + + Iteration: allows a component to be used more than once + with varying operations; + + Assignment: allows the specification of parameters; + + Selection: allows the specification of one or more items + from a list; and + + Refinement: allows the addition of details. + + The assignment and selection operations are permitted only + where specifically indicated in a component. Iteration and + refinement are permitted for all components. The operations + are described in more detail below. + The CC Part 2 Annexes provide the guidance on the valid + completion of selections and assignments. This guidance + provides normative instructions on how to complete operations, + and those instructions shall be followed unless the PP/ST + author justifies the deviation: + + ``None'' is only available as a choice for the completion + of a selection if explicitly provided. + + The lists provided for the completion of selections must + be non-empty. If a ``None'' option is chosen, no + additional selection options may be chosen. If ``None'' + is not given as an option in a selection, it is + permissible to combine the choices in a selection with + ``and''s and ``or''s, unless the selection explicitly + states ``choose one of''. + Selection operations may be combined by iteration where + needed. In this case, the applicability of the option + chosen for each iteration should not overlap the subject + of the other iterated selection, since they are intended + to be exclusive. + For the completion of assignments, the CC Part 2 Annexes + shall be consulted in order to determine when ``None'' + would be a valid completion. + + The iteration operation may be performed on every + component. The PP/ST author performs an iteration operation + by including multiple requirements based on the same + component. Each iteration of a component shall be different + from all other iterations of that component, which is + realised by completing assignments and selections in a + different way, or by applying refinements to it in a + different way. + Different iterations should be uniquely identified to allow + clear rationales and tracings to and from these + requirements. + It is important to note that sometimes an iteration + operation can be used with components where could also be + possible to perform an assignment operation with a range or + list of values instead of iterate them. In that case the + author can select the most appropriate alternative, + considering if there is a necessity of providing a whole + rationale for the range of values or if it is necessary to + have a separate one for each of them. The author should also + keep in mind if individual traces are required for those + values. + An assignment operation occurs where a given component + contains an element with a parameter that may be set by the + PP/ST author. The parameter may be an unrestricted variable, + or a rule that narrows the variable to a specific range of + values. + Whenever an element in a PP contains an assignment, a PP + author shall do one of four things: + + leave the assignment uncompleted. The PP author could + include ``When the + defined number of unsuccessful authentication attempts + has been met or surpassed, the TSF shall + [assignment: list of actions].'' in the PP. + + complete the assignment. As an example, the PP author + could include ``When + the defined number of unsuccessful authentication + attempts has been met or surpassed, the TSF shall + prevent that external entity from binding to any + subject in the future.'' in the PP. + + narrow the assignment, to further limit the range of + values that is allowed. As an example, the PP author + could include ``The + TSF shall detect when [assignment: positive + integer between 4 and 9] unsuccessful authentication + attempts occur ...'' in the PP. + + transform the assignment to a selection, thereby + narrowing the assignment. As an example, the PP author + could include ``When + the defined number of unsuccessful authentication + attempts has been met or surpassed, the TSF shall + [selection: prevent that user from binding to any + subject in the future, notify the + administrator].'' in the PP. + + Whenever an element in an ST contains an assignment, an ST + author shall complete that assignment, as indicated in b) + above. Options a), c) and d) are not allowed for STs. + The values chosen in options b), c) and d) shall conform to + the indicated type required by the assignment. + When an assignment is to be completed with a set + (e.g. subjects), one may list a set of subjects, but also + some description of the set from which the elements of the + set can be derived such as: + + all subjects + + all subjects of type X + + all subjects except subject a + + as long as it is clear which subjects are meant. + + The selection operation occurs where a given component + contains an element where a choice from several items has to + be made by the PP/ST author. + Whenever an element in a PP contains a selection, the PP + author may do one of three things: + + leave the selection uncompleted. + + complete the selection by choosing one or more items. + + restrict the selection by removing some of the choices, + but leaving two or more. + + Whenever an element in an ST contains a selection, an ST + author shall complete that selection, as indicated in b) + above. Options a) and c) are not allowed for STs. + The item or items chosen in b) and c) shall be taken from + the items provided in the selection. + The refinement operation can be performed on every + requirement. The PP/ST author performs a refinement by + altering that requirement. The first rule for a refinement + is that a TOE meeting the refined requirement also meets the + unrefined requirement in the context of the PP/ST (i.e. a + refined requirement must be ``stricter'' than the original + requirement). If a refinement does not meet this rule, the + resulting refined requirement is considered to be an + extended requirement and shall be treated as such. + The first rule for a refinement is that a TOE meeting the + refined requirement also meets the unrefined requirement in + the context of the PP/ST (i.e. a refined requirement must be + ``stricter'' than the original requirement) + The only exception to this rule is that a PP/ST author is + allowed to refine a SFR to apply to some but not all + subjects, objects, operations, security attributes and/or + external entities. + However, this exception does not apply to refining SFRs that + are taken from PPs that compliance is being claimed to; + these SFRs may not be refined to apply to fewer subjects, + objects, operations, security attributes and/or external + entities than the SFR in the PP. + The second rule for a refinement is that the refinement + shall be related to the original component. + A special case of refinement is an editorial refinement, + where a small change is made in a requirement, + i.e. rephrasing a sentence due to adherence to proper + English grammar, or to make it more understandable to the + reader. This change is not allowed to modify the meaning of + the requirement in any way. + Dependencies may exist between components. Dependencies arise + when a component is not self sufficient and relies upon the + presence of another component to provide security + functionality or assurance. + The functional components in CC Part 2 typically have + dependencies on other functional components as do some of the + assurance components in CC Part 3 which may have dependencies + on other CC Part 3 components. CC Part 2 dependencies on CC + Part 3 components may also be defined. However, this does not + preclude extended functional components having dependencies on + assurance components or vice versa. + Component dependency descriptions are determined by consulting + the CC Part 2 and CC Part 3 component definitions. In order to + ensure completeness of the TOE security requirements, + dependencies should be satisfied when requirements based on + components with dependencies are incorporated into PPs and + STs. Dependencies should also be considered when constructing + packages. + In other words: if component A has a dependency on component + B, this means that whenever a PP/ST contains a security + requirement based on component A, the PP/ST shall also contain + one of : + + a security requirement based on component B, or + + a security requirement based on a component that is + hierarchically higher than B, or + + a justification why the PP/ST does not contain a security + requirement based on component B. + + In cases a) and b), when a security requirement is included + because of a dependency, it may be necessary to complete + operations (assignment, iteration, refinement, selection) on + that security requirement in a particular manner to make sure + that it actually satisfies the dependency. + In case c), the justification that a security requirement is + not included should address either: + + why the dependency is not necessary or useful, or + + that the dependency has been addressed by the operational + environment of the TOE, in which case the justification + should describe how the security objectives for the + operational environment address this dependency, or + + that the dependency has been addressed by the other SFRs + in some other manner (extended SFRs, combinations of SFRs + etc.) + + In the CC it is mandatory to base requirements on + components from CC Part 2 or CC Part 3 with two + exceptions: + + there are security objectives for the TOE that can not be + translated to Part 2 SFRs, or there are third party + requirements (e.g., laws, standards) that can not be + translated to Part 3 SARs (e.g. regarding evaluation of + cryptography); + + a security objective can be translated, but only with + great difficulty and/or complexity based on components in + CC Part 2 and/or CC Part 3. + + In both cases the PP/ST author is required to define his own + components. These newly defined components are called extended + components. A precisely defined extended component is needed + to provide context and meaning to the extended SFRs and SARs + based on that component. + After the new components have been defined correctly, the + PP/ST author can then base one or more SFRs or SARs on these + newly defined extended components and use them in the same way + as the other SFRs and SARs. From this point on, there is no + further distinction between SARs and SFRs based on the CC and + SARs and SFRs based on extended components. Refer to CC Part 3 + and for further + requirements on extended components. + To allow consumer groups and communities of interest to + express their security needs, and to facilitate writing STs, + this part of the CC provides two special constructs: packages + and Protection Profiles (PPs). In the following two subclauses + these constructs are described in more detail, followed by a + subclause on how these constructs can be used. + A package is a named set of security requirements. A package + is either + + a functional package, containing only SFRs, or + + an assurance package, containing only SARs. + + Mixed packages containing both SFRs and SARs are not allowed. + A package can be defined by any party and is intended to be + re-usable. To this goal it should contain requirements that + are useful and effective in combination. Packages can be used + in the construction of larger packages, PPs and STs. At + present there are no criteria for the evaluation of packages, + therefore any set of SFRs or SARs can be a package. + Examples of assurance packages are the evaluation assurance + levels (EALs) that are defined in CC Part 3. At the time + of writing there are no functional packages for this version + of the CC. + Whereas an ST always describes a specific TOE (e.g. the + MinuteGap v18.5 Firewall), a PP is intended to describe a TOE + type (e.g. firewalls). The same PP may therefore be used as a + template for many different STs to be used in different + evaluations. A detailed description of PPs is given in  . + In general an ST describes requirements for a TOE and is + written by the developer of that TOE, while a PP describes + the general requirements for a TOE type, and is therefore + typically written by: + + A user community seeking to come to a consensus on the + requirements for a given TOE type; + + A developer of a TOE, or a group of developers of + similar TOEs wishing to establish a minimum baseline for + that type of TOE; + + A government or large corporation specifying its + requirements as part of its acquisition process. + + The PP determines the allowed type of conformance of the ST + to the PP. That is, the PP states (in the PP conformance + statement, see subclause ) + what the allowed types of conformance for the ST are: + + if the PP states that strict conformance is required, + the ST shall conform to the PP in a strict manner; + + if the PP states that demonstrable conformance is + required, the ST shall conform to the PP in a strict or + demonstrable manner. + + Restating this in other words, an ST is only allowed to + conform in a PP in a demonstrable manner, if the PP + explicitly allows this. + If an ST claims conformance to multiple PPs, it shall + conform (as described above) to each PP in the manner + ordained by that PP. This may mean that the ST conforms + strictly to some PPs and demonstrably to other PPs. + Note that either the ST conforms to the PP in question or it + does not. The CC does not recognise ``partial'' + conformance. It is therefore the responsibility of the PP + author to ensure the PP is not overly onerous, prohibiting + PP/ST authors in claiming conformance to the PP. + An ST is equivalent or more restrictive than a PP if: + + all TOEs that meet the ST also meet the PP, and + + all operational environments that meet the PP also meet + the ST. + + or, informally, the ST shall levy the same or more, + restrictions on the TOE and the same or less restrictions on + the operational environment of the TOE. + This general statement can be made more specific for various + subclauses of the ST: + Security problem definition: The + conformance rationale in the ST shall demonstrate that + the security problem definition in the ST is equivalent + (or more restrictive) than the security problem + definition in the PP. This means that: + + all TOEs that would meet the security problem + definition in the ST also meet the security problem + definition in the PP; + + all operational environments that would meet the + security problem definition in the PP would also + meet the security problem definition in the ST. + Security objectives: The conformance + rationale in the ST shall demonstrate that the security + objectives in the ST is equivalent (or more restrictive) + than the security objectives in the PP. This means that: + + all TOEs that would meet the security objectives for + the TOE in the ST also meet the security objectives + for the TOE in the PP; + + all operational environments that would meet the + security objectives for the operational environment + in the PP would also meet the security objectives + for the operational environment in the ST. + + If strict conformance for protection profiles is specified + then the following requirements apply: + Security problem definition: The ST shall + contain the security problem definition of the PP, may + specify additional threats and OSPs, but may not specify + additional assumptions. + Security objectives: The ST: + + shall contain all security objectives for the TOE of + the PP but may specify additional security + objectives for the TOE; + + shall contain all security objectives for the + operational environment (with one exception in the + next bullet) but may not specify additional security + objectives for the operational environment; + + may specify that certain objectives for the + operational environment in the PP are security + objectives for the TOE in the ST. This is called + re-assigning a security objective. If a security + objective is re-assigned to the TOE the security + objectives rationale has to make clear which + assumption or part of the assumption is not + necessary any more. + Security requirements: The ST shall contain + all SFRs and SARs in the PP, but may claim additional or + hierarchically stronger SFRs and SARs. The completion of + operations in the ST must be consistent with that in the + PP; either the same completion will be used in the ST as + that in the PP or one that makes the requirement more + restrictive (the rules of refinement apply). + + If demonstrable conformance for protection profiles is + specified then the following requirements apply: + + the ST shall contain a rationale on why the ST is + considered to be ``equivalent or more restrictive'' than + the PP. + + Demonstrable conformance allows a PP author to describe + a common security problem to be solved and provide + generic guidelines to the requirements necessary for its + resolution, in the knowledge that there is likely to be + more than one way of specifying a resolution. + + PP evaluation is optional. Evaluation is performed by applying + the criteria to them as listed in + CC Part 3. The goal of such an evaluation is to demonstrate + that the PP is complete, consistent, and technically sound and + suitable for use as a template on which to build another PP or + an ST. + Basing a PP/ST on an evaluated PP has two advantages: + + There is much less risk that there are errors, ambiguities + or gaps in the PP. If any problems with a PP (that would + have been caught by evaluating that PP) are found during + the writing or evaluation of the new ST, significant time + may elapse before the PP is corrected. + + Evaluation of the new PP/ST may often re-use evaluation + results of the evaluated PP, resulting in less effort + for evaluating the new PP/ST. +
+ If an ST claims to be conformant to one or more packages + and/or Protection Profiles, the evaluation of that ST will + (among other properties of that ST) demonstrate that the ST + actually conforms to these packages and/or PPs that they claim + conformance to. Details of this determination of conformance + can be found in . + This allows the following process: + + An organisation seeking to acquire a particular type of + IT security product develops their security needs into a + PP, then has this evaluated and publishes it; + + A developer takes this PP, writes an ST that claims + conformance to the PP and has this ST evaluated; + + The developer then builds a TOE (or uses an existing + one) and has this evaluated against the ST. + + The result is that the developer can prove that his TOE is + conformant to the security needs of the organisation: the + organisation can therefore acquire that TOE. A similar line of + reasoning applies to packages. + The CC also allows PPs to conform to other PPs, allowing + chains of PPs to be constructed, each based on the previous + one(s). + For instance, one could take a PP for an Integrated Circuit + and a PP for a Smart Card OS, and use these to construct a + Smart Card PP (IC and OS) that claims conformance to the + other two. One could then write a PP on Smart Cards for + Public Transport based on the Smart Card PP and a PP on + Applet Loading. Finally, a developer could then construct an + ST based on this Smart Cards for Public Transport PP. + This clause presents the expected results from PP and ST/TOE + evaluations performed according to the CEM. + PP evaluations lead to catalogues of evaluated PPs. + An ST evaluation leads to intermediate results that are used + in the frame of a TOE evaluation. + ST/TOE evaluations lead to catalogues of evaluated TOEs. In + many cases these catalogues will refer to the IT products that + the TOEs are derived from rather than the specific + TOE. Therefore, the existence of an IT product in a catalogue + should not be construed as meaning that the whole IT product + has been evaluated; instead the actual extent of the ST/TOE + evaluation is defined by the ST. Refer to the bibliography for + examples of such catalogues.
+ STs may be based on packages, evaluated PPs or non-evaluated + PPs - however this is not mandatory, as STs do not have to be + based on anything at all. + Evaluation should lead to objective and repeatable results + that can be cited as evidence, even if there is no absolute + objective scale for representing the results of a security + evaluation. The existence of a set of evaluation criteria is a + necessary pre-condition for evaluation to lead to a meaningful + result and provides a technical basis for mutual recognition + of evaluation results between evaluation authorities. + An evaluation result represents the findings of a specific + type of investigation of the security properties of a + TOE. Such a result does not automatically guarantee fitness + for use in any particular application environment. The + decision to accept a TOE for use in a specific application + environment is based on consideration of many security issues + including the evaluation findings. + CC Part 3 contains the evaluation criteria that an evaluator + is obliged to consult in order to state whether a PP is + complete, consistent, and technically sound and hence suitable + for use in developing an ST. + The results of the evaluation shall also include a + ``Conformance Claim'' (see Subclause )). + CC Part 3 contains the evaluation criteria that an evaluator + is obliged to consult in order to determine whether + sufficient assurance exists that the TOE satisfies the SFRs + in the ST. Evaluation of the TOE shall therefore result in a + pass/fail statement for the ST. If both the ST and the TOE + evaluation have resulted in a pass statement, the underlying + product is eligible for inclusion in a registry. The results + of evaluation shall also include a ``Conformance Claim'' as + defined in the next subclause. + It may be the case that the evaluation results are + subsequently used in a certification process, but this + certification process is outside the scope of the CC. + 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 +   . + + Once an ST and a TOE have been evaluated, asset owners can + have the assurance (as defined in the ST) that the TOE, + together with the operational environment, counters the + threats. The evaluation results may be used by the asset + owner in deciding whether to accept the risk of exposing the + assets to the threats. + However, the asset owner should carefully check whether: + + the Security Problem Definition in the ST matches the + security problem of the asset owner; + + the Operational Environment of the asset owner conforms + (or can be made to conform) to the security objectives + for the Operational Environment described in the ST. + + If either of these is not the case, the TOE may not be + suitable for the purposes of the asset owner. + Additionally, once an evaluated TOE is in operation, it is + still possible that previously unknown errors or + vulnerabilities in the TOE may surface. In that case, the + developer may correct the TOE (to repair the + vulnerabilities) or change the ST to exclude the + vulnerabilities from the scope of the evaluation. In either + case, the old evaluation results may no longer be valid. + If it is deemed necessary that confidence is regained, + re-evaluation is needed. The CC may be used for this + re-evaluation, but detailed procedures for re-evaluation are + outside the scope of this part of the CC. + The goal of this annex is to explain the Security Target (ST) + concept. This annex does not define the criteria; this definition can be found in CC Part + 3 and is supported by the documents given in the bibliography. + This annex consists of four major parts: + What an ST must contain. This is + summarised in Subclause , and described in more detail + in Subclauses - . These subclauses describe the + mandatory contents of the ST, the interrelationships + between these contents, and provide examples. + How an ST should be used. This is + summarised in Subclause , and described in more detail in + subclause . These + subclauses describe how an ST should be used, and some of + the questions that can be answered with an ST. + Low Assurance STs. Low Assurance STs are + STs with reduced content. They are described in detail in + subclause . + Claiming compliance with + standards. Subclause describes how an ST writer can claim that + the TOE meets a particular standard. + + Figure portrays the mandatory + contents of an ST that are given in CC Part 3. Figure may also be used as a structural outline + of the ST, though alternative structures are allowed. For + instance, if the security requirements rationale is + particularly bulky, it could be included in an appendix of the + ST instead of in the security requirements subclause. The + separate subclauses of an ST and the contents of those + subclauses are briefly summarised below and explained in much + more detail in subclauses to . An ST normally contains: + an ST introduction containing three + narrative descriptions of the TOE on different levels of + abstraction; + a conformance claim, showing whether the + ST claims conformance to any PPs and/or packages, and if + so, to which PPs and/or packages; + a security problem definition, showing + threats, OSPs and assumptions; + security objectives, showing how the + solution to the security problem is divided between + security objectives for the TOE and security objectives + for the operational environment of the TOE; + extended components definition + (optional), where new components (i.e. those not included + in CC Part 2 or CC Part 3) may be defined. These new + components are needed to define extended functional and + extended assurance requirements; + security requirements, where a + translation of the security objectives for the TOE into a + standardised language is provided. This standardised + language is in the form of SFRs. Additionally this + subclause defines the SARs; + a TOE summary specification, showing how + the SFRs are implemented in the TOE. + + There also exists low assurance STs which have reduced + contents; these are described in detail in subclause . All other parts of this Annex assume an ST + with full contents.
+ A typical ST fulfils two roles: + + Before and during the evaluation, the ST specifies + ``what is to be evaluated''. In this role, the ST serves + as a basis for agreement between the developer and the + evaluator on the exact security properties of the TOE + and the exact scope of the evaluation. Technical + correctness and completeness are major issues for this + role. Subclause describes how + the ST should be used in this role. + + After the evaluation, the ST specifies ``what was + evaluated''. In this role, the ST serves as a basis for + agreement between the developer or re-seller of the TOE + and the potential consumer of the TOE. The ST describes + the exact security properties of the TOE in an abstract + manner, and the potential consumer can rely on this + description because the TOE has been evaluated to meet + the ST. Ease of use and understandability are major + issues for this role. Subclause describes how the ST should be used + in this role. + + Two roles (among many) that an ST should not fulfil are: + a detailed specification: An ST is + designed to be a security specification on a relatively + high level of abstraction. An ST should, in general, not + contain detailed protocol specifications, detailed + descriptions of algorithms and/or mechanisms, long + description of detailed operations etc. + a complete specification: An ST is + designed to be a security specification and not a + general specification. Unless security-relevant, + properties such as interoperability, physical size and + weight, required voltage etc. should not be part of an + ST. This means that in general an ST may be a part of a + complete specification, but not a complete specification + itself. + + The ST introduction describes the TOE in a narrative way on + three levels of abstraction: + + the ST reference and the TOE reference, which provide + identification material for the ST and the TOE that the ST + refers to; + + the TOE overview, which briefly describes the TOE; + + the TOE description, which describes the TOE in more + detail. + + An ST contains a clear ST reference that identifies that + particular ST. A typical ST reference consists of title, + version, authors and publication date. An example of an ST + reference is ``MauveRAM Database ST, version 1.3, MauveCorp + Specification Team, 11 October 2002''. + An ST also contains a TOE reference that identifies the TOE + that claims conformance to the ST. A typical TOE reference + consists of developer name, TOE name and TOE version + number. An example of a TOE reference is ``MauveCorp + MauveRAM Database v2.11''. As a single TOE may be evaluated + multiple times, for instance by different consumers of that + TOE, and therefore have multiple STs, this reference is not + necessarily unique. + If the TOE is constructed from one or more well-known + products, it is allowed to reflect this in the TOE + reference, by referring to the product name(s). However, + this should not be used to mislead consumers: situations + where major parts or security functionalities were not + considered in the evaluation, yet the TOE reference does not + reflect this are not allowed. + The ST reference and the TOE reference facilitate indexing + and referencing the ST and TOE and their inclusion in + summaries of lists of evaluated TOEs/Products. + The TOE overview is aimed at potential consumers of a TOE + who are looking through lists of evaluated TOEs/Products to + find TOEs that may meet their security needs, and are + supported by their hardware, software and firmware. The + typical length of a TOE overview is several paragraphs. + To this end, the TOE overview briefly describes the usage of + the TOE and its major security features, identifies the TOE + type and identifies any major non-TOE + hardware/software/firmware required by the TOE. + The description of the usage and major security features + of the TOE is intended to give a very general idea of what + the TOE is capable of in terms of security, and what it + can be used for in a security context. This subclause + should be written for (potential) TOE consumers, + describing TOE usage and major security features in terms + of business operations, using language that TOE consumers + understand. + An example of this is ``The MauveCorp MauveRAM Database + v2.11 is a multi-user database intended to be used in a + networked environment. It allows 1024 users to be active + simultaneously. It allows password/token and biometric + authentication, protects against accidental data + corruption, and can roll-back ten thousand + transactions. Its audit features are highly configurable, + so as to allow detailed audit to be performed for some + users and transactions, while protecting the privacy of + other users and transactions.'' + The TOE overview identifies the general type of TOE, such + as: firewall, VPN-firewall, smart card, crypto-modem, + intranet, web server, database, web server and database, + LAN, LAN with web server and database, etc. + It may be the case that the TOE is not of a readily + available type, in which case ``none'' would be + acceptable. + In some cases, a TOE type can mislead consumers. Examples include: + + certain functionality can be expected of the TOE + because of its TOE type, but the TOE does not have + this functionality. Examples include: + + an ATM-card type TOE, which does not support any + identification/authentication functionality; + + a firewall type TOE, which does not support + protocols that are almost universally used; + + a PKI-type TOE, which has no certificate + revocation functionality. + + the TOE can be expected to operate in certain + operational environments because of its TOE type, but + it cannot do so. Examples include: + + a PC-operating system type TOE, which is unable to + function securely unless the PC has no network + connection, floppy drive, and CD/DVD-player; + + a firewall, which is unable to function securely + unless all users that can connect through that + firewall are benign. + + While some TOEs do not rely upon other IT, many TOEs + (notably software TOEs) rely on additional, non-TOE, + hardware, software and/or firmware. In the latter case, + the TOE overview is required to identify such non-TOE + hardware,software and/or firmware . A complete and fully + detailed identification of the additional hardware, + software and/or firmware is not necessary, but the + identification should be complete and detailed enough for + potential consumers to determine the major + hardware,software and/or firmware needed to use the TOE. + Example hardware/software/firmware identifications are: + + a standard PC with a 1GHz or faster processor and + 512MB or more RAM, running version 3.0 Update 6b, c, + or 7, or version 4.0 of the Yaiza operating system; + + a standard PC with a 1GHz or faster version processor + and 512MB or more RAM, running version 3.0 Update 6d + of the Yaiza operating system and the WonderMagic 1.0 + Graphics card with the 1.0 WM Driver Set; + + a standard PC with version 3.0 of the Yaiza OS (or + higher); + + a CleverCard SB2067 integrated circuit; + + a CleverCard SB2067 integrated circuit running v2.0 of + the QuickOS smart card operating system; + + the December 2002 installation of the LAN of the + Director-General's Office of the Department of + Traffic. + + A TOE description is a narrative description of the TOE, + likely to run to several pages. The TOE description should + provide evaluators and potential consumers with a general + understanding of the security capabilities of the TOE, in + more detail than was provided in the TOE overview. The TOE + description may also be used to describe the wider + application context into which the TOE will fit. + The TOE description discusses the physical scope of the TOE: + a list of all hardware, firmware, software and guidance + parts that constitute the TOE. This list should be described + at a level of detail that is sufficient to give the reader a + general understanding of those parts. + The TOE description should also discuss the logical scope of + the TOE: the logical security features offered by the TOE at + a level of detail that is sufficient to give the reader a + general understanding of those features. This description is + expected to be in more detail than the major security + features described in the TOE overview. + An important property of the physical and logical scopes is + that they describe the TOE in such a way that there remains + no doubt on whether a certain part or feature is in the TOE + or whether this part or feature is outside the TOE. This is + especially important when the TOE is intertwined with and + cannot be easily separated from non-TOE entities. + Examples where the TOE is intertwined with non-TOE entities + are: + + the TOE is a cryptographic co-processor of a smart card + IC, instead of the entire IC; + + the TOE is a smart card IC, except for the cryptographic + processor; + + the TOE is the Network Address Translation part of the + MinuteGap Firewall v18.5. + + This subclause of an ST describes how the ST conforms with: + + Part 2 and Part 3 of this International Standard; + + Protection Profiles (if any); + + Packages (if any). + + The description of how the ST conforms to the CC consists of + two items: the version of the CC that is used and whether the + ST contains extended security requirements or not (see + Subclause ). + The description of conformance of the ST to Protection + Profiles means that the ST lists the packages that conformance + is being claimed to. For an explanation of this, see Subclause + . + The description of conformance of the ST to packages means + that the ST lists the packages that conformance is being + claimed to. For an explanation of this, see Subclause . + The security problem definition defines the security problem + that is to be addressed. The security problem definition is, + as far as the CC is concerned, axiomatic. That is, + the process of deriving the security problem definition + falls outside the scope of the CC. + However, it should be noted that the usefulness of the + results of an evaluation strongly depends on the ST, and the + usefulness of the ST strongly depends on the quality of the + security problem definition. It is therefore often + worthwhile to spend significant resources and use + well-defined processes and analyses to derive a good + security problem definition. + Note that according to CC Part 3 it is not mandatory + to have statements in all subclauses, an ST with threats + does not need to have OSPs and vice versa. Also, any ST may + omit assumptions. + Also note that where the TOE is physically distributed, it + may be better to discuss the relevant threats, OSPs and + assumptions separately for distinct domains of the TOE + operational environment. + This subclause of the security problem definition shows + the threats that are to be countered by the TOE, its + operational environment, or a combination of the two. + A threat consists of an adverse action performed by a + threat agent on an asset. + Adverse actions are actions performed by a threat agent on + an asset. These actions influence one or more properties + of an asset from which that asset derives its value. + Threat agents may be described as individual entities, but + in some cases it may be better to describe them as types + of entities, groups of entities etc. + Examples of threat agents are hackers, users, computer + processes, and accidents. Threat agents may be further + described by aspects such as expertise, resources, + opportunity and motivation. + Examples of threats are: + + a hacker (with substantial expertise, standard + equipment, and being paid to do so) remotely copying + confidential files from a company network; + + a worm seriously degrading the performance of a + wide-area network; + + a system administrator violating user privacy; + + someone on the Internet listening in on confidential + electronic communication. + + This subclause of the security problem definition shows + the OSPs that are to be enforced by the TOE, its + operational environment, or a combination of the two. + OSPs are security rules, procedures, or guidelines imposed + (or presumed to be imposed) now and/or in the future by an + actual or hypothetical organisation in the operational + environment. OSPs may be laid down by an organisation + controlling the operational environment of the TOE, or + they may be laid down by legislative or regulatory + bodies. OSPs can apply to the TOE and/or the operational + environment of the TOE. + Examples of OSPs are: + + All products that are used by the Government must + conform to the National Standard for password + generation and encryption; + + Only users with System Administrator privilege and + clearance of Department Secret shall be allowed to + manage the Department Fileserver. + + This subclause of the security problem definition shows + the assumptions that are made on the operational + environment in order to be able to provide security + functionality. If the TOE is placed in an operational + environment that does not meet these assumptions, the TOE + may not be able to provide all of its security + functionality anymore. Assumptions can be on physical, + personnel and connectivity of the operational environment. + Examples of assumptions are: + + Assumptions on physical aspects of the operational environment: + + It is assumed that the TOE will be placed in a + room that is designed to minimise electromagnetic + emanations; + + It is assumed that the administrator consoles of + the TOE will be placed in a restricted access + area. + + Assumptions on personnel aspects of the operational + environment: + + It is assumed that users of the TOE will be + trained sufficiently in order to operate the TOE; + + It is assumed that users of the TOE are approved + for information that is classified as National + Secret; + + It is assumed that users of the TOE will not write + down their passwords. + + Assumptions on connectivity aspects of the operational + environment: + + It is assumed that a PC workstation with at least + 10GB of disk space is available to run the TOE on; + + It is assumed that the TOE is the only non-OS + application running on this workstation; + + It is assumed that the TOE will not be connected + to an untrusted network. + + Note that during the evaluation these assumptions are + considered to be true: they are not tested in any way. For + these reasons, assumptions can only be made on the + operational environment. Assumptions can never be made on + the behaviour of the TOE because an evaluation consists of + evaluating assertions made about the TOE and not by + assuming that assertions on the TOE are true. + The security objectives are a concise and abstract statement + of the intended solution to the problem defined by the + security problem definition. The role of the security + objectives is threefold: + + provide a high-level, natural language solution of the + problem; + + divide this solution into two part wise solutions, that + reflect that different entities each have to address a + part of the problem; + + demonstrate that these part wise solutions form a + complete solution to the problem. + + The security objectives consist of a set of short and + clear statements without overly much detail that together + form a high-level solution to the security problem. The + level of abstraction of the security objectives aims at + being clear and understandable to knowledgeable potential + consumers of the TOE. The security objectives are in + natural language. + In an ST the high-level security solution, as described by + the security objectives, is divided into two part wise + solutions. These part wise solutions are called the + security objectives for the TOE and the security + objectives for the operational environment. This reflects + that these part wise solutions are to be provided by two + different entities: the TOE, and the operational + environment. + The TOE provides security functionality to solve a + certain part of the problem defined by the security + problem definition. This part wise solution is called + the security objectives for the TOE and consists of a + set of objectives that the TOE should achieve in order + to solve its part of the problem. + Examples of security objectives for the TOE are: + + The TOE shall keep confidential the content of all + files transmitted between it and a Server; + + The TOE shall identify and authenticate all users + before allowing them access to the Transmission + Service provided by the TOE; + + The TOE shall restrict user access to data according + to the Data Access policy described in Annex 3 of + the ST. + + If the TOE is physically distributed, it may be better + to subdivide the ST subclause containing the security + objectives for the TOE into several sub-subclauses to + reflect this. + The operational environment of the TOE implements + technical and procedural measures to assist the TOE in + correctly providing its security functionality (which is + defined by the security objectives for the TOE). This + part wise solution is called the security objectives for + the operational environment and consists of a set of + statements describing the goals that the operational + environment should achieve. + Examples of security objectives for the operational + environment are: + + The operational environment shall provide a + workstation with the OS Inux version 3.01b to + execute the TOE on; + + The operational environment shall ensure that all + human TOE users receive appropriate training before + allowing them to work with the TOE; + + The operational environment of the TOE shall + restrict physical access to the TOE to + administrative personnel and maintenance personnel + accompanied by administrative personnel; + + The operational environment shall ensure the + confidentiality of the audit logs generated by the + TOE before sending them to the central Audit Server. + + If the operational environment of the TOE consists of + multiple sites, each with different properties, it may + be better to subdivide the ST subclause containing the + security objectives for the operational environment into + several sub-subclauses to reflect this. + The ST also contains a security objectives rationale + containing two subclauses: + + a tracing that shows which security objectives + address which threats, OSPs and assumptions; + + a set of justifications that shows that all threats, + OSPs, and assumptions are effectively addressed by + the security objectives. + + The tracing shows how the security objectives trace + back to the threats, OSPs and assumptions as described + in the security problem definition. + No spurious objectives: Each + security objective traces to at least one threat, + OSP or assumption. + Complete with respect to the security + problem definition: Each threat, OSP and + assumption has at least one security objective + tracing to it. + Correct tracing: Since + assumptions are always made by the TOE on the + operational environment, security objectives for + the TOE do not trace back to assumptions. The + tracings allowed by CC Part 3 are depicted in + Figure . +
+ Multiple security objectives may trace to the same + threat, indicating that the combination of those + security objectives counters that threat. A similar + argument holds for OSPs and assumptions. + The security objectives rationale also demonstrates + that the tracing is effective: All the given threats, + OSPs and assumption are addressed (i.e. countered, + enforced and upheld respectively) if all security + objectives tracing to a particular threat, OSP or + assumption are achieved. + This demonstration analyses the effect of achieving + the relevant security objectives on countering the + threats, enforcing the OSPs and upholding the + assumptions and leads to the conclusion that this is + indeed the case. + In some cases, where parts of the security problem + definition very closely resemble some security + objectives, the demonstration can be very simple. An + example is: a threat ``T17: Threat agent X reads the + Confidential Information in transit between A and B'', + a security objective for the TOE: ``OT12: The TOE + shall ensure that all information transmitted between + A and B is kept confidential'', and a demonstration + ``T17 is directly countered by OT12''. + Countering a threat does not necessarily mean removing + that threat, it can also mean sufficiently diminishing + that threat or sufficiently mitigating that threat. + Examples of removing a threat are: + + removing the ability to execute the adverse action + from the threat agent; + + moving, changing or protecting the asset in such a + way that the adverse action is no longer + applicable to it; + + removing the threat agent (e.g. removing machines + from a network that frequently crash that + network). + + Examples of diminishing a threat are: + + restricting the ability of a threat agent to + perform adverse actions; + + restricting the opportunity to execute an adverse + action of a threat agent; + + reducing the likelihood of an executed adverse + action being successful; + + reducing the motivation to execute an adverse + action of a threat agent by deterrence; + + requiring greater expertise or greater resources + from the threat agent. + + Examples of mitigating the effects of a threat are: + + making frequent back-ups of the asset; + + obtaining spare copies of an asset; + + insuring an asset; + + ensuring that successful adverse actions are + always timely detected, so that appropriate action + can be taken. + + Based on the security objectives and the security + objectives rationale, the following conclusion can be + drawn: if all security objectives are achieved then the + security problem as defined in is + solved: all threats are countered, all OSPs are + enforced, and all assumptions are upheld. + In many cases the security requirements (see the next + subclause) in an ST are based on components in CC Part 2 + or CC Part 3. However, in some cases, there may be + requirements in an ST that are not based on components in + CC Part 2 or CC Part 3. In this case, new components + (extended components) must be defined, and this definition + should be done in the Extended Components Definition. For + more information on this, see Annex . + Note that this subclause is intended to contain only the + extended components and not the extended requirements + (requirements based on extended components). The extended + requirements should be included in the security + requirements (see the next subclause) and are for all + purposes the same as requirements based on components in + CC Part 2 or CC Part 3. + The security requirements consist of two groups of + requirements: + the security functional requirements + (SFRs): a translation of the security objectives for the + TOE into a standardised language; + the security assurance requirements + (SARs): a description of how assurance is to be gained + that the TOE meets the SFRs. + + These two groups are discussed in the following two subclauses: + The SFRs are a translation of the security objectives for + the TOE. They are usually at a more detailed level of + abstraction, but they have to be a complete translation + (the security objectives must be completely addressed) and + be independent of any specific technical solution + (implementation). The CC requires this translation into a + standardised language for several reasons: + + to provide an exact description of what is to be + evaluated. As security objectives for the TOE are + usually formulated in natural language, translation + into a standardised language enforces a more exact + description of the functionality of the TOE. + + to allow comparison between two STs. As different ST + authors may use different terminology in describing + their security objectives, the standardised language + enforces using the same terminology and concepts. This + allows easy comparison. + + There is no translation required in the CC for the + security objectives for the operational environment, + because the operational environment is not evaluated and + does therefore not require a description aimed at its + evaluation. See the bibliography for items relevant to the + security assessment of operational systems. + It may be the case that parts of the operational + environment are evaluated in another evaluation, but this + is out of scope for the current evaluation. For example: + an OS TOE may require a firewall to be present in its + operational environment. Another evaluation may + subsequently evaluate the firewall, but this evaluation + has nothing to do with the evaluation of the OS TOE. + The CC supports this translation in three ways: + + by providing a predefined precise ``language'' + designed to describe exactly what is to be + evaluated. This language is defined as a set of + components defined in CC Part 2. The use of this + language as a well-defined translation of the + security objectives for the TOE to SFRs is + mandatory, though some exceptions exist (see + Subclause ). + + by providing operations: mechanisms that allow the + ST writer to modify the SFRs to provide a more + accurate translation of the security objectives for + the TOE. This part of the CC defines the four + allowed operations: assignment, selection, + iteration, and refinement. These are described + further in Subclause . + + by providing dependencies: a mechanism that supports + a more complete translation to SFRs. In the CC Part + 2 language, an SFR can have a dependency on other + SFRs. This signifies that if an ST uses that SFR, it + generally needs to use those other SFRs as + well. This makes it much harder for the ST writer to + overlook including necessary SFRs and thereby + improves the completeness of the ST. Dependencies + are described further in Subclause . + + The ST also contains a security requirements rationale, + consisting of two subclauses about SFRs: + + a tracing that shows which SFRs address which + security objectives for the TOE; + + a set of justifications that shows that all security + objectives for the TOE are effectively addressed by + the SFRs. + + The tracing shows how the SFRs trace back to the + security objectives for the TOE as follows: + No spurious SFRs: Each SFR traces + back to at least one security objective. + Complete with respect to the security + objectives for the TOE: Each security + objective for the TOE has at least one SFR tracing + to it. + + Multiple SFRs may trace to the same security objective + for the TOE, indicating that the combination of those + security requirements meets that security objective + for the TOE. + The security requirements rationale demonstrates that + the tracing is effective: if all SFRs tracing to a + particular security objective for the TOE are + satisfied, that security objective for the TOE is + achieved. + This demonstration should analyse the effects of + satisfying the relevant SFRs on achieving the security + objective for the TOE and lead to the conclusion that + this is indeed the case. + In cases where SFRs very closely resemble security + objectives for the TOE, the demonstration can be very + simple. + The SARs are a description of how the TOE is to be + evaluated. This description uses a standardised language + for two reasons: + + to provide an exact description of how the TOE is to + be evaluated. Using a standardised language assists in + creating an exact description and avoids ambiguity. + + to allow comparison between two STs. As different ST + authors may use different terminology in describing + the evaluation, the standardised language enforces + using the same terminology and concepts. This allows + easy comparison. + + This standardised language is defined as a set of + components defined in CC Part 3. The use of this + language is mandatory, though some exceptions + exist. The CC enhances this language in two ways: + + by providing operations: mechanisms that allow the ST + writer to modify the SARs. The CC has four operations: + assignment, selection, iteration, and + refinement. These are described further in Subclause + . + + by providing dependencies: a mechanism that supports a + more complete translation to SARs. In CC Part 3 + language, an SAR can have a dependency on other + SARs. This signifies that if an ST uses that SAR, it + generally needs to use those other SARs as well. This + makes it much harder for the ST writer to overlook + including necessary SARs and thereby improves the + completeness of STs. Dependencies are described + further in Subclause . + + The ST also contains a security requirements rationale + that explains why this particular set of SARs was deemed + appropriate. There are no specific requirements for this + explanation. The goal for this explanation is to allow the + readers of the ST to understand the reasons why this + particular set was chosen. + An example of an inconsistency is if the security problem + description mentions threats where the threat agent is + very capable, and a low (or no) is + included in the SARs. + In the security problem definition of the ST, the security + problem is defined as consisting of threats, OSPs and + assumptions. In the security objectives subclause of the + ST, the solution is provided in the form of two + sub-solutions: + + security objectives for the TOE; + + security objectives for the operational environment. + + Additionally, a security objectives rationale is provided + showing that if all security objectives are achieved, the + security problem is solved: all threats are countered, all + OSPs are enforced, and all assumptions are upheld.
+ In the security requirements subclause of the ST, the + security objectives for the TOE are translated to SFRs and + a security requirements rationale is provided showing that + if all SFRs are satisfied, all security objectives for the + TOE are achieved. + Additionally, a set of SARs is provided to show how the + TOE is evaluated, together with an explanation for + selecting these SARs. + All of the above can be combined into the statement: If + all SFRs and SARs are satisfied and all security + objectives for the operational environment are achieved, + then there exists assurance that the security problem as + defined in is solved: all + threats are countered, all OSPs are enforced, and all + assumptions are upheld. This is illustrated in Figure + . + The amount of assurance obtained is defined by the SARs, + and whether this amount of assurance is sufficient is + defined by the explanation for choosing these SARs. + The objective for the TOE summary specification is to provide + potential consumers of the TOE with a description of how the + TOE satisfies all the SFRs. The TOE summary specification + should provide the general technical mechanisms that the TOE + uses for this purpose. The level of detail of this description + should be enough to enable potential consumers to understand + the general form and implementation of the TOE. + For instance if the TOE is an Internet PC and the SFRs contain + to specify authentication, + the TOE summary specification should indicate how this + authentication is done: password, token, iris scanning + etc. More information, like applicable standards that the TOE + uses to meet SFRs, or more detailed descriptions may also be + provided. + After the evaluation, the ST specifies ``what was + evaluated''. In this role, the ST serves as a basis for + agreement between the developer or re-seller of the TOE and + the potential consumer of the TOE. The ST can therefore answer + the following questions (and more): + How can I find the ST/TOE that I need given the + multitude of existing STs/TOEs? This question is + addressed by the TOE overview, which gives a brief + (several paragraphs) summary of the TOE; + Does this TOE fit in with my existing + IT-infrastructure? This question is addressed by + the TOE overview, which identifies the major + hardware/firmware/software elements needed to run the TOE; + Does this TOE fit in with my existing operational + environment? This question is addressed by the + security objectives for the operational environment, which + identifies all constraints the TOE places on the + operational environment in order to function; + What does the TOE do (interested reader)? + This question is addressed by the TOE overview, which + gives a brief (several paragraphs) summary of the TOE; + What does the TOE do (potential + consumer)? This question is addressed by the TOE + description, which gives a less brief (several pages) + summary of the TOE; + What does the TOE do (technical)? This + question is addressed by the TOE summary specification + which provides a high-level description of the mechanisms + the TOE uses; + What does the TOE do (expert)? This + question is addressed by the SFRs which provide an + abstract highly technical description, and the TOE summary + specification which provide additional detail; + Does the TOE address the problem as defined by my + government/organisation? If your + government/organisation has defined packages and/or PPs to + define this solution, then the answer can be found in the + Conformance Claims subclause of the ST, which lists all + packages and PPs that the ST conforms to + Does the TOE address my security problem + (expert)? What are the threats countered by the + TOE? What organisational security policies does it + enforce? What assumptions does it make about the + operational environment? These questions are addressed by + the security problem definition; + How much trust can I place in the TOE? + This can be found in the SARs in the security requirements + subclause, which provide the assurance level that was used + to evaluate the TOE, and hence the trust that the + evaluation provides in the correctness of the TOE. + + Writing an ST is not a trivial task, and may, especially in + low assurance evaluations, be a major part of the total effort + expended by the developer and the evaluator in the whole of + the evaluation. For this reason, it is also possible to write + a low assurance ST. + The CC allows the use of a low assurance ST for an EAL 1 + evaluation, but not for EAL 2 and up. A low-assurance ST may + only claim conformance to a low-assurance PP (see ). A regular ST + (i.e., one with full contents) may claim conformance with a + low assurance PP. + A low assurance ST has a significantly reduced content + compared to a regular ST: + + there is no need to describe the security problem definition; + + there is no need to describe the security objectives for + the TOE. The security objectives for the operational + environment must still be described; + + there is no need to describe the security objectives + rationale as there is no security problem definition in + the ST; + + the security requirements rationale only needs to justify + (any) dependencies not being satisfied as there are no + security objectives for the TOE in the ST. + + All that remains are: + + the references to TOE and ST; + + a conformance claim; + + the various narrative descriptions; + + the TOE overview; + + the TOE description; + + the TOE summary specification. + + security objectives for the operational environment; + + the SFRs and the SARs (including the extended components + definition) and the security requirements rationale (only + if the dependencies are not satisfied). + + The reduced content of a low assurance ST is shown in Figure + .
+ In some cases, an ST writer may wish to refer to an external + standard, such as a particular cryptographic standard or + protocol. The CC allows three ways of doing this: + + As an organisational security policy (or part of it). + + If, for example, there exists a government standard + defining how passwords have to be chosen, this may be + stated as an organisational security policy in an + ST. This may lead to an objective for the environment + (e. g. if users of the TOE need to choose passwords + accordingly), or it may lead to security objectives for + the TOE and then to appropriate SFRs (likely of the + class), if the TOE generates + passwords. In both cases the rationale of the developer + needs to make plausible that the security objectives for + the TOE and the SFRs are suitable to fulfil the OSP. The + evaluator will examine if this is in fact plausible (and + may decide to look into the standard for this), if the + OSP is implemented by SFRs, as explained below. + As a technical standard (for example a cryptographic + standard) used in a refinement of an SFR. + + In this case conformance to the standard is part of the + fulfilment of the SFR by the TOE and is treated as if + the full text of the standard is part of the + SFR. Conformance is subsequently determined like any + other conformance to SFRs: during and + it is analysed, by design analysis and + tests, that the SFR is completely and fully implemented + in the TOE. If reference to only a certain part of a + standard is desired, that part should be unambiguously + stated in the SFR refinement. + As a technical standard (for example a cryptographic + standard) mentioned in the TOE summary specification. + + The TOE summary specification is only considered as an + explanation of how the SFRs are realised, and is not + strictly used as a strict implementation requirement + like the SFRs or the documents delivered for . So the evaluator may detect an inconsistency + if the TSS references a technical standard and this is + not reflected in documentation, but + there is no routine activity to test fulfilment of the + standard. + The goal of this Annex is to explain the Protection Profile + (PP) concept. This Annex does not define the criteria; this definition can be found in + CC Part 3 and is supported by the documents given in the + bibliography. + As PPs and STs have a significant overlap, this Annex focuses + on the differences between PPs and STs. The material that is + identical between STs and PPs is described in . + This annex consists of four major parts: + What a PP must contain. This is + summarised in Subclause , and described in more detail + in Subclauses -. These clauses describe the + mandatory contents of the PP, the interrelationships + between these contents, and provide examples. + How a PP should be used. This is + summarised in Subclause . + Low Assurance PPs. Low Assurance PPs are + PPs with reduced content. They are described in detail in + Subclause . + Claiming compliance with + standards. Subclause describes how a PP writer can claim that + the TOE is to meet a particular standard. + + Figure portrays the + mandatory content for a PP that is given in + CC Part 3. Figure may + also be used as a structural outline of the PP, though + alternative structures are allowed. For instance, if the + security requirements rationale is particularly bulky, it + could be included in an appendix of the PP instead of in the + security requirements subclause. The separate subclauses of a + PP and the contents of those subclauses are briefly summarised + below and explained in much more detail in Subclauses - . A + PP contains: + + a PP introduction containing a narrative + description of the TOE type; + + a conformance claim, showing whether the + PP claims conformance to any PPs and/or packages, and if + so, to which PPs and/or packages; + + a security problem definition, showing + threats, OSPs and assumptions; + security objectives, showing how the + solution to the security problem is divided between + security objectives for the TOE and security objectives + for the operational environment of the TOE; + extended components definition, where new + components (i.e. those not included in CC Part 2 or + CC Part 3) may be defined. These new components are + needed to define extended functional and extended + assurance requirements; + security requirements, where a + translation of the security objectives for the TOE into a + standardised language is provided. This standardised + language is in the form of SFRs. Additionally this + subclause defines the SARs; + + There also exist low assurance PPs, which have reduced + contents; these are described in detail in Subclause . With this exception, all other + parts of this Annex assume a PP with full contents.
+ A PP is typically a statement of need where a user + community, a regulatory entity, or a group of developers + define a common set of security needs. A PP gives consumers + a means of referring to this set, and facilitates future + evaluation against these needs. + A PP is therefore typically used as: + + part of a requirement specification for a specific + consumer or group of consumers, who will only consider + buying a specific type of IT if it meets the PP; + + part of a regulation from a specific regulatory entity, + who will only allow a specific type of IT to be used if + it meets the PP; + + a baseline defined by a group of IT developers, who then + agree that all IT that they produce of this type will + meet this baseline. + + though this does not preclude other uses. + Three roles (among many) that a PP should not fulfil are: + a detailed specification: A PP is + designed to be a security specification on a relatively + high level of abstraction. A PP should, in general, not + contain detailed protocol specifications, detailed + descriptions of algorithms and/or mechanisms, long + description of detailed operations etc. + a complete specification: A PP is + designed to be a security specification and not a general + specification. Unless security-relevant, properties such + as interoperability, physical size and weight, required + voltage etc. should not be part of a PP. This means that + in general a PP is a part of a complete specification, but + not a complete specification itself. + a specification of a single product: + Unlike an ST, a PP is designed to describe a certain type + of IT, and not a single product. When only a single + product is described, it is better to use an ST for this + purpose. + + The PP introduction describes the TOE in a narrative way on + two levels of abstraction: + + the PP reference, which provides identification material + for the PP; + + the TOE overview, which briefly describes the TOE. + + A PP contains a clear PP reference that identifies that + particular PP. A typical PP reference consists of title, + version, authors and publication date. An example of a PP + reference is ``Atlantean Navy CablePhone Encryptor PP, + version 2b, Atlantean Navy Procurement Office, April 7, + 2003''. The reference must be unique so that it is possible + to tell different PPs and different versions of the same PP + apart. + The PP reference facilitates indexing and referencing the PP + and its inclusion in lists of PPs. + The TOE overview is aimed at potential consumers of a TOE + who are looking through lists of evaluated products to find + TOEs that may meet their security needs, and are supported + by their hardware, software and firmware. + The TOE overview is also aimed at developers who may use the + PP in designing TOEs or in adapting existing products. + The typical length of a TOE overview is several paragraphs. + To this end, the TOE overview briefly describes the usage of + the TOE and its major security features, identifies the TOE + type and identifies any major non-TOE + hardware/software/firmware available to the TOE. + The description of the usage and major security features + of the TOE is intended to give a very general idea of what + the TOE should be capable of, and what it can be used + for. This subclause should be written for (potential) TOE + consumers, describing TOE usage and major security + features in terms of business operations, using language + that TOE consumers understand. + An example of this is ``The Atlantean Navy CablePhone + Encryptor is an encryption device that should allow + confidential communication between ships across the + Atlantean Navy CablePhone system. To this end it should + allow at least 32 different users and support at least 100 + Mbps encryption speed. It should allow both bilateral + communication between ships and broadcast across the + entire network.'' + The TOE overview identifies the general type of TOE, such + as: firewall, VPN-firewall, smart card, crypto-modem, + intranet, web server, database, web server and database, + LAN, LAN with web server and database, etc. + While some TOEs do not rely upon other IT, many TOEs + (notably software TOEs) rely on additional, non-TOE, + hardware, software and/or firmware. In the latter case, + the TOE overview is required to identify the non-TOE + hardware/software/firmware. + As a Protection Profile is not written for a specific + product, in many cases only a general idea can be given of + the available hardware/software/firmware. In some other + cases, e.g. a requirements specification for a specific + consumer where the platform is already known, (much) more + specific information may be provided. + Examples of hardware/software/firmware identifications + are: + + None. (for a completely stand-alone TOE); + + The Yaiza 3.0 Operating System running on a general + PC; + + a CleverCard SB2067 integrated circuit; + + a CleverCard SB2067 IC running v2.0 of the QuickOS + smart card operating system; + + the December 2002 installation of the LAN of the + Director-General's Office of the Department of + Traffic. + + This subclause of a PP describes how the PP conforms with + other PPs and with packages. It is identical to the + conformance claims subclause for an ST (see Subclause ), with one exception: + the conformance statement. + The conformance statement in the PP states how STs and/or + other PPs must conform to that PP. The PP author selects + whether ``strict'' or ``demonstrable'' conformance is + required. See + for more details on this. + This subclause is identical to the security problem definition + subclause of an ST as explained in Subclause . + This subclause is identical to the security objectives subclause + of an ST as explained in Subclause . + This subclause is identical to the extended components subclause + of an ST as explained in Subclause . + This subclause is identical to the security requirements + subclause of an ST as explained in Subclause . Note however that the rules for completing + operations in a PP are slightly different from the rules for + completing operations in an ST. This is explained in more + detail in Subclause . + A PP has no TOE summary specification. + A low assurance PP has the same relationship to a regular PP + (i.e., one with full contents), as a low assurance ST has to a + regular ST. This means that a low-assurance PP consists of + + a PP introduction, consisting of a PP reference and a TOE + overview; + + a conformance claim; + + security objectives for the operational environment; + + the SFRs and the SARs (including the extended components + definition) and the security requirements rationale (only + if the dependencies are not satisfied). + + A low-assurance PP may only claim conformance to a + low-assurance PP (see ). A + regular PP may claim conformance with a low assurance PP. + The reduced content of a low assurance PP is shown in Figure + .
+ This subclause is identical to the subclause on standards for + STs as described in Subclause , with one exception: as a PP has no TOE + summary specification, the third option is not valid for PPs. + The PP author is reminded that referring to a standard in SFRs + may impose a significant burden on a developer developing a + TOE to meet that PP (depending on the size and complexity of + the standard and the assurance level required), and that it + may be more suitable to require alternative (non-CC related) + ways to assess conformance to that standard. + As described in this CC part 1, Protection Profiles and + Security Targets contain pre-defined security requirements, as + well as providing PP and ST authors the ability to extend the + component lists in some circumstances. + The four types of operations are given in section . Examples of the various + operations are described below: + As described in section + the iteration operation may be performed on every + component. The PP/ST author performs an iteration operation + by including multiple requirements based on the same + component. Each iteration of a component is different from + all other iterations of that component, which is realised by + completing assignments and selections in a different way, or + by applying refinements to it in a different way. Different + iterations should be uniquely identified to allow clear + rationales and tracings to and from these requirements. + A typical example of an iteration is + being iterated twice in order to require the implementation + of two different cryptographic algorithms. An example of + each iteration being uniquely identified is: + + Cryptographic operation (RSA and DSA signatures) + (FCS_COP.1(1)) + + Cryptographic operation (TLS/SSL: symmetric operations) + (FCS_COP.1(2)) + + As described in subclause + an assignment operation occurs where a given component + contains an element with a parameter that may be set by the + PP/ST author. The parameter may be an unrestricted variable, + or a rule that narrows the variable to a specific range of + values. + An example of an element with an assignment is: ``When the defined number of + unsuccessful authentication attempts has been met or + surpassed, the TSF shall [assignment: list of + actions].'' + As described in subclause + the selection operation occurs where a given component + contains an element where a choice from several items has to + be made by the PP/ST author. + An example of an element with a selection is: ``The TSF shall run a suite of + self tests [selection: during initial start-up, periodically + during normal operation, at the request of the authorised + user, at the conditions [assignment: conditions under which + self test should occur]] to demonstrate the correct + operation of ...'' + As described in subclause + the refinement operation can be performed on every + requirement. The PP/ST author performs a refinement by + altering that requirement. + An example of a valid refinement is ``The TSF shall require each user to be + successfully authenticated before allowing any other + TSF-mediated actions on behalf of that user.'' being refined + to ``The TSF shall require each user to be successfully + authenticated by username/password before + allowing any other TSF-mediated actions on behalf of that + user.'' + The first rule for a refinement is that a TOE meeting the + refined requirement also meets the unrefined requirement in + the context of the PP/ST (i.e. a refined requirement must be + ``stricter'' than the original requirement) + The only exception to this rule is that a PP/ST author is + allowed to refine a SFR to apply to some but not all + subjects, objects, operations, security attributes and/or + external entities. + An example of a such an exception is ``The TSF shall require each user to be + successfully authenticated before allowing any other + TSF-mediated actions on behalf of that user.'' being refined + to ``The TSF shall require each user originating from + the internet to be successfully authenticated before + allowing any other TSF-mediated actions on behalf of that + user.'' + The second rule for a refinement given is that the + refinement shall be related to the original component. For + example, refining an audit component with an extra element + on prevention of electromagnetic radiation is not allowed. + A special case of refinement is an editorial refinement, + where a small change is made in a requirement, + i.e. rephrasing a sentence due to adherence to proper + English grammar, or to make it more understandable to the + reader. This change is not allowed to modify the meaning of + the requirement in any way. Examples of editorial + refinements include: + + the SFR ``The TSF shall + continue to preserve a secure state when the following + failures occur: breakdown of one CPU'' + could be refined to + ``The TSF shall continue to preserve a secure state when + the following failure occurs: breakdown of one + CPU'' or even + ``The TSF shall continue to preserve a secure state when + one CPU breaks down''. + + The CC has organised the components in CC Part 2 and CC Part 3 + into hierarchical structures: + Classes, consisting ofFamilies, consisting ofComponents, consisting ofElements. + This organisation into a hierarchy of class - family - + component - element is provided to assist consumers, + developers and evaluators in locating specific components. + The CC presents functional and assurance components in + the same general hierarchical style and use the same + organisation and terminology for each. + An example of a class is the class that is + focused at identification of users, authentication of users + and binding of users and subjects. + An example of a family is the family + which is part of the class. This family + concentrates on the authentication of users. + An example of a component is which + concentrates on unforgeable authentication. + An example of an element is which + concentrates on the prevention of use of copied + authentication data. + Whenever a PP/ST author defines an extended component, + this has to be done in a similar manner to the existing CC + components: clear, unambiguous and evaluatable (it is + possible to systematically demonstrate whether a + requirement based on that component holds for a + TOE). Extended components must use similar labelling, + manner of expression, and level of detail as the existing + CC components. + The PP/ST author also has to make to sure that all + applicable dependencies of an extended component are + included in the definition of that extended + component. Examples of possible dependencies are: + + if an extended component refers to auditing, + dependencies to components of the + class may have to be included; + + if an extended component modifies or accesses data, + dependencies to components of the + family may have to be included; + + if an extended component uses a particular design + description a dependency to the appropriate family (e.g. Functional Specification) may + have to be included. + + In the case of an extended functional component, the PP/ST + author also has to include any applicable audit and + associated operations information in the definition of + that component, similar to existing CC Part 2 + components. In the case of an extended assurance + component, the PP/ST author also has to provide suitable + evaluation methodology for the component, similar to the + methodology provided in the CEM. + Extended components may be placed in existing families, in + which case the PP/ST writer has to show how these families + change. If they do not fit into an existing family, they + shall be placed in a new family. New families have to be + defined similarly to the CC. + New families may be placed in existing classes in which + case the PP/ST writer has to show how these classes + change. If they do not fit into an existing class, they + shall be placed in a new class. New classes have to be + defined similarly to the CC. + A PP is intended to be used as a ``template'' for an ST. That + is: the PP describes a set of user needs, while an ST that + conforms to that PP describes a TOE that satisfies those + needs. + Note that it is also possible for a PP to be used as a + template for another PP. That is PPs can claim conformance to + other PPs. This case is completely similar to that of an ST + vs. a PP. For clarity this Annex describes only the ST/PP + case, but it holds also for the PP/PP case. + The CC does not allow any form of partial conformance, so if a + PP is claimed, the PP or ST must fully conform to the + referenced PP or PPs. There are however two types of + conformance (``strict'' and demonstrable'') and the type of + conformance allowed is determined by the PP. That is, the PP + states (in the PP conformance statement, see subclause ) what the allowed types of conformance for the ST + are. This distinction between strict and demonstrable + conformance is applicable to each PP to which an ST may claim + conformance on an individual basis. This may mean that the ST + conforms strictly to some PPs and demonstrably to other + PPs. An ST is only allowed to conform to a PP in a + demonstrable manner, if the PP explicitly allows this, whereas + an ST can always conform with strict conformance to any PP. + Restating this in other words, an ST is only allowed to + conform to a PP in a demonstrable manner, if the PP explicitly + allows this. + Conformance to a PP means that the PP or ST (and if an ST is + of an evaluated product, the product as well) meets all + requirements of that PP. + Published PPs will normally require demonstrable + conformance. This means that STs claiming conformance with the + PP must offer a solution to the generic security problem + described in the PP, but can do so in any way that is + equivalent or more restrictive to that described in the + PP. ``Equivalent but more restrictive'' is defined at length + within the CC, but in principle it means that the PP + and ST may contain entirely different statements that discuss + different entities, use different concepts etc., provided that + overall the ST levies the same or more restrictions on the + TOE, and the same or less restrictions on the operational + environment of the TOE. + Strict conformance is oriented to the PP-author who requires + evidence that the requirements in the PP are met, that the ST + is an instantiation of the PP, though the ST could be broader + than the PP. In essence, the ST specifies that the TOE does at + least the same as in the PP, while the operational environment + does at most the same as in the PP. + A typical example of the use of strict conformance is in + selection based purchasing where a product's security + requirements are expected to exactly match those specified in + the PP. + An ST instantiating strict conformance to a PP can still + introduce additional restrictions to those given in the PP. + Demonstrable conformance is orientated to the PP-author who + requires evidence that the ST is a suitable solution to the + generic security problem described in the PP. + Where there is a clear subset-superset type relation between + PP and ST in the case of strict conformance, the relation is + less clear-cut in the case of demonstrable conformance. STs + claiming conformance with the PP must offer a solution to the + generic security problem described in the PP. but can do so in + any way that is equivalent or more restrictive to that + described in the PP. + This bibliography contains references to further material and + standards that the reader of the CC may find useful. For + undated references the reader is recommended to refer to the + latest edition of the referenced document.ISO/IEC 15292Information technology -- Security techniques -- + Protection Profile registration proceduresISO/IEC 15443Information technology -- Security techniques + -- A framework for IT security assurance - all partsISO/IEC 15446Information technology -- Security techniques + -- Guide for the production of Protection Profiles and Security + TargetsISO/IEC 19790Information technology -- Security techniques + -- Security requirements for cryptographic modulesISO/IEC 19791Information technology -- Security techniques + -- Security assessment of operational systemsISO/IEC 27001Information technology -- Security techniques + -- Information security management systems -- RequirementsISO/IEC 27002Information technology -- Security techniques + -- Code of practice for information security managementIEEE Std 610.12-1990 + Institute of Electrical and Electronics Engineers, Standard + Glossary of Software Engineering Terminology + CC portal + Common Criteria portal, February 2009. CCRA, www.commoncriteriaportal.org + + + + Table describes the + relationship between PPs and the families and components of the + class. + + + + + Assurance + class + Assurance family + Assurance component + + + Low Assurance PP + PP + + + + + Protection Profile evaluation + + 1 + 1 + + + + 1 + 1 + + + + 1 + 1 + + + + 1 + 2 + + + + 1 + 2 + + + + + 1 + + + + PP assurance level summary +
+ + + + + + + + + + The following Subclauses describe the constructs used in + representing the assurance classes, families, and + components. + + Figure + illustrates the SARs defined in this CC Part 3. Note that the + most abstract collection of SARs is referred to as a + class. Each class contains assurance families, which then + contain assurance components, which in turn contain assurance + elements. Classes and families are used to provide a taxonomy + for classifying SARs, while components are used to specify + SARs in a PP/ST. + + + Figure + illustrates the assurance class structure. + + + Each assurance class is assigned a unique name. The name + indicates the topics covered by the assurance + class. + + A unique short form of the assurance class name is also + provided. This is the primary means for referencing the + assurance class. The convention adopted is an ``A'' + followed by two letters related to the class name. + + + + Each assurance class has an introductory Subclause that + describes the composition of the class and contains + supportive text covering the intent of the class. + + + + Each assurance class contains at least one assurance + family. The structure of the assurance families is + described in the following Subclause. + + +
+ + + Figure + illustrates the assurance family structure. + + + Every assurance family is assigned a unique name. The name + provides descriptive information about the topics covered + by the assurance family. Each assurance family is placed + within the assurance class that contains other families + with the same intent. + + A unique short form of the assurance family name is also + provided. This is the primary means used to reference the + assurance family. The convention adopted is that the short + form of the class name is used, followed by an underscore, + and then three letters related to the family name. + + + + The objectives Subclause of the assurance family presents + the intent of the assurance family. + + This Subclause describes the objectives, particularly + those related to the CC assurance paradigm, that the + family is intended to address. The description for the + assurance family is kept at a general level. Any specific + details required for objectives are incorporated in the + particular assurance component. + + + + Each assurance family contains one or more assurance + components. This Subclause of the assurance family + describes the components available and explains the + distinctions between them. Its main purpose is to + differentiate between the assurance components once it has + been determined that the assurance family is a necessary + or useful part of the SARs for a PP/ST. + + Assurance families containing more than one component are + levelled and rationale is provided as to how the + components are levelled. This rationale is in terms of + scope, depth, and/or rigour. + + + + The application notes Subclause of the assurance family, + if present, contains additional information for the + assurance family. This information should be of particular + interest to users of the assurance family (e.g. PP and ST + authors, designers of TOEs, evaluators). The presentation + is informal and covers, for example, warnings about + limitations of use and areas where specific attention may + be required. + + + + Each assurance family has at least one assurance + component. The structure of the assurance components is + provided in the following Subclause. + + + + + Figure illustrates the + assurance component structure. +
+ + The relationship between components within a family is + highlighted using a bolding convention. Those parts of the + requirements that are new, enhanced or modified beyond the + requirements of the previous component within a hierarchy + are bolded. + + + The component identification Subclause provides + descriptive information necessary to identify, categorise, + register, and reference a component. + + Every assurance component is assigned a unique name. The + name provides descriptive information about the topics + covered by the assurance component. Each assurance + component is placed within the assurance family that + shares its security objective. + + A unique short form of the assurance component name is + also provided. This is the primary means used to reference + the assurance component. The convention used is that the + short form of the family name is used, followed by a + period, and then a numeric character. The numeric + characters for the components within each family are + assigned sequentially, starting from 1. + + + + The objectives Subclause of the assurance component, if + present, contains specific objectives for the particular + assurance component. For those assurance components that + have this Subclause, it presents the specific intent of + the component and a more detailed explanation of the + objectives. + + + + The application notes Subclause of an assurance component, + if present, contains additional information to facilitate + the use of the component. + + + + Dependencies among assurance components arise when a + component is not self-sufficient, and relies upon the + presence of another component. + + Each assurance component provides a complete list of + dependencies to other assurance components. Some + components may list ``No dependencies'', to indicate that + no dependencies have been identified. The components + depended upon may have dependencies on other + components. + + The dependency list identifies the minimum set of + assurance components which are relied upon. Components + which are hierarchical to a component in the dependency + list may also be used to satisfy the dependency. + + In specific situations the indicated dependencies might + not be applicable. The PP/ST author, by providing + rationale for why a given dependency is not applicable, + may elect not to satisfy that dependency. + + + + A set of assurance elements is provided for each assurance + component. An assurance element is a security requirement + which, if further divided, would not yield a meaningful + evaluation result. It is the smallest security requirement + recognised in the CC. + + Each assurance element is identified as belonging to one + of the three sets of assurance elements: + + + Developer action elements: the activities that shall + be performed by the developer. This set of actions is + further qualified by evidential material referenced in + the following set of elements. Requirements for + developer actions are identified by appending the + letter ``D'' to the element number. + + + Content and presentation of evidence elements: the + evidence required, what the evidence shall + demonstrate, and what information the evidence shall + convey. Requirements for content and presentation of + evidence are identified by appending the letter ``C'' + to the element number. + + + Evaluator action elements: the activities that shall + be performed by the evaluator. This set of actions + explicitly includes confirmation that the requirements + prescribed in the content and presentation of evidence + elements have been met. It also includes explicit + actions and analysis that shall be performed in + addition to that already performed by the + developer. Implicit evaluator actions are also to be + performed as a result of developer action elements + which are not covered by content and presentation of + evidence requirements. Requirements for evaluator + actions are identified by appending the letter ``E'' + to the element number. + + + + The developer actions and content and presentation of + evidence define the assurance requirements that are used + to represent a developer's responsibilities in + demonstrating assurance in the TOE meeting the SFRs of a + PP or ST. + + The evaluator actions define the evaluator's + responsibilities in the two aspects of evaluation. The + first aspect is validation of the PP/ST, in accordance + with the classes and in Clauses and . The second + aspect is verification of the TOE's conformance with its + SFRs and SARs. By demonstrating that the PP/ST is valid + and that the requirements are met by the TOE, the + evaluator can provide a basis for confidence that the TOE + in its operational environment solves the defined security + problem. + + The developer action elements, content and presentation of + evidence elements, and explicit evaluator action elements, + identify the evaluator effort that shall be expended in + verifying the security claims made in the ST of the + TOE. + + + + + Each element represents a requirement to be met. These + statements of requirements are intended to be clear, + concise, and unambiguous. Therefore, there are no compound + sentences: each separable requirement is stated as an + individual element. + + + + This CC Part 3 contains classes of families and components + that are grouped on the basis of related assurance. At the + start of each class is a diagram that indicates the families + in the class and the components in each family. +
+ + In Figure , + above, the class as shown contains a single family. The + family contains three components that are linearly + hierarchical (i.e. component 2 requires more than component + 1, in terms of specific actions, specific evidence, or + rigour of the actions or evidence). The assurance families + in this CC Part 3 are all linearly hierarchical, although + linearity is not a mandatory criterion for assurance + families that may be added in the future. + + + + + Figure illustrates + the EALs and associated structure defined in this CC Part + 3. Note that while the figure shows the contents of the + assurance components, it is intended that this information + would be included in an EAL by reference to the actual + components defined in the CC. +
+ + + Each EAL is assigned a unique name. The name provides + descriptive information about the intent of the EAL. + + A unique short form of the EAL name is also provided. This + is the primary means used to reference the EAL. + + + + The objectives Subclause of the EAL presents the intent of + the EAL. + + + The application notes Subclause of the EAL, if present, + contains information of particular interest to users of the + EAL (e.g. PP and ST authors, designers of TOEs targeting + this EAL, evaluators). The presentation is informal and + covers, for example, warnings about limitations of use and + areas where specific attention may be required. + A set of assurance components have been chosen for each + EAL. + A higher level of assurance than that provided by a given + EAL can be achieved by: + + including additional assurance components from other + assurance families; or + + replacing an assurance component with a higher level + assurance component from the same assurance family. + + + + Figure + illustrates the relationship between the SARs and the + assurance levels defined in the CC. While assurance + components further decompose into assurance elements, + assurance elements cannot be individually referenced by + assurance levels. Note that the arrow in the figure + represents a reference from an EAL to an assurance component + within the class where it is defined. +
+ + + + + The structure of the CAPs is similar to that of the EALs. The + main difference between these two types of package is the type + of TOE they apply to; the EALs applying to component TOEs and + the CAPs applying to composed TOEs. + + Figure illustrates + the CAPs and associated structure defined in this CC Part + 3. Note that while the figure shows the contents of the + assurance components, it is intended that this information + would be included in a CAP by reference to the actual + components defined in the CC. +
+ + + Each CAP is assigned a unique name. The name provides + descriptive information about the intent of the CAP. + + A unique short form of the CAP name is also provided. This + is the primary means used to reference the CAP. + + + + The objectives Subclause of the CAP presents the intent of + the CAP. + + + The application notes Subclause of the CAP, if present, + contains information of particular interest to users of the + CAP (e.g. PP and ST authors, integrators of composed TOEs + targeting this CAP, evaluators). The presentation is + informal and covers, for example, warnings about limitations + of use and areas where specific attention may be + required. + A set of assurance components have been chosen for each + CAP. + Some dependencies identify the activities performed during + the evaluation of the dependent component on which the + composed TOE activity relies. Where it is not explicitly + identified that the dependency is on a dependent component + activity, the dependency is to another evaluation activity + of the composed TOE. + A higher level of assurance than that provided by a given + CAP can be achieved by: + + including additional assurance components from other + assurance families; or + + replacing an assurance component with a higher level + assurance component from the same assurance family. + + The components included in the CAP + assurance packages should not be used as augmentations for + component TOE evaluations, as this would provide no + meaningful assurance for the component. + + + Figure + illustrates the relationship between the SARs and the + composed assurance packages defined in the CC. While + assurance components further decompose into assurance + elements, assurance elements cannot be individually + referenced by assurance packages. Note that the arrow in the + figure represents a reference from a CAP to an assurance + component within the class where it is defined. +
+ + + + + + + + This clause defines the content and presentation of the + functional requirements of the CC, and provides guidance on + the organisation of the requirements for new components to be + included in an ST. The functional requirements are expressed + in classes, families, and components. + + + + Figure illustrates the + functional class structure in diagrammatic form. Each + functional class includes a class name, class introduction, + and one or more functional families. + +
+ + + + The class name subclause provides information necessary to + identify and categorise a functional class. Every + functional class has a unique name. The categorical + information consists of a short name of three + characters. The short name of the class is used in the + specification of the short names of the families of that + class. + + + + The class introduction expresses the common intent or + approach of those families to satisfy security + objectives. The definition of functional classes does not + reflect any formal taxonomy in the specification of the + requirements. + + The class introduction provides a figure describing the + families in this class and the hierarchy of the components + in each family, as explained in subclause . + + + + + + Figure + illustrates the functional family structure in diagrammatic + form. + +
+ + + + The family name subclause provides categorical and + descriptive information necessary to identify and + categorise a functional family. Every functional family + has a unique name. The categorical information consists of + a short name of seven characters, with the first three + identical to the short name of the class followed by an + underscore and the short name of the family as follows + XXX_YYY. The unique short form of the family name provides + the principal reference name for the components. + + + + The family behaviour is the narrative description of the + functional family stating its security objective and a + general description of the functional requirements. These + are described in greater detail below: + + + The security objectives of the family + address a security problem that may be solved with the + help of a TOE that incorporates a component of this + family; + + + The description of the functional + requirements summarises all the requirements + that are included in the component(s). The description + is aimed at authors of PPs, STs and functional + packages who wish to assess whether the family is + relevant to their specific requirements. + + + + + + Functional families contain one or more components, any + one of which can be selected for inclusion in PPs, STs and + functional packages. The goal of this section is to + provide information to users in selecting an appropriate + functional component once the family has been identified + as being a necessary or useful part of their security + requirements. + + This section of the functional family description + describes the components available, and their + rationale. The exact details of the components are + contained within each component. + + The relationships between components within a functional + family may or may not be hierarchical. A component is + hierarchical to another if it offers more security. + + As explained in the descriptions of the + families provide a graphical overview of the hierarchy of + the components in a family. + + + + + The management clauses contain information for + the PP/ST authors to consider as management activities for a + given component. The clauses reference components of the + management class (FMT), and provide guidance regarding potential + management activities that may be applied via operations to + those components. + + A PP/ST author may select the indicated management components or + may include other management requirements not listed to detail + management activities. As such the information should be + considered informative. + + + + + The audit requirements contain auditable + events for the PP/ST authors to select, if requirements + from the class , are included in the + PP/ST. These requirements include security relevant events + in terms of the various levels of detail supported by the + components of the family. For example, + an audit note might include actions that are in terms of: + Minimal - successful use of the security mechanism; Basic + - any use of the security mechanism as well as relevant + information regarding the security attributes involved; + Detailed - any configuration changes made to the + mechanism, including the actual configuration values + before and after the change. + + It should be observed that the categorisation of auditable + events is hierarchical. For example, when Basic Audit + Generation is desired, all auditable events identified as + being both Minimal and Basic should be included in the + PP/ST through the use of the appropriate assignment + operation, except when the higher level event simply + provides more detail than the lower level event. When + Detailed Audit Generation is desired, all identified + auditable events (Minimal, Basic and Detailed) should be + included in the PP/ST. + + In the class the rules governing the audit + are explained in more detail. + + + + + + Figure illustrates the + functional component structure. + +
+ + + + The component identification subclause provides + descriptive information necessary to identify, categorise, + register and cross-reference a component. The following is + provided as part of every functional component: + + A unique name. The name reflects the + purpose of the component. + + A short name. A unique short form of the + functional component name. This short name serves as the + principal reference name for the categorisation, + registration and cross-referencing of the component. This + short name reflects the class and family to which the + component belongs and the component number within the + family. + + A hierarchical-to list. A list of other + components that this component is hierarchical to and for + which this component can be used to satisfy dependencies + to the listed components. + + + + + A set of elements is provided for each component. Each + element is individually defined and is self-contained. + + A functional element is a security functional requirement + that if further divided would not yield a meaningful + evaluation result. It is the smallest security functional + requirement identified and recognised in the CC. + + When building packages, PPs and/or STs, it is not + permitted to select only one or more elements from a + component. The complete set of elements of a component + must be selected for inclusion in a PP, ST or package. + + A unique short form of the functional element name is + provided. For example the requirement name FDP_IFF.4.2 + reads as follows: F - functional requirement, DP - class + ``User data protection'', _IFF - + family ``Information flow control + functions'', .4 - 4th component named + ``Partial elimination of illicit information + flows'', .2 - 2nd element of the component. + + + + + Dependencies among functional components arise when a + component is not self sufficient and relies upon the + functionality of, or interaction with, another component + for its own proper functioning. + + Each functional component provides a complete list of + dependencies to other functional and assurance + components. Some components may list ``No + dependencies''. The components depended upon may in + turn have dependencies on other components. The list + provided in the components will be the direct + dependencies. That is only references to the functional + requirements that are required for this requirement to + perform its job properly. The indirect dependencies, that + is the dependencies that result from the depended upon + components can be found in + of this part of the CC. It is noted that in some cases the + dependency is optional in that a number of functional + requirements are provided, where each one of them would be + sufficient to satisfy the dependency (see for example + ). + + The dependency list identifies the minimum functional or + assurance components needed to satisfy the security + requirements associated with an identified + component. Components that are hierarchical to the + identified component may also be used to satisfy the + dependency. + + The dependencies indicated in CC Part 2 are + normative. They must be satisfied within a PP/ST. In + specific situations the indicated dependencies might not + be applicable. The PP/ST author, by providing the + rationale why it is not applicable, may leave the depended + upon component out of the package, PP or ST. + + + + + + + + + The grouping of the components in this part of the CC does not + reflect any formal taxonomy. + + This part of the CC contains classes of families and + components, which are rough groupings on the basis of related + function or purpose, presented in alphabetic order. At the + start of each class is an informative diagram that indicates + the taxonomy of each class, indicating the families in each + class and the components in each family. The diagram is a + useful indicator of the hierarchical relationship that may + exist between components. + + In the description of the functional components, a section + identifies the dependencies between the component and any + other components. + + In each class a figure describing the family hierarchy similar + to Figure , is provided. In Figure + the first family, Family 1, + contains three hierarchical components, where component 2 and + component 3 can both be used to satisfy dependencies on + component 1. Component 3 is hierarchical to component 2 and + can also be used to satisfy dependencies on component 2. + +
+ + + In Family 2 there are three components not all of which are + hierarchical. Components 1 and 2 are hierarchical to no other + components. Component 3 is hierarchical to component 2, and + can be used to satisfy dependencies on component 2, but not to + satisfy dependencies on component 1. + + In Family 3, components 2, 3, and 4 are hierarchical to + component 1. Components 2 and 3 are both hierarchical to + component 1, but non-comparable. Component 4 is hierarchical + to both component 2 and component 3. + + These diagrams are meant to complement the text of the + families and make identification of the relationships + easier. They do not replace the ``Hierarchical + to:'' note in each component that is the mandatory + claim of hierarchy for each component. + + + The relationship between components within a family is + highlighted using a bolding + convention. This bolding convention calls for the bolding of + all new requirements. For hierarchical components, + requirements are bolded when they are + enhanced or modified beyond the requirements of the previous + component. In addition, any new or enhanced permitted + operations beyond the previous component are also + highlighted using bold type. + + + + + + This annex contains additional guidance for the families and + components defined in the elements of this CC Part 2, which + may be required by users, developers or evaluators to use the + components. To facilitate finding the appropriate information, + the presentation of the classes, families and components in + this annex is similar to the presentation within the elements. + + + + This clause defines the content and presentation of the notes + related to functional requirements of the CC. + + + + Figure below + illustrates the functional class structure in this annex. + +
+ + + + This is the unique name of the class defined within the + normative elements of this part of the CC. + + + + + The class introduction in this annex provides information + about the use of the families and components of the + class. This information is completed with the informative + diagram that describes the organisation of each class with + the families in each class and the hierarchical + relationship between components in each family. + + + + + + Figure illustrates + the functional family structure for application notes in + diagrammatic form. + +
+ + + + This is the unique name of the family defined within the + normative elements of this part of the CC. + + + + + The user notes contain additional information that is of + interest to potential users of the family, that is PP, ST + and functional package authors, and developers of TOEs + incorporating the functional components. The presentation + is informative, and might cover warnings about limitations + of use and areas where specific attention might be + required when using the components. + + + + + The evaluator notes contain any information that is of + interest to developers and evaluators of TOEs that claim + compliance with a component of the family. The + presentation is informative and can cover a variety of + areas where specific attention might be needed when + evaluating the TOE. This can include clarifications of + meaning and specification of the way to interpret + requirements, as well as caveats and warnings of specific + interest to evaluators. + + These User Notes and Evaluator Notes sections are not + mandatory and appear only if appropriate. + + + + + + Figure illustrates + the functional component structure for the application + notes. + +
+ + + + This is the unique name of the component defined within + the normative elements of this part of the CC. + + + + + Any specific information related to the component can be + found in this section. + + + The rationale contains the specifics + of the rationale that refine the general statements on + rationale for the specific level, and should only be + used if level specific amplification is required. + + + The application notes contain + additional refinement in terms of narrative + qualification as it pertains to a specific + component. This refinement can pertain to user notes, + and/or evaluator notes as described in Subclause . This refinement can be + used to explain the nature of the dependencies + (e.g. shared information, or shared operation). + + + + This section is not mandatory and appears only if + appropriate. + + + + + This portion of each component contains advice relating to + the permitted operations of the component. + + This section is not mandatory and appears only if + appropriate. + + + + + + The following dependency tables for functional components + show their direct, indirect and optional dependencies. Each + of the components that is a dependency of some functional + component is allocated a column. Each functional component is + allocated a row. The value in the table cell indicate whether + the column label component is directly required (indicated by + a cross ``X''), indirectly required (indicated by a + dash ``-''), or optionally required (indicated by a + ``o'') by the row label component. An example of a + component with optional dependencies is , which requires either + or to be present. So if is present, is not + necessary and vice versa. If no character is presented, the + component is not dependent upon another component. + + + + + + Security auditing involves recognising, recording, storing, + and analysing information related to security relevant + activities (i.e. activities controlled by the TSF). The + resulting audit records can be examined to determine which + security relevant activities took place and whom (which user) + is responsible for them. + + + + CC audit families allow PP/ST authors the ability to define + requirements for monitoring user activities and, in some + cases, detecting real, possible, or imminent violations of + the enforcement of the SFRs. The TOE's security audit functions are + defined to help monitor security-relevant events, and act as a + deterrent against security violations. The requirements of the + audit families refer to functions that include audit data + protection, record format, and event selection, as well as + analysis tools, violation alarms, and real-time analysis. The + audit trail should be presented in human-readable format + either directly (e.g. storing the audit trail in + human-readable format) or indirectly (e.g. using audit + reduction tools), or both. + + While developing the security audit requirements, the PP/ST + author should take note of the inter-relationships among the + audit families and components. The potential exists to specify + a set of audit requirements that comply with the + family/component dependencies lists, while at the same time + resulting in a deficient audit function (e.g. an audit + function that requires all security relevant events to be + audited but without the selectivity to control them on any + reasonable basis such as individual user or object). + + + The implementation of audit requirements for networks and + other large systems may differ significantly from those + needed for stand-alone systems. Larger, more complex and + active systems require more thought concerning which audit + data to collect and how this should be managed, due to + lowered feasibility of interpreting (or even storing) what + gets collected. The traditional notion of a time-ordered list + or ``trail'' of audited events may not + be applicable in a global asynchronous network with + arbitrarily many events occurring at once. + + Also, different hosts and servers on a distributed TOE may + have differing naming policies and values. Symbolic names + presentation for audit review may require a net-wide + convention to avoid redundancies and ``name + clashes.'' + + A multi-object audit repository, portions of which are + accessible by a potentially wide variety of authorised + users, may be required if audit repositories are to serve a + useful function in distributed systems. + + Finally, misuse of authority by authorised users should be + addressed by systematically avoiding local storage of audit + data pertaining to administrator actions. + + + + + + + This family defines the response to be taken in case of + detected events indicative of a potential security + violation. + + + + The Security audit automatic response family describes + requirements for the handling of audit events. The + requirement could include requirements for alarms or TSF + action (automatic response). For example, the TSF could + include the generation of real time alarms, termination of + the offending process, disabling of a service, or + disconnection or invalidation of a user account. + + An audit event is defined to be an ``potential + security violation'' if so indicated by the + components. + + + + + + + + + An action should be taken for follow up action in the + event of an alarm. This action can be to inform the + authorised user, to present the authorised user with a set + of possible containment actions, or to take corrective + actions. The timing of the actions should be carefully + considered by the PP/ST author. + + + + At , the TSF shall take actions in + case a potential security violation is detected. + + + the management (addition, removal, or modification) of + actions. + + + Actions taken due to potential security violations. + + + The TSF shall take + + + list of actions + + + + the PP/ST author should specify the actions to be taken + in case of a potential security violation. An example of + such a list is: ``inform the authorised user, disable + the subject that created the potential security + violation.'' It can also specify that the action to be + taken can be specified by an authorised user. + + + upon detection of a potential security violation. + + + + + + + + This family defines requirements for recording the + occurrence of security relevant events that take place under + TSF control. This family identifies the level of auditing, + enumerates the types of events that shall be auditable by + the TSF, and identifies the minimum set of audit-related + information that should be provided within various audit + record types. + + + + The Security audit data generation family includes + requirements to specify the audit events that should be + generated by the TSF for security-relevant events. + + This family is presented in a manner that avoids a dependency + on all components requiring audit support. Each component has + an audit section developed in which the events to be audited + for that functional area are listed. When the PP/ST author + assembles the PP/ST, the items in the audit area are used to + complete the variable in this component. Thus, the + specification of what could be audited for a functional area + is localised in that functional area. + + The list of auditable events is entirely dependent on the + other functional families within the PP/ST. Each family + definition should therefore include a list of its + family-specific auditable events. Each auditable event in the + list of auditable events specified in the functional family + should correspond to one of the levels of audit event + generation specified in this family (i.e. minimal, basic, + detailed). This provides the PP/ST author with information + necessary to ensure that all appropriate auditable events are + specified in the PP/ST. The following example shows how + auditable events are to be specified in appropriate functional + families: + + ``The following actions should be auditable if is included in the PP/ST: + + + Minimal: Successful use of the user security attribute + administration functions; + + + Basic: All attempted uses of the user security attribute + administration functions; + + + Basic: Identification of which user security attributes + have been modified; + + + Detailed: With the exception of specific sensitive + attribute data items (e.g. passwords, cryptographic + keys), the new values of the attributes should be + captured.'' + + + + For each functional component that is chosen, the auditable + events that are indicated in that component, at and below the + level indicated in should be + auditable. If, for example, in the previous example ``Basic'' + would be selected in , the + auditable events mentioned in a), b) and c) should be + auditable. + + Observe that the categorisation of auditable events is + hierarchical. For example, when Basic Audit Generation is + desired, all auditable events identified as being either + Minimal or Basic, should also be included in the PP/ST + through the use of the appropriate assignment operation, + except when the higher level event simply provides more + detail than the lower level event. When Detailed Audit + Generation is desired, all identified auditable events + (Minimal, Basic, and Detailed) should be included in the + PP/ST. + + A PP/ST author may decide to include other auditable events + beyond those required for a given audit level. For example, + the PP/ST may claim only minimal audit capabilities while + including most of the basic capabilities because the few + excluded capabilities conflict with other PP/ST constraints + (e.g. because they require the collection of unavailable + data). + + The functionality that creates the auditable event should be + specified in the PP or ST as a functional requirement. + + The following are examples of the types of the events that + should be defined as auditable within each PP/ST functional + component: + + + Introduction of objects within the control of the TSF into a + subject's address space; + + + Deletion of objects; + + + Distribution or revocation of access rights or + capabilities; + + + Changes to subject or object security attributes; + + + Policy checks performed by the TSF as a result of a + request by a subject; + + + The use of access rights to bypass a policy check; + + + Use of Identification and Authentication functions; + + + Actions taken by an operator, and/or authorised user + (e.g. suppression of a TSF protection mechanism as + human-readable labels); + + + Import/export of data from/to removable media + (e.g. printed output, tapes, diskettes). + + + + + + + + + + + This component defines requirements to identify the + auditable events for which audit records should be + generated, and the information to be provided in the audit + records. + + by itself might be used + when the SFRs do not require that individual user identities + be associated with audit events. This could be appropriate + when the PP/ST also contains privacy requirements. If the + user identity must be incorporated could be used in addition. + + If the subject is a user, the user identity may be recorded as + the subject identity. The identity of the user may not yet been + verified if has not been + applied. Therefore in the instance of an invalid login the + claimed user identity should be recorded. It should be + considered to indicate when a recorded identity has not been + authenticated. + + + + There is a dependency on . If correctness of time is not an issue for + this TOE, elimination of this dependency could be + justified. + + + + defines the level of auditable + events, and specifies the list of data that shall be + recorded in each record. + + + The TSF shall be able to generate an audit record of the + following auditable events: + + + Start-up and shutdown of the audit functions; + + + All auditable events for the + + minimum + basic + detailed + not specified + + + the PP/ST author should select the level of + auditable events called out in the audit section of + other functional components included in the + PP/ST. This level is one of the following: + ``minimum'', ``basic'', ``detailed'' or ``not + specified''. + + + level of audit; and + + + + + other specifically defined auditable events + + + + the PP/ST author should assign a list of other + specifically defined auditable events to be included + in the list of auditable events. The assignment may + comprise none, or events that could be auditable + events of a functional requirement that are of a + higher audit level than requested in , as well as the + events generated through the use of a specified + Application Programming Interface (API). + + . + + + + + The TSF shall record within each audit record at least the + following information: + + + Date and time of the event, type of event, subject identity (if + applicable), and the outcome (success or failure) of the event; + and + + + For each audit event type, based on the auditable event + definitions of the functional components included in the + PP/ST, + + + other audit relevant information + + + + the PP/ST author should assign, for each auditable + events included in the PP/ST, either a list of other + audit relevant information to be included in audit + events records or none. + + . + + + + + + + + + + + + + This component addresses the requirement of accountability + of auditable events at the level of individual user + identity. This component should be used in addition to + . + + There is a potential conflict between the audit and privacy + requirements. For audit purposes it may be desirable to know + who performed an action. The user may want to keep his/her + actions to himself/herself and not be identified by other + persons (e.g. a site with job offers). Or it might be + required in the Organisational Security Policy that the + identity of the users must be protected. In those cases the + objectives for audit and privacy might contradict each + other. Therefore if this requirement is selected and privacy + is important, inclusion of the component user pseudonimity + might be considered. Requirements on determining the real + user name based on its pseudonym are specified in the + privacy class. + + If the identity of the user has not yet been verified through + authentication, in the instance of an invalid login the claimed + user identity should be recorded. It should be considered to + indicate when a recorded identity has not been authenticated. + + + + At , the TSF shall associate + auditable events to individual user identities. + + + 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. + + + + + + + + This family defines requirements for automated means that + analyse system activity and audit data looking for possible or + real security violations. This analysis may work in support of + intrusion detection, or automatic response to a potential + security violation. + + The actions to be taken based on the detection can be + specified using the family as + desired. + + + + This family defines requirements for automated means that + analyse system activity and audit data looking for possible + or real security violations. This analysis may work in + support of intrusion detection, or automatic response to a + potential security violation. + + The action to be performed by the TSF on detection of a + potential violation is defined in components. + + For real-time analysis, audit data could be transformed into a + useful format for automated treatment, but into a different + useful format for delivery to authorised users for + review. + + + + + + + + + This component is used to specify the set of auditable + events whose occurrence or accumulated occurrence held to + indicate a potential violation of the enforcement of the + SFRs, and any rules to be used to perform the violation + analysis. + + + + In , basic threshold + detection on the basis of a fixed rule set is + required. + + + maintenance of the rules by (adding, modifying, deletion) + of rules from the set of rules. + + + Enabling and disabling of any of the analysis mechanisms; + + + Automated responses performed by the tool. + + + The TSF shall be able to apply a set of rules in monitoring + the audited events and based upon these rules indicate a + potential violation of the enforcement of the SFRs. + + + The TSF shall enforce the following rules for monitoring + audited events: + + + Accumulation or combination of + + + subset of defined auditable events + + + + the PP/ST author should identify the subset of + defined auditable events whose occurrence or + accumulated occurrence need to be detected as an + indication of a potential violation of the + enforcement of the SFRs. + + + known to indicate a potential security violation; + + + + + any other rules + + + + the PP/ST author should specify any other rules that + the TSF should use in its analysis of the audit + trail. Those rules could include specific + requirements to express the needs for the events to + occur in a certain period of time (e.g. period of + the day, duration). If there are no additional + rules that the TSF should use in the analysis of the + audit trail, this assignment can be completed with + ``none''. + + . + + + + + + + + + + + + + A profile is a structure that + characterises the behaviour of users and/or subjects; it + represents how the users/subjects interact with the TSF in + a variety of ways. Patterns of usage are established with + respect to the various types of activity the + users/subjects engage in (e.g. patterns in exceptions + raised, patterns in resource utilisation (when, which, + how), patterns in actions performed). The ways in which + the various types of activity are recorded in the profile + (e.g. resource measures, event counters, timers) are + referred to as profile metrics. + + Each profile represents the expected patterns of usage + performed by members of the profile target + group. This pattern may be based on past use + (historical patterns) or on normal use for users of + similar target groups (expected behaviour). A profile + target group refers to one or more users who interact with + the TSF. The activity of each member of the profile group + is used by the analysis tool in establishing the usage + patterns represented in the profile. The following are + some examples of profile target groups: + + + Single user account: one profile per + user; + + + Group ID or Group Account: one profile + for all users who possess the same group ID or operate + using the same group account; + + + Operating Role: one profile for all users + sharing a given operating role; + + + System: one profile for all users of a + system. + + + + Each member of a profile target group is assigned an + individual suspicion rating that + represents how closely that member's new + activity corresponds to the established patterns of usage + represented in the group profile. + + The sophistication of the anomaly detection tool will + largely be determined by the number of target profile + groups required by the PP/ST and the complexity of the + required profile metrics. + + + The PP/ST author should enumerate specifically what activity + should be monitored and/or analysed by the TSF. The PP/ST + author should also identify specifically what information + pertaining to the activity is necessary to construct the + usage profiles. + + requires that the TSF + maintain profiles of system usage. The word maintain implies + that the anomaly detector is actively updating the usage + profile based on new activity performed by the profile + target members. It is important here that the metrics for + representing user activity are defined by the PP/ST + author. For example, there may be a thousand different + actions an individual may be capable of performing, but the + anomaly detector may choose to monitor a subset of that + activity. Anomalous activity gets integrated into the + profile just like non-anomalous activity (assuming the tool + is monitoring those actions). Things that may have appeared + anomalous four months ago, might over time become the norm + (and vice-versa) as the user's work duties change. The TSF + wouldn't be able to capture this notion if it filtered out + anomalous activity from the profile updating + algorithms. + + Administrative notification should be provided such that + the authorised user understands the significance of the + suspicion rating. + + The PP/ST author should define how to interpret suspicion + ratings and the conditions under which anomalous activity is + indicated to the + mechanism. + + + + In , the TSF maintains + individual profiles of system usage, where a profile + represents the historical patterns of usage performed by + members of the profile target group. A profile target group + refers to a group of one or more individuals (e.g. a single + user, users who share a group ID or group account, users who + operate under an assigned role, users of an entire system or + network node) who interact with the TSF. Each member of a + profile target group is assigned an individual suspicion + rating that represents how well that member's current + activity corresponds to the established patterns of usage + represented in the profile. This analysis can be performed + at runtime or during a post-collection batch-mode + analysis. + + + maintenance (deletion, modification, addition) of the + group of users in the profile target group. + + + + The TSF shall be able to maintain profiles of system usage, + where an individual profile represents the historical + patterns of usage performed by the member(s) of + + + the profile target group + + + + the PP/ST author should specify the profile target + group. A single PP/ST may include multiple profile + target groups. + + . + + + The TSF shall be able to maintain a suspicion rating + associated with each user whose activity is recorded in a + profile, where the suspicion rating represents the degree to + which the user's current activity is found + inconsistent with the established patterns of usage + represented in the profile. + + + The TSF shall be able to indicate a possible violation of + the enforcement of the SFRs when a user's suspicion rating exceeds + the following threshold conditions + + + conditions under which anomalous activity is reported by + the TSF + + + + the PP/ST author should specify conditions under which + anomalous activity is reported by the TSF. Conditions + may include the suspicion rating reaching a certain + value, or be based on the type of anomalous activity + observed. + + . + + + + + + + + In practice, it is at best rare when an analysis tool can + detect with certainty when a security violation is + imminent. However, there do exist some system events that + are so significant that they are always worthy of + independent review. Example of such events include the + deletion of a key TSF security data file (e.g. the + password file) or activity such as a remote user + attempting to gain administrative privilege. These events + are referred to as signature events in that their + occurrence in isolation from the rest of the system + activity are indicative of intrusive activity. + + The complexity of a given tool will depend greatly on the + assignments defined by the PP/ST author in identifying the + base set of signature events. + + The PP/ST author should enumerate specifically what events + should be monitored by the TSF in order to perform the + analysis. The PP/ST author should identify specifically + what information pertaining to the event is necessary to + determine if the event maps to a signature event. + + Administrative notification should be provided such that + the authorised user understands the significance of the + event and the appropriate possible responses. + + An effort was made in the specification of these + requirements to avoid a dependency on audit data as the + sole input for monitoring system activity. This was done + in recognition of the existence of previously developed + intrusion detection tools that do not perform their + analyses of system activity solely through the use of + audit data (examples of other input data include network + datagrams, resource/accounting data, or combinations of + various system data). + + The elements of do not + require that the TSF implementing the immediate attack + heuristics be the same TSF whose activity is being + monitored. Thus, one can develop an intrusion detection + component that operates independently of the system whose + system activity is being analysed. + + + + In , the TSF shall be able + to detect the occurrence of signature events that represent + a significant threat to enforcement of the SFRs. This search + for signature events may occur in real-time or during a + post-collection batch-mode analysis. + + + maintenance (deletion, modification, addition) of the subset + of system events. + + + + The TSF shall be able to maintain an internal representation + of the following signature events + + + a subset of system events + + + + the PP/ST author should identify a base subset of system + events whose occurrence, in isolation from all other + system activity, may indicate a violation of the + enforcement of the SFRs. These include events that by + themselves indicate a clear violation to the enforcement + of the SFRs, or whose occurrence is so significant that + they warrant actions. + + + that may indicate a violation of the enforcement of the SFRs. + + + The TSF shall be able to compare the signature events + against the record of system activity discernible from an + examination of + + + the information to be used to determine system activity + + + + the PP/ST author should specify the information used to + determine system activity. This information is the input + data used by the analysis tool to determine the system + activity that has occurred on the TOE. This data may + include audit data, combinations of audit data with + other system data, or may consist of data other than the + audit data. The PP/ST author should define precisely + what system events and event attributes are being + monitored within the input data. + + . + + + The TSF shall be able to indicate a potential violation of the + enforcement of the SFRs when a system event is found to match + a signature event that indicates a potential violation of the + enforcement of the SFRs. + + + + + + + + In practice, it is at best rare when an analysis tool can + detect with certainty when a security violation is + imminent. However, there do exist some system events that + are so significant they are always worthy of independent + review. Example of such events include the deletion of a key + TSF security data file (e.g. the password file) or activity + such as a remote user attempting to gain administrative + privilege. These events are referred to as signature events + in that their occurrence in isolation from the rest of the + system activity are indicative of intrusive activity. Event + sequences are an ordered set of signature events that might + indicate intrusive activity. + + The complexity of a given tool will depend greatly on the + assignments defined by the PP/ST author in identifying the + base set of signature events and event sequences. + + The PP/ST author should enumerate specifically what events + should be monitored by the TSF in order to perform the + analysis. The PP/ST author should identify specifically + what information pertaining to the event is necessary to + determine if the event maps to a signature event. + + Administrative notification should be provided such that + the authorised user understands the significance of the + event and the appropriate possible responses. + + An effort was made in the specification of these + requirements to avoid a dependency on audit data as the + sole input for monitoring system activity. This was done + in recognition of the existence of previously developed + intrusion detection tools that do not perform their + analyses of system activity solely through the use of + audit data (examples of other input data include network + datagrams, resource/accounting data, or combinations of + various system data). Levelling, therefore, requires the + PP/ST author to specify the type of input data used to + monitor system activity. + + The elements of do not + require that the TSF implementing the complex attack + heuristics be the same TSF whose activity is being + monitored. Thus, one can develop an intrusion detection + component that operates independently of the system whose + system activity is being analysed. + + + + In , the TSF shall be able to + represent and detect multi-step intrusion scenarios. The + TSF is able to compare system events (possibly performed + by multiple individuals) against event sequences known to + represent entire intrusion scenarios. The TSF shall be + able to indicate when a signature event or event sequence + is found that indicates a potential violation of the + enforcement of the SFRs. + + + maintenance (deletion, modification, addition) of the subset + of system events; + + + maintenance (deletion, modification, addition) of the set of + sequence of system events. + + + + The TSF shall be able to maintain an internal representation + of the following event sequences of known intrusion + scenarios + + + list of sequences of system events whose occurrence are + representative of known penetration scenarios + + + + the PP/ST author should identify a base set of list of + sequences of system events whose occurrence are + representative of known penetration scenarios. These + event sequences represent known penetration + scenarios. Each event represented in the sequence should + map to a monitored system event, such that as the system + events are performed, they are bound (mapped) to the + known penetration event sequences. + + + and the following signature events + + + a subset of system events + + + + the PP/ST author should identify a base subset of + system events whose occurrence, in isolation from all + other system activity, may indicate a violation of the + enforcement of the SFRs. These include events that by themselves indicate + a clear violation to the SFRs, or whose occurrence is + so significant they warrant action. + + + that may indicate a potential + violation of the enforcement of the SFRs. + + + The TSF shall be able to compare the signature events and + event sequences against the record of system activity + discernible from an examination of + + + the information to be used to determine system activity + + + + the PP/ST author should specify the information used to + determine system activity. This information is the input + data used by the analysis tool to determine the system + activity that has occurred on the TOE. This data may + include audit data, combinations of audit data with + other system data, or may consist of data other than the + audit data. The PP/ST author should define precisely + what system events and event attributes are being + monitored within the input data. + + . + + + The TSF shall be able to indicate a potential violation of the + enforcement of the SFRs when system activity is found to match + a signature event or event sequence that indicates a potential + violation of the enforcement of the SFRs. + + + + + + + + This family defines the requirements for audit tools that + should be available to authorised users to assist in the + review of audit data. + + + + The Security audit review family defines requirements + related to review of the audit information. + + These functions should allow pre-storage or post-storage + audit selection that includes, for example, the ability to + selectively review: + + + the actions of one or more users (e.g. identification, + authentication, TOE entry, and access control actions); + + + the actions performed on a specific object or TOE + resource; + + + all of a specified set of audited exceptions; + or + + + actions associated with a specific SFR attribute. + + + + The distinction between audit reviews is based on + functionality. Audit review (only) encompasses the ability to + view audit data. Selectable review is more sophisticated, and + requires the ability to select subsets of audit data based on a + single criterion or multiple criteria with logical (i.e. and/or) + relations, and order the audit data before it is + reviewed. + + + + + + + + + This component will provide authorised users the + capability to obtain and interpret the information. In + case of human users this information needs to be in a + human understandable presentation. In case of external IT + entities the information needs to be unambiguously + represented in an electronic fashion. + + + + This component is used to specify that users and/or + authorised users can read the audit records. These audit + records will be provided in a manner appropriate to the + user. There are different types of users (human users, + machine users) that might have different needs. + + The content of the audit records that can be viewed can be + specified. + + + + , provides the capability to read + information from the audit records. + + + maintenance (deletion, modification, addition) of the group + of users with read access right to the audit records. + + + Reading of information from the audit records. + + + The TSF shall provide + + + authorised users + + + + the PP/ST author should specify the authorised users + that can use this capability. If appropriate the PP/ST + author may include security roles (see ). + + + with the capability to read + + + list of audit information + + + + the PP/ST author should specify the type of information + the specified user is permitted to obtain from the audit + records. Examples are ``all'', ``subject identity'', + ``all information belonging to audit records referencing + this user''. When employing the SFR, FAU_SAR.1, it is not + necessary to repeat, in full detail, the list of audit + information first specified in FAU_GEN.1. Use of terms + such as ``all'' or ``all audit information'' assist in + eliminating ambiguity and the further need for + comparative analysis between the two security + requirements. + + + from the audit records. + + + The TSF shall provide the audit records in a manner suitable + for the user to interpret the information. + + + + + + + + + + This component specifies that any users not identified in + will not be able to read + the audit records. + + + + , requires that there are + no other users except those that have been identified in + that can read the + information. + + + Unsuccessful attempts to read information from the audit + records. + + + The TSF shall prohibit all users read access to the audit + records, except those users that have been granted explicit + read-access. + + + + + + + + + + This component is used to specify that it should be + possible to perform selection of the audit data to be + reviewed. If based on multiple criteria, those criteria + should be related together with logical + (i.e. ``and'' or + ``or'') relations, and the tools + should provide the ability to manipulate audit data + (e.g. sort, filter). + + + + , requires audit review + tools to select the audit data to be reviewed based on + criteria. + + + the parameters used for the viewing. + + + The TSF shall provide the ability to apply + + methods of selection and/or ordering + + the PP/ST author should specify whether capabilities to + select and/or order audit data is required from the + TSF. + of audit data based on + + criteria with logical relations + + the PP/ST author should assign the criteria, possibly + with logical relations, to be used to select the audit + data for review. The logical relations are intended to + specify whether the operation can be on an individual + attribute or a collection of attributes. An example of + this assignment could be: ``application, user account + and/or location''. In this case the operation could be + specified using any combination of the three attributes: + application, user account and location.. + + + + + + + + This family defines requirements to select the set of events to + be audited during TOE operation from the set of all auditable + events. + + + + The Security audit event selection family provides + requirements related to the capabilities of identifying which + of the possible auditable events are to be audited. The + auditable events are defined in the family, but those events should be defined as + being selectable in this component to be audited. + + This family ensures that it is possible to keep the audit + trail from becoming so large that it becomes useless, by + defining the appropriate granularity of the selected + security audit events. + + + + + + + + + + This component defines the selection criteria used, and the + resulting audited subsets of the set of all auditable events, + based on user attributes, subject attributes, object attributes, + or event types. + + The existence of individual user identities is not assumed + for this component. This allows for TOEs such as routers + that may not support the notion of users. + + For a distributed environment, the host identity could be + used as a selection criteria for events to be audited. + + The management function + will handle the rights of authorised users to query or + modify the selections. + + + , requires the ability to + select the set of events to be audited from the set of all + auditable events, identified in , based upon attributes to be specified by the + PP/ST author. + + + maintenance of the rights to view/modify the audit events. + + + All modifications to the audit configuration that occur + while the audit collection functions are operating. + + + The TSF shall be able to select the set of events to be audited from + the set of all auditable events based on the following + attributes: + object identityuser identitysubject identityhost identityevent type + the PP/ST author should select whether the + security attributes upon which audit selectivity + is based, is related to object identity, user + identity, subject identity, host identity, or event type. + list of additional attributes that audit selectivity is based upon + + the PP/ST author should specify any additional + attributes upon which audit selectivity is based. If + there are no additional rules upon which audit + selectivity is based, this assignment can be + completed with ``none''. + + + + + + + This family defines the requirements for the TSF to be able + to create and maintain a secure audit trail. Stored audit + records refers to those records within the audit trail, and + not the audit records that have been retrieved (to temporary + storage) through selection. + + + + The Security audit event storage family describes + requirements for storing audit data for later use, including + requirements controlling the loss of audit information due + to TOE failure, attack and/or exhaustion of storage + space. + + + + + + + + In a distributed environment, as the location of the audit + trail is in the TSF, but not necessarily co-located with + the function generating the audit data, the PP/ST author + could request authentication of the originator of the + audit record, or non-repudiation of the origin of the + record prior storing this record in the audit trail. + + The TSF will protect the stored audit records in the audit trail from unauthorised + deletion and modification. It is noted that in some TOEs the + auditor (role) might not be authorised to delete the audit + records for a certain period of time. + + + + At , requirements are + placed on the audit trail. It will be protected from + unauthorised deletion and/or modification. + + + The TSF shall protect the stored audit records in the audit + trail from unauthorised deletion. + + + The TSF shall be able to preventdetect the PP/ST author should specify whether the TSF + shall prevent or only be able to detect modifications of the + stored audit records in the audit trail. Only one of these + options may be + chosen. unauthorised + modifications to the stored audit records in the audit trail. + + + + + + + + + + + This component allows the PP/ST author to specify to which + metrics the audit trail should conform. + + In a distributed environment, as the location of the audit + trail is in the TSF, but not necessarily co-located with + the function generating the audit data, the PP/ST author + could request authentication of the originator of the + audit record, or non-repudiation of the origin of the + record prior storing this record in the audit trail. + + + + , specifies the guarantees + that the TSF maintains over the audit data given the + occurrence of an undesired condition. + + + maintenance of the parameters that control the audit storage + capability. + + + The TSF shall protect the stored audit records in the audit trail from + unauthorised deletion. + + + The TSF shall be able to preventdetect the PP/ST author should specify whether the TSF + shall prevent or only be able to detect modifications of the + stored audit records in the audit trail. Only one of these + options may be + chosen. unauthorised + modifications to the stored audit records in the audit trail. + + + The TSF shall ensure that + + + metric for saving audit records + + + + the PP/ST author should specify the metric that the TSF + must ensure with respect to the stored audit + records. This metric limits the data loss by enumerating + the number of records that must be kept, or the time + that records are guaranteed to be maintained. An example + of the metric could be ``100,000'' indicating that + 100,000 audit records can be stored. + + + stored audit records will be maintained when the + following conditions occur: + + audit storage exhaustion + failure + attack + + + the PP/ST author should specify the condition under which the + TSF shall still be able to maintain a defined amount of audit + data. This condition can be any of the following: audit + storage exhaustion, failure, attack. + + + + + + + + + + + + This component requires that actions will be taken when + the audit trail exceeds certain pre-defined limits. + + + + , specifies actions to be taken if a + threshold on the audit trail is exceeded. + + + maintenance of the threshold; + + + maintenance (deletion, modification, addition) of actions to + be taken in case of imminent audit storage failure. + + + Actions taken due to exceeding of a threshold. + + + The TSF shall + + + actions to be taken in case + of possible audit storage failure + + + + the PP/ST author should indicate the pre-defined + limit. If the management functions indicate that this + number might be changed by the authorised user, this + value is the default value. The PP/ST author might + choose to let the authorised user define this + limit. In that case the assignment can be for example + ``an authorised user set limit''. + + + if the audit trail exceeds + + + pre-defined limit + + + + the PP/ST author should specify actions that should be + taken in case of imminent audit storage failure + indicated by exceeding the threshold. Actions might + include informing an authorised user. + + . + + + + + + + + + + + This component specifies the behaviour of the TOE if the audit + trail is full: either audit records are ignored, or the TOE is + frozen such that no audited events can take place. The + requirement also states that no matter how the requirement is + instantiated, the authorised user with specific rights to this + effect, can continue to generate audited events (actions). The + reason is that otherwise the authorised user could not even + reset the TOE. Consideration should be given to the choice of + the action to be taken by the TSF in the case of audit storage + exhaustion, as ignoring events, which provides better + availability of the TOE, will also permit actions to be + performed without being recorded and without the user being + accountable. + + + + , specifies actions in case the + audit trail is full. + + + maintenance (deletion, modification, addition) of actions to + be taken in case of audit storage failure. + + + Actions taken due to the audit storage failure. + + + The TSF shall + ``ignore audited + events''``prevent audited events, + except those taken by the authorised user with special + rights'' + ``overwrite the oldest stored audit + records'' + + the PP/ST author should select whether the TSF shall ignore + audited actions, or whether it should prevent audited + actions from happening, or whether the oldest audit records + should be overwritten when the TSF can no longer store audit + records. Only one of these options may be chosen. + and + + other actions to be taken in case of audit storage + failure + + the PP/ST author should specify other actions that should be + taken in case of audit storage failure, such as informing the + authorised user. If there is no other action to be taken in + case of audit storage failure, this assignment can be + completed with ``none''. + if the audit trail is full. + + + + + + + + This class provides two families specifically concerned with + assuring the identity of a party participating in a data + exchange. These families are related to assuring the identity + of the originator of transmitted information (proof of origin) + and assuring the identity of the recipient of transmitted + information (proof of receipt). These families ensure that an + originator cannot deny having sent the message, nor can the + recipient deny having received it. + + + + This class describes requirements specifically of interest for + TOEs that are used for the transport of information. Families + within this class deal with non-repudiation. + + In this class the concept of ``information'' is + used. This information should be interpreted as the object + being communicated, and could contain an electronic mail + message, a file, or a set of predefined attribute types. + + In the literature, the terms ``proof of receipt'' + and ``proof of origin'' are commonly used + terms. However it is recognised that the term + ``proof'' might be interpreted in a legal sense to + imply a form of mathematical rationale. The components in this + class interpret the de-facto use of the word + ``proof'' in the context of ``evidence'' + that the TSF demonstrates the non-repudiated transport of + types of information. + + + + + + Non-repudiation of origin ensures that the originator of + information cannot successfully deny having sent the + information. This family requires that the TSF provide a + method to ensure that a subject that receives information + during a data exchange is provided with evidence of the + origin of the information. This evidence can then be + verified by either this subject or other subjects. + + + + Non-repudiation of origin defines requirements to provide + evidence to users/subjects about the identity of the + originator of some information. The originator cannot + successfully deny having sent the information because + evidence of origin (e.g. digital signature) provides + evidence of the binding between the originator and the + information sent. The recipient or a third party can verify + the evidence of origin. This evidence should not be + forgeable. + + If the information or the associated attributes are altered + in any way, validation of the evidence of origin might + fail. Therefore a PP/ST author should consider including + integrity requirements such as in the + PP/ST. + + In non-repudiation there are several different roles + involved, each of which could be combined in one or more + subjects. The first role is a subject that requests evidence + of origin (only in ). The second role + is the recipient and/or other subjects to which the evidence + is provided (e.g. a notary). The third role is a subject + that requests verification of the evidence of origin, for + example, a recipient or a third party such as an arbiter. + + The PP/ST author must specify the conditions that must be + met to be able to verify the validity of the evidence. An + example of a condition which could be specified is where the + verification of evidence must occur within 24 hours. These + conditions, therefore, allow the tailoring of the + non-repudiation to legal requirements, such as being able to + provide evidence for several years. + + In most cases, the identity of the recipient will be the + identity of the user who received the transmission. In some + instances, the PP/ST author does not want the user identity + to be exported. In that case the PP/ST author must consider + whether it is appropriate to include this class, or whether + the identity of the transport service provider or the + identity of the host should be used. + + In addition to (or instead of) the user identity, a PP/ST + author might be more concerned about the time the + information was transmitted. For example, requests for + proposals must be transmitted before a certain date in order + to be considered. In such instances, these requirements can + be customised to provide a timestamp indication (time of + origin). + + + + + + + + + , requires the TSF to provide + subjects with the capability to request evidence of the + origin of information. + + + The management of changes to information types, fields, + originator attributes and recipients of evidence. + + + The identity of the user who requested that evidence of + origin would be generated. + + + The invocation of the non-repudiation service. + + + Identification of the information, the destination, and a + copy of the evidence provided. + + + The identity of the user who requested a verification of the + evidence. + + + + The TSF shall be able to generate evidence of origin for + transmitted + + + list of information types + + + + the PP/ST author should fill in the types of + information subject to the evidence of origin + function, for example, electronic mail messages. + + + at the request of the + + + originator + + + recipient + + + + + list of third parties + + + + the PP/ST author, dependent on the selection, should specify the third + parties that can request evidence of origin. A third party could be an + arbiter, judge or legal body. + + + + + + the PP/ST author should specify the user/subject who + can request evidence of origin. + + . + + + The TSF shall be able to relate the + + + list of attributes + + + + the PP/ST author should fill in the list of the + attributes that shall be linked to the information; + for example, originator identity, time of origin, and + location of origin. + + + of the originator of the information, and the + + list of information fields + + + the PP/ST author should fill in the list of + information fields within the information over which + the attributes provide evidence of origin, such as the + body of a message. + + + of the information to which the evidence applies. + + + The TSF shall provide a capability to verify the evidence of + origin of information to + + + originator + + + recipient + + + + + list of third parties + + + + the PP/ST author, dependent on the selection, + should specify the third parties that can verify + the evidence of origin. + + + + + + the PP/ST author should specify the user/subject who + can verify the evidence of origin. + + + given + + + limitations on the evidence of origin + + + + the PP/ST author should fill in the list of + limitations under which the evidence can be + verified. For example the evidence can only be + verified within a 24 hour time interval. An assignment + of ``immediate'' or + ``indefinite'' is acceptable. + + . + + + + + + + + + + + , requires that the TSF always + generate evidence of origin for transmitted information. + + + + The invocation of the non-repudiation service. + + + Identification of the information, the destination, and a + copy of the evidence provided. + + + The identity of the user who requested a verification of the + evidence. + + + + The TSF shall enforce the generation of evidence of origin + for transmitted + + + list of information types + + + + the PP/ST author should fill in the types of + information subject to the evidence of origin + function, for example, electronic mail messages. + + + at all times. + + + The TSF shall be able to relate the + + + list of attributes + + + + the PP/ST author should fill in the list of the + attributes that shall be linked to the information; + for example, originator identity, time of origin, and + location of origin. + + + of the originator of the information, and the + + + list of information fields + + + + the PP/ST author should fill in the list of + information fields within the information over which + the attributes provide evidence of origin, such as the + body of a message. + + + of the information to which the evidence applies. + + + The TSF shall provide a capability to verify the evidence of + origin of information to + + + originator + + + recipient + + + + + list of third parties + + + + the PP/ST author, dependent on the selection, + should specify the third parties that can verify + the evidence of origin. A third party could be an + arbiter, judge or legal body. + + + + + + the PP/ST author should specify the user/subject who + can verify the evidence of origin. + + + given + + + limitations on the evidence of origin + + + + the PP/ST author should fill in the list of + limitations under which the evidence can be + verified. For example the evidence can only be + verified within a 24 hour time interval. An assignment + of ``immediate'' or + ``indefinite'' is acceptable. + + . + + + + + + + + Non-repudiation of receipt ensures that the recipient of + information cannot successfully deny receiving the + information. This family requires that the TSF provide a + method to ensure that a subject that transmits information + during a data exchange is provided with evidence of receipt + of the information. This evidence can then be verified by + either this subject or other subjects. + + + + Non-repudiation of receipt defines requirements to provide + evidence to other users/subjects that the information was + received by the recipient. The recipient cannot successfully + deny having received the information because evidence of + receipt (e.g. digital signature) provides evidence of the + binding between the recipient attributes and the + information. The originator or a third party can verify the + evidence of receipt. This evidence should not be forgeable. + + It should be noted that the provision of evidence that the + information was received does not necessarily imply that the + information was read or comprehended, but only delivered + + If the information or the associated attributes are altered + in any way, validation of the evidence of receipt with + respect to the original information might fail. Therefore a + PP/ST author should consider including integrity + requirements such as in the PP/ST. + + In non-repudiation, there are several different roles + involved, each of which could be combined in one or more + subjects. The first role is a subject that requests evidence + of receipt (only in ). The second role + is the recipient and/or other subjects to which the evidence + is provided, (e.g. a notary). The third role is a subject + that requests verification of the evidence of receipt, for + example, an originator or a third party such as an arbiter. + + The PP/ST author must specify the conditions that must be + met to be able to verify the validity of the evidence. An + example of a condition which could be specified is where the + verification of evidence must occur within 24 hours. These + conditions, therefore, allow the tailoring of the + non-repudiation to legal requirements, such as being able to + provide evidence for several years. + + In most cases, the identity of the recipient will be the + identity of the user who received the transmission. In some + instances, the PP/ST author does not want the user identity + to be exported. In that case, the PP/ST author must consider + whether it is appropriate to include this class, or whether + the identity of the transport service provider or the + identity of the host should be used. + + In addition to (or instead of) the user identity, a PP/ST + author might be more concerned about the time the + information was received. For example, when an offer expires + at a certain date, orders must be received before a certain + date in order to be considered. In such instances, these + requirements can be customised to provide a timestamp + indication (time of receipt). + + + + + + + + + , requires the TSF to provide + subjects with a capability to request evidence of the + receipt of information. + + + The management of changes to information types, fields, + originator attributes and third parties recipients of + evidence. + + + The identity of the user who requested that evidence of + receipt would be generated. + + + The invocation of the non-repudiation service. + + + Identification of the information, the destination, and a + copy of the evidence provided. + + + The identity of the user who requested a verification of the + evidence. + + + The TSF shall be able to generate + evidence of receipt for received + + + list of information types + + + + the PP/ST author should fill in the types of + information subject to the evidence of receipt + function, for example, electronic mail messages. + + + at the request of the + + + originator + + + recipient + + + + + list of third parties + + + + the PP/ST author, dependent on the selection, + should specify the third parties that can request + evidence of receipt. A third party could be an + arbiter, judge or legal body. + + + + + + the PP/ST author should specify the user/subject who + can request evidence of receipt. + + . + + + The TSF shall be able to relate the + + list of attributes + + + the PP/ST author should fill in the list of the + attributes that shall be linked to the information; + for example, recipient identity, time of receipt, and + location of receipt. + + + of the recipient of the information, and the + + + list of information fields + + + + the PP/ST author should fill in the list of + information fields with the fields within the + information over which the attributes provide evidence + of receipt, such as the body a message. + + + of the information to which the evidence applies. + + + The TSF shall provide a capability to verify the evidence of + receipt of information to + + + originator + + + recipient + + + + + list of third parties + + + + the PP/ST author, dependent on the selection, + should specify the third parties that can verify + the evidence of receipt. + + + + + + the PP/ST author should specify the user/subjects who + can verify the evidence of receipt. + + + given + + + limitations on the evidence of receipt + + + + the PP/ST author should fill in the list of + limitations under which the evidence can be + verified. For example the evidence can only be + verified within a 24 hour time interval. An assignment + of ``immediate'' or + ``indefinite'' is acceptable. + + . + + + + + + + + + + + , requires that the TSF always + generate evidence of receipt for received information. + + + + The invocation of the non-repudiation service. + + + Identification of the information, the destination, and a + copy of the evidence provided. + + + The identity of the user who requested a verification of the + evidence. + + + + The TSF shall enforce the generation of evidence of receipt + for received + + list of information types + + the PP/ST author should fill in the types of + information subject to the evidence of receipt + function, for example electronic mail messages. at all times. + + + The TSF shall be able to relate the + + list of attributes + + + the PP/ST author should fill in the list of the + attributes that shall be linked to the information; + for example, recipient identity, time of receipt, and + location of receipt. + + + of the recipient of the information, and the + + + list of information fields + + + + the PP/ST author should fill in the list of + information fields with the fields within the + information over which the attributes provide evidence + of receipt, such as the body of a message. + + + of the information to which the evidence applies. + + + The TSF shall provide a capability to verify the evidence of + receipt of information to + + + originator + + + recipient + + + + + list of third parties + + + + the PP/ST author, dependent on the selection, + should specify the third parties that can verify + the evidence of receipt. A third party could be an + arbiter, judge or legal body. + + + + + + the PP/ST author should specify the user/subjects who + can verify the evidence of receipt. + + + given + + + limitations on the evidence of receipt + + + + the PP/ST author should fill in the list of + limitations under which the evidence can be + verified. For example the evidence can only be + verified within a 24 hour time interval. An assignment + of ``immediate'' or + ``indefinite'' is acceptable. + + . + + + + + + + + The TSF may employ cryptographic functionality to help satisfy + several high-level security objectives. These include (but are + not limited to): identification and authentication, + non-repudiation, trusted path, trusted channel and data + separation. This class is used when the TOE implements + cryptographic functions, the implementation of which could be + in hardware, firmware and/or software. + + The class is composed of two families: and . The family addresses the management aspects of + cryptographic keys, while the family is + concerned with the operational use of those cryptographic + keys. + + + + The TSF may employ cryptographic functionality to help satisfy + several high-level security objectives. These include (but are + not limited to): identification and authentication, + non-repudiation, trusted path, trusted channel and data + separation. This class is used when the TOE implements + cryptographic functions, the implementation of which could be + in hardware, firmware and/or software. + + The class is composed of two families: and . The family addresses the management aspects of + cryptographic keys, while the family is + concerned with the operational use of those cryptographic + keys. + + For each cryptographic key generation method implemented by + the TOE, if any, the PP/ST author should select the component. + + For each cryptographic key distribution method implemented by + the TOE, if any, the PP/ST author should select the component. + + For each cryptographic key access method implemented by the + TOE, if any, the PP/ST author should select the component. + + For each cryptographic key destruction method implemented by + the TOE, if any, the PP/ST author should select the component. + + For each cryptographic operation (such as digital signature, + data encryption, key agreement, secure hash, etc.) performed + by the TOE, if any, the PP/ST author should select the component. + + Cryptographic functionality may be used to meet objectives + specified in class , and in families , , , + , , , to meet a variety of objectives. In the cases + where cryptographic functionality is used to meet objectives + for other classes, the individual functional components + specify the objectives that cryptographic functionality must + satisfy. The objectives in class should be + used when cryptographic functionality of the TOE is sought by + consumers. + + + + + + Cryptographic keys must be managed throughout their life + cycle. This family is intended to support that lifecycle and + consequently defines requirements for the following + activities: cryptographic key generation, cryptographic key + distribution, cryptographic key access and cryptographic key + destruction. This family should be included whenever there + are functional requirements for the management of + cryptographic keys. + + + + Cryptographic keys must be managed throughout their + lifetime. The typical events in the lifecycle of a + cryptographic key include (but are not limited to): + generation, distribution, entry, storage, access + (e.g. backup, escrow, archive, recovery) and destruction. + + The inclusion of other stages is dependent on the key management + strategy being implemented, as the TOE need not be involved in + all of the key life-cycle (e.g. the TOE may only generate and + distribute cryptographic keys). + + This family is intended to support the cryptographic key + lifecycle and consequently defines requirements for the + following activities: cryptographic key generation, + cryptographic key distribution, cryptographic key access and + cryptographic key destruction. This family should be + included whenever there are functional requirements for the + management of cryptographic keys. + + If Security Audit Data Generation is + included in the PP/ST then, in the context of the events + being audited: + + + The object attributes may include the assigned user + for the cryptographic key, the user role, the + cryptographic operation that the cryptographic key is + to be used for, the cryptographic key identifier and + the cryptographic key validity period. + + + The object value may include the values of cryptographic + key(s) and parameters excluding any sensitive + information (such as secret or private cryptographic + keys). + + + + Typically, random numbers are used to generate cryptographic + keys. If this is the case, then + should be used instead of the component . + In cases where random number generation is required for purposes other + than for the generation of cryptographic keys, the component + should be used. + + + + + + + + + + + + + + This component requires the cryptographic key sizes and + method used to generate cryptographic keys to be + specified, this can be in accordance with an assigned + standard. It should be used to specify the cryptographic + key sizes and the method (e.g. algorithm) used to generate + the cryptographic keys. Only one instance of the component + is needed for the same method and multiple key sizes. The + key size could be common or different for the various + entities, and could be either the input to or the output + from the method. + + + + , requires cryptographic keys to be + generated in accordance with a specified algorithm and key + sizes which can be based on an assigned standard. + + + + Success and failure of the activity. + + + The object attribute(s), and object value(s) excluding any + sensitive information (e.g. secret or private keys). + + + The TSF shall generate cryptographic keys in accordance with + a specified cryptographic key generation algorithm + + + cryptographic key generation algorithm + + + + the PP/ST author should specify the cryptographic key + generation algorithm to be used. + + + and specified cryptographic key sizes + + + cryptographic key sizes + + + + the PP/ST author should specify the cryptographic key + sizes to be used. The key sizes specified should be + appropriate for the algorithm and its intended use. + + + that meet the following: + + + list of standards + + + + the PP/ST author should specify the assigned standard + that documents the method used to generate + cryptographic keys. The assigned standard may comprise + none, one or more actual standards publications, for + example, from international, national, industry or + organisational standards. + + . + + + + + + + + + + + + + + + This component requires the method used to distribute + cryptographic keys to be specified, this can be in + accordance with an assigned standard. + + + + , requires cryptographic keys to be + distributed in accordance with a specified distribution + method which can be based on an assigned standard. + + + + + + The TSF shall distribute cryptographic keys in accordance + with a specified cryptographic key distribution method + + + cryptographic key distribution method + + + + the PP/ST author should specify the cryptographic key + distribution method to be used. + + + that meets the following: + + + list of standards + + + + the PP/ST author should specify the assigned standard + that documents the method used to distribute + cryptographic keys. The assigned standard may comprise + none, one or more actual standards publications, for + example, from international, national, industry or + organisational standards. + + . + + + + + + + + + + + + + + + This component requires the method used to access + cryptographic keys be specified, this can be in accordance + with an assigned standard. + + + + , requires access to cryptographic + keys to be performed in accordance with a specified access + method which can be based on an assigned standard. + + + + + + The TSF shall perform + + + type of cryptographic key access + + + + the PP/ST author should specify the type of + cryptographic key access being used. Examples of types + of cryptographic key access include (but are not + limited to) cryptographic key backup, cryptographic + key archival, cryptographic key escrow and + cryptographic key recovery. + + + in accordance with a specified cryptographic key access + method + + + cryptographic key access method + + + + the PP/ST author should specify the cryptographic key + access method to be used. + + + that meets the following: + + + list of standards + + + + the PP/ST author should specify the assigned standard + that documents the method used to access cryptographic + keys. The assigned standard may comprise none, one or + more actual standards publications, for example, from + international, national, industry or organisational + standards. + + . + + + + + + + + + + + + + + This component requires the method used to destroy + cryptographic keys be specified, this can be in accordance + with an assigned standard. + + + + , requires cryptographic keys to be + destroyed in accordance with a specified destruction + method which can be based on an assigned standard. + + + + + + The TSF shall destroy cryptographic keys in accordance with + a specified cryptographic key destruction method + + + cryptographic key destruction method + + + + the PP/ST author should specify the key destruction + method to be used to destroy cryptographic keys. + + + that meets the following: + + + list of standards + + + + the PP/ST author should specify the assigned standard + that documents the method used to destroy + cryptographic keys. The assigned standard may comprise + none, one or more actual standards publications, for + example, from international, national, industry or + organisational standards. + + . + + + + + + + + In order for a cryptographic operation to function + correctly, the operation must be performed in accordance + with a specified algorithm and with a cryptographic key of a + specified size. This family should be included whenever + there are requirements for cryptographic operations to be + performed. + + Typical cryptographic operations include data encryption + and/or decryption, digital signature generation and/or + verification, cryptographic checksum generation for + integrity and/or verification of checksum, secure hash + (message digest), cryptographic key encryption and/or + decryption, and cryptographic key agreement. + + + + A cryptographic operation may have cryptographic mode(s) of + operation associated with it. If this is the case, then the + cryptographic mode(s) must be specified. Examples of + cryptographic modes of operation are cipher block chaining, + output feedback mode, electronic code book mode, and cipher + feedback mode. + + Cryptographic operations may be used to support one or more + TOE security services. The component + may need to be iterated more than once depending on: + + + the user application for which the security service is + being used. + + + the use of different cryptographic algorithms and/or + cryptographic key sizes. + + + the type or sensitivity of the data being operated on. + + + + If Security audit data generation is + included in the PP/ST then, in the context of the + cryptographic operation events being audited: + + + The types of cryptographic operation may include digital + signature generation and/or verification, cryptographic + checksum generation for integrity and/or for + verification of checksum, secure hash (message digest) + computation, data encryption and/or decryption, + cryptographic key encryption and/or decryption, + cryptographic key agreement and random number + generation. + + + The subject attributes may include subject role(s) and + user(s) associated with the subject. + + + The object attributes may include the assigned user for + the cryptographic key, user role, cryptographic + operation the cryptographic key is to be used for, + cryptographic key identifier, and the cryptographic key + validity period. + + + + + + + + + + + + + + + This component requires the cryptographic algorithm and + key size used to perform specified cryptographic + operation(s) which can be based on an assigned standard. + + + + , requires a cryptographic operation + to be performed in accordance with a specified algorithm + and with a cryptographic key of specified sizes. The + specified algorithm and cryptographic key sizes can be + based on an assigned standard. + + + Success and failure, and the type of cryptographic + operation. + + + Any applicable cryptographic mode(s) of operation, subject + attributes and object attributes. + + + The TSF shall perform + + + list of cryptographic operations + + + + the PP/ST author should specify the cryptographic + operations being performed. Typical cryptographic + operations include digital signature generation and/or + verification, cryptographic checksum generation for + integrity and/or for verification of checksum, secure + hash (message digest) computation, data encryption + and/or decryption, cryptographic key encryption and/or + decryption, cryptographic key agreement and random + number generation. The cryptographic operation may be + performed on user data or TSF data. + + + in accordance with a specified cryptographic algorithm + + + cryptographic algorithm + + + + the PP/ST author should specify the cryptographic + algorithm to be used. Typical cryptographic algorithms + include, but are not limited to, DES, RSA and IDEA. + + + and cryptographic key sizes + + + cryptographic key sizes + + + + the PP/ST author should specify the cryptographic key + sizes to be used. The key sizes specified should be + appropriate for the algorithm and its intended use. + + + that meet the following: + + + list of standards + + + + the PP/ST author should specify the assigned standard + that documents how the identified cryptographic + operation(s) are performed. The assigned standard may + comprise none, one or more actual standards + publications, for example, from international, + national, industry or organisational standards. + + . + + + + + + + + This class contains families specifying requirements related + to protecting user data. is split + into four groups of families (listed below) that address user + data within a TOE, during import, export, and storage as well + as security attributes directly related to user data. + + The families in this class are organised into four groups: + + + User data protection security function policies: + + + ; and + + + . + + + + Components in these families permit the PP/ST author to + name the user data protection security function policies + and define the scope of control of the policy, necessary + to address the security objectives. The names of these + policies are meant to be used throughout the remainder + of the functional components that have an operation that + calls for an assignment or selection of an "access + control SFP" or an "information flow control + SFP". The rules that define the functionality of + the named access control and information flow control + SFPs will be defined in the and + families (respectively). + + + Forms of user data protection: + + + ; + + + ; + + + ; + + + ; + + + ; and + + + . + + + + + Off-line storage, import and export: + + + ; + + + ; + + + . + + + + Components in these families address the trustworthy + transfer into or out of the TOE. + + + Inter-TSF communication: + + + ; and + + + . + + + + Components in these families address communication + between the TSF of the TOE and another trusted IT + product. + + + + + + This class contains families specifying requirements related + to protecting user data. This class differs from FIA and FPT + in that specifies components to + protect user data, FIA specifies components to protect + attributes associated with the user, and FPT specifies + components to protect TSF information. + + The class does not contain explicit requirements for + traditional Mandatory Access Controls (MAC) or traditional + Discretionary Access Controls (DAC); however, such + requirements may be constructed using components from this + class. + + does not explicitly deal with + confidentiality, integrity, or availability, as all three are + most often intertwined in the policy and mechanisms. However, + the TOE security policy must adequately cover these three + objectives in the PP/ST. + + A final aspect of this class is that it specifies access + control in terms of ``operations''. An operation + is defined as a specific type of access on a specific + object. It depends on the level of abstraction of the PP/ST + author whether these operations are described as + ``read'' and/or ``write'' + operations, or as more complex operations such as + ``update the database''. + + The access control policies are policies that control access + to the information container. The attributes represent + attributes of the container. Once the information is out of + the container, the accessor is free to modify that + information, including writing the information into a + different container with different attributes. By contrast, an + information flow policies controls access to the information, + independent of the container. The attributes of the + information, which may be associated with the attributes of + the container (or may not, as in the case of a multi-level + database) stay with the information as it moves. The accessor + does not have the ability, in the absence of an explicit + authorisation, to change the attributes of the information. + + This class is not meant to be a complete taxonomy of IT access + policies, as others can be imagined. Those policies included + here are simply those for which current experience with actual + systems provides a basis for specifying requirements. There + may be other forms of intent that are not captured in the + definitions here. + + For example, one could imagine a goal of having user-imposed + (and user-defined) controls on information flow (e.g. an + automated implementation of the NO FOREIGN handling + caveat). Such concepts could be handled as refinements of, or + extensions to the components. + + Finally, it is important when looking at the components in + to remember that these components are + requirements for functions that may be implemented by a + mechanism that also serves or could serve another purpose. For + example, it is possible to build an access control policy + () that uses labels () as the basis of the access control + mechanism. + + A set of SFRs may encompass many security function + policies (SFPs), each to be identified by the two policy + oriented components , and . These policies will typically take + confidentiality, integrity, and availability aspects into + consideration as required, to satisfy the TOE + requirements. Care should be taken to ensure that all objects + are covered by at least one SFP and that there are no + conflicts arising from implementing the multiple SFPs. + + When building a PP/ST using components from the class, the following information provides guidance + on where to look and what to select from the class. + + The requirements in the class are defined in + terms of a set of SFRs that will + implement a SFP. Since a TOE may implement multiple SFPs + simultaneously, the PP/ST author must specify the name for + each SFP, so it can be referenced in other families. This name + will then be used in each component selected to indicate that + it is being used as part of the definition of requirements for + that SFP. This allows the author to easily indicate the + scope for operations such as objects covered, operations + covered, authorised users, etc. + + Each instantiation of a component can apply to only one + SFP. Therefore if an SFP is specified in a component then + this SFP will apply to all the elements in this + component. The components may be instantiated multiple times + within a PP/ST to account for different policies if so + desired. + + The key to selecting components from this family is to have a + well defined set of TOE security objectives to enable proper + selection of the components from the two policy components; + and . In and respectively, all access control + policies and all information flow control policies are + named. Furthermore the scope of control of these components in + terms of the subjects, objects and operations covered by this + security functionality. The names of these policies are meant + to be used throughout the remainder of the functional + components that have an operation that calls for an assignment + or selection of an ``access control SFP'' or an ``information + flow control SFP''. The rules that define the functionality + of the named access control and information flow control SFPs + will be defined in the and + families + (respectively). + + The following steps are guidance on how this class is applied + in the construction of a PP/ST: + + + Identify the policies to be enforced from the , and families. These + families define scope of control for the policy, + granularity of control and may identify some rules to go + with the policy. + + + Identify the components and perform any applicable operations + in the policy components. The assignment operations may be + performed generally (such as with a statement ``All + files'') or specifically (``The files + ``A'', ``B'', etc.) depending upon + the level of detail known. + + + Identify any applicable function components from the and families to address + the named policy families from and + . Perform the operations to make the + components define the rules to be enforced by the named + policies. This should make the components fit the + requirements of the selected function envisioned or to be + built. + + + Identify who will have the ability to control and change + security attributes under the function, such as only a + security administrator, only the owner of the object, + etc. Select the appropriate components from + and perform the operations. Refinements may be useful here + to identify missing features, such as that some or all + changes must be done via trusted path. + + + Identify any appropriate components from the for initial values for new objects and subjects. + + + Identify any applicable rollback components from the family. + + + Identify any applicable residual information protection + requirements from the family. + + + Identify any applicable import or export components, and how + security attributes should be handled during import and + export, from the and families. + + + Identify any applicable internal TOE communication + components from the family. + + + Identify any requirements for integrity protection of stored + information from the . + + + Identify any applicable inter-TSF communication components + from the or + families. + + + + + + + + This family identifies the access control SFPs (by name) and + defines the scope of control of the policies that form the + identified access control portion of the SFRs related to the + SFP. This scope of control is characterised by three sets: the + subjects under control of the policy, the objects under control + of the policy, and the operations among controlled subjects and + controlled objects that are covered by the policy. The criteria + allows multiple policies to exist, each having a unique name. + This is accomplished by iterating components from this family + once for each named access control policy. The rules that + define the functionality of an access control SFP will be + defined by other families such as and . The names + of the access control SFPs identified here in are meant to be used throughout the remainder of + the functional components that have an operation that calls for + an assignment or selection of an ``access control SFP.'' + + + + This family is based upon the concept of arbitrary controls + on the interaction of subjects and objects. The scope and + purpose of the controls is based upon the attributes of the + accessor (subject), the attributes of the container being + accessed (object), the actions (operations) and any + associated access control rules. + + The components in this family are capable of identifying the + access control SFPs (by name) to be enforced by the traditional + Discretionary Access Control (DAC) mechanisms. It further + defines the subjects, objects and operations that are covered by + identified access control SFPs. The rules that define the + functionality of an access control SFP will be defined by other + families, such as and . The names of the access control SFPs + defined in are meant to be used + throughout the remainder of the functional components that have + an operation that calls for an assignment or selection of an + ``access control SFP.'' + + The access control SFP covers a set of triplets: subject, + object, and operations. Therefore a subject can be covered + by multiple access control SFPs but only with respect to a + different operation or a different object. Of course the + same applies to objects and operations. + + A critical aspect of an access control function that + enforces an access control SFP is the ability for users to + modify the attributes involved in access control + decisions. The family does not address + these aspects. Some of these requirements are left + undefined, but can be added as refinements, while others are + covered elsewhere in other families and classes such as + . + + There are no audit requirements in as + this family specifies access control SFP requirements. Audit + requirements will be found in families specifying functions + to satisfy the access control SFPs identified in this + family. + + This family provides a PP/ST author the capability to + specify several policies, for example, a fixed access + control SFP to be applied to one scope of control, and a + flexible access control SFP to be defined for a different + scope of control. To specify more than one access control + policy, the components from this family can be iterated + multiple times in a PP/ST to different subsets of operations + and objects. This will accommodate TOEs that contain + multiple policies, each addressing a particular set of + operations and objects. In other words, the PP/ST author + should specify the required information in the ACC component + for each of the access control SFPs that the TSF will + enforce. For example, a TOE incorporating three access + control SFPs, each covering only a subset of the objects, + subjects, and operations within the TOE, will contain one + component for each of the three + access control SFPs, necessitating a total of three components. + + + + + + + + + The terms object and subject refer to generic elements in + the TOE. For a policy to be implementable, the entities + must be clearly identified. For a PP, the objects and + operations might be expressed as types such as: named + objects, data repositories, observe accesses, etc. For a + specific TOE these generic terms (subject, object) must be + refined, e.g. files, registers, ports, daemons, open + calls, etc. + + This component specifies that the policy cover some + well-defined set of operations on some subset of the + objects. It places no constraints on any operations + outside the set - including operations on objects for + which other operations are controlled. + + + + , requires that each identified + access control SFP be in place for a subset of the + possible operations on a subset of the objects in the TOE. + + + The TSF shall enforce the + + + access control SFP + + + + the PP/ST author should specify a uniquely named + access control SFP to be enforced by the TSF. + + + on + + + list of subjects, objects, and operations among subjects + and objects covered by the SFP + + + + the PP/ST author should specify the list of subjects, + objects, and operations among subjects and objects + covered by the SFP. + + . + + + + + + + + + + + This component requires that all possible operations on + objects, that are included in the SFP, are covered by an + access control SFP. + + The PP/ST author must demonstrate that each combination of + objects and subjects is covered by an access control SFP. + + + + , requires that each identified + access control SFP cover all operations on subjects and + objects covered by that SFP. It further requires that all + objects and operations protected by the TSF are covered by at + least one identified access control SFP. + + + The TSF shall enforce the + + + access control SFP + + + + the PP/ST author should specify a uniquely named + access control SFP to be enforced by the TSF. + + + on + + + list of subjects and objects + + + + the PP/ST author should specify the list of subjects + and objects covered by the SFP. All operations among + those subjects and objects will be covered by the SFP. + + + and all operations among subjects and objects covered by the + SFP. + + + 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. + + + + + + + + This family describes the rules for the specific functions + that can implement an access control policy named in . specifies the scope of control of the + policy. + + + + This family describes the rules for the specific functions + that can implement an access control policy named in which also specifies the scope of + control of the policy. + + This family provides a PP/ST author the capability to + describe the rules for access control. This results in a + TOE where the access to objects will not change. An + example of such an object is ``Message of the Day'', which + is readable by all, and changeable only by the authorised + administrator. This family also provides the PP/ST author + with the ability to describe rules that provide for + exceptions to the general access control rules. Such + exceptions would either explicitly allow or deny + authorisation to access an object. + + There are no explicit components to specify other possible + functions such as two-person control, sequence rules for + operations, or exclusion controls. However, these + mechanisms, as well as traditional DAC mechanisms, can be + represented with the existing components, by careful + drafting of the access control rules. + + A variety of acceptable access control functionality may be + specified in this family such as: + + + Access control lists (ACLs) + + + Time-based access control specifications + + + Origin-based access control specifications + + + Owner-controlled access control attributes + + + + + + + + + + + This component provides requirements for a mechanism that + mediates access control based on security attributes + associated with subjects and objects. Each object and + subject has a set of associated attributes, such as + location, time of creation, access rights (e.g., Access + Control Lists (ACLs)). This component allows the PP/ST + author to specify the attributes that will be used for the + access control mediation. This component allows access + control rules, using these attributes, to be + specified. + + Examples of the attributes that a PP/ST author might + assign are presented in the following paragraphs. + + An identity attribute may be associated with users, + subjects, or objects to be used for mediation. Examples of + such attributes might be the name of the program image + used in the creation of the subject, or a security + attribute assigned to the program image. + + A time attribute can be used to specify that access will + be authorised during certain times of the day, during + certain days of the week, or during a certain calendar + year. + + A location attribute could specify whether the location is + the location of the request for the operation, the + location where the operation will be carried out, or + both. It could be based upon internal tables to translate + the logical interfaces of the TSF into locations such as + through terminal locations, CPU locations, etc. + + A grouping attribute allows a single group of users to be + associated with an operation for the purposes of access + control. If required, the refinement operation should be + used to specify the maximum number of definable groups, + the maximum membership of a group, and the maximum number + of groups to which a user can concurrently be + associated. + + This component also provides requirements for the access + control security functions to be able to explicitly + authorise or deny access to an object based upon security + attributes. This could be used to provide privilege, + access rights, or access authorisations within the + TOE. Such privileges, rights, or authorisations could + apply to users, subjects (representing users or + applications), and objects. + + + + This family addresses security attribute usage and + characteristics of policies. The component within this + family is meant to be used to describe the rules for the + function that implements the SFP as identified in . The PP/ST author may also + iterate this component to address multiple policies in the + TOE. + + Security attribute + based access control allows the TSF to enforce access + based upon security attributes and named groups of + attributes. Furthermore, the TSF may have the ability to + explicitly authorise or deny access to an object based + upon security attributes. + + + Managing the attributes used to make explicit access or + denial based decisions. + + + Successful requests to perform an operation on an object + covered by the SFP. + + + All requests to perform an operation on an object covered by + the SFP. + + + The specific security attributes used in making an access + check. + + + The TSF shall enforce the + + access control SFP + + the PP/ST author should specify an access control SFP + name that the TSF is to enforce. The name of the access + control SFP, and the scope of control for that policy + are defined in components from . + to objects based on the following: + + list of subjects and objects controlled under the + indicated SFP, and for each, the SFP-relevant security + attributes, or named groups of SFP-relevant security + attributes + + the PP/ST author should specify, for each controlled + subject and object, the security attributes and/or named + groups of security attributes that the function will use + in the specification of the rules. For example, such + attributes may be things such as the user identity, + subject identity, role, time of day, location, ACLs, or + any other attribute specified by the PP/ST author. Named + groups of security attributes can be specified to + provide a convenient means to refer to multiple security + attributes. Named groups could provide a useful way to + associate ``roles'' defined in , and + all of their relevant attributes, with subjects. In + other words, each role could relate to a named group of + attributes.. + + + The TSF shall enforce the following rules to determine if an + operation among controlled subjects and controlled objects + is allowed: + + + rules governing access among controlled subjects and + controlled objects using controlled operations on + controlled objects + + + + the PP/ST author should specify the SFP rules + governing access among controlled subjects and + controlled objects using controlled operations on + controlled objects. These rules specify when access + is granted or denied. It can specify general access + control functions (e.g. typical permission bits) or + granular access control functions (e.g. ACLs). + + . + + + The TSF shall explicitly authorise access of subjects to + objects based on the following additional rules: + + + rules, based on security attributes, that explicitly + authorise access of subjects to objects + + + + the PP/ST author should specify the rules, based on + security attributes, that explicitly authorise access + of subjects to objects that will be used to explicitly + authorise access. These rules are in addition to those + specified in . They are + included in as they are + intended to contain exceptions to the rules in . An example of rules to explicitly + authorise access is based on a privilege vector + associated with a subject that always grants access to + objects covered by the access control SFP that has + been specified. If such a capability is not desired, + then the PP/ST author should specify + ``none''. + + . + + + The TSF shall explicitly deny access of subjects to objects based on the + following additional rules: + rules, based on security attributes, that + explicitly deny access of subjects to objects the PP/ST author should specify the rules, + based on security attributes, that explicitly deny access of subjects + to objects. These rules are in addition to those specified in + + . They are included in + + as they are intended to contain exceptions to the rules in + + . An example of rules to explicitly deny access is based on a privilege + vector associated with a subject + that always denies access to objects covered by the access control SFP + that has been specified. If such a capability is not desired, then the + PP/ST author should specify ``none''.. + + + + + + + + Data authentication permits an entity to accept + responsibility for the authenticity of information (e.g., by + digitally signing it). This family provides a method of + providing a guarantee of the validity of a specific unit of + data that can be subsequently used to verify that the + information content has not been forged or fraudulently + modified. In contrast to , this family is + intended to be applied to "static" data rather + than data that is being transferred. + + + + This family describes specific functions that can be used to + authenticate ``static'' data. + + Components in this family are to be used when there is a + requirement for ``static'' data + authentication, i.e. where data is to be signed but not + transmitted. (Note that the family + provides for non-repudiation of origin of information + received during a data exchange.) + + + + + + This component may be satisfied by one-way hash functions + (cryptographic checksum, fingerprint, message digest), to + generate a hash value for a definitive document that may + be used as verification of the validity or authenticity of + its information content. + + + + , requires that the TSF is capable + of generating a guarantee of authenticity of the + information content of objects (e.g. documents). + + + The assignment or modification of the objects for which data + authentication may apply could be configurable. + + + Successful generation of validity evidence. + + + Unsuccessful generation of validity evidence. + + + The identity of the subject that requested the evidence. + + + The TSF shall provide a capability to generate evidence that + can be used as a guarantee of the validity of + + + list of objects or information types + + + + the PP/ST author should specify the list of objects or + information types for which the TSF shall be capable + of generating data authentication evidence. + + . + + + The TSF shall provide + + + list of subjects + + + + the PP/ST author should specify the list of subjects + that will have the ability to verify data + authentication evidence for the objects identified in + the previous element. The list of subjects could be + very specific, if the subjects are known, or it could + be more generic and refer to a + ``type'' of subject such + as an identified role. + + + with the ability to verify evidence of the validity of the + indicated information. + + + + + + + + + + + This component additionally requires the ability to verify + the identity of the user that provided the guarantee of + authenticity (e.g. a trusted third party). + + + + additionally requires that the TSF + is capable of establishing the identity of the subject who + provided the guarantee of authenticity. + + + + Successful generation of validity evidence. + + + Unsuccessful generation of validity evidence. + + + The identity of the subject that requested the evidence. + + + The identity of the subject that generated the evidence. + + + The TSF shall provide a capability to generate evidence that + can be used as a guarantee of the validity of + + + list of objects or information types + + + + the PP/ST author should specify the list of objects or + information types for which the TSF shall be capable + of generating data authentication evidence. + + . + + + The TSF shall provide + + + list of subjects + + + + the PP/ST author should specify the list of subjects + that will have the ability to verify data + authentication evidence for the objects identified in + the previous element as well as the identity of the + user that created the data authentication evidence. + + + with the ability to verify evidence of the validity of the + indicated information and the identity of the user that + generated the evidence. + + + + + + + + This family defines functions for TSF-mediated exporting of user data from + the TOE such that its security attributes and protection + either can be explicitly preserved or can be ignored once it + has been exported. It is concerned with limitations on + export and with the association of security attributes with + the exported user data. + + + + This family defines functions for TSF-mediated exporting of user data from + the TOE such that its security attributes either can be + explicitly preserved or can be ignored once it has been + exported. Consistency of these security attributes are + addressed by . + + is concerned with limitations on export + and association of security attributes with the exported + user data. + + This family, and the corresponding Import family , address how the TOE deals with user data + transferred into and outside its control. In principle this + family is concerned with the TSF-mediated exporting of user data and its + related security attributes. + + A variety of activities might be involved here: + + + exporting of user data without any security attributes; + + + exporting user data including security attributes where + the two are associated with one another and the security + attributes unambiguously represent the exported user + data. + + + + If there are multiple SFPs (access control and/or + information flow control) then it may be appropriate to + iterate these components once for each named SFP. + + + + + + + + + + + + This component is used to specify the TSF-mediated exporting of user data + without the export of its security attributes. + + + + , requires that the TSF enforce the + appropriate SFPs when exporting user data outside the + TSF. User data that is exported by this function is + exported without its associated security attributes. + + + Successful export of information. + + + All attempts to export information. + + + The TSF shall enforce the + + + access control SFP(s) and/or information flow control + SFP(s) + + + + the PP/ST author should specify the access control + SFP(s) and/or information flow control SFP(s) that + will be enforced when exporting user data. The user + data that this function exports is scoped by the + assignment of these SFPs. + + + when exporting user data, controlled under the SFP(s), + outside of the TOE. + + + The TSF shall export the user data without the user + data's associated security attributes + + + + + + + + + + + + + The user data is exported together with its security + attributes. The security attributes are unambiguously + associated with the user data. There are several ways of + achieving this association. One way that this can be + achieved is by physically collocating the user data and + the security attributes (e.g. the same floppy), or by + using cryptographic techniques such as secure signatures + to associate the attributes and the user data. could be used to assure that the attributes + are correctly received at the other trusted IT product + while can be used to make sure that + those attributes are properly interpreted. Furthermore, + could be used to make sure that the + export is being initiated by the proper user. + + + + , requires that the TSF enforce the + appropriate SFPs using a function that accurately and + unambiguously associates security attributes with the user + data that is exported. + + + The additional exportation control rules could be + configurable by a user in a defined role. + + + + + The TSF shall enforce the + + + access control SFP(s) and/or information flow control + SFP(s) + + + + the PP/ST author should specify the access control + SFP(s) and/or information flow control SFP(s) that + will be enforced when exporting user data. The user + data that this function exports is scoped by the + assignment of these SFPs. + + + when exporting user data, controlled under the SFP(s), + outside of the TOE. + + + The TSF shall export the user data with the user + data's associated security attributes. + + + The TSF shall ensure that the security attributes, when + exported outside the TOE, are unambiguously associated with + the exported user data. + + + The TSF shall enforce the following rules when user data is + exported from the TOE: + + + additional exportation control rules + + + + the PP/ST author should specify any additional + exportation control rules or + ``none'' if there are no + additional exportation control rules. These rules will + be enforced by the TSF in addition to the access + control SFPs and/or information flow control SFPs + selected in . + + . + + + + + + + + This family identifies the information flow control SFPs (by + name) and defines the scope of control for each named + information flow control SFP. This scope of control is + characterised by three sets: the subjects under control of the + policy, the information under control of the policy, and + operations which cause controlled information to flow to and + from controlled subjects covered by the policy. The criteria + allows multiple policies to exist, each having a unique name. + This is accomplished by iterating components from this family + once for each named information flow control policy. The rules + that define the functionality of an information flow control SFP + will be defined by other families such as and . The names + of the information flow control SFPs identified here in are meant to be used throughout the + remainder of the functional components that have an operation + that calls for an assignment or selection of an ``information + flow control SFP.'' + + The TSF mechanism controls the flow of information in + accordance with the information flow control SFP. Operations + that would change the security attributes of information are + not generally permitted as this would be in violation of an + information flow control SFP. However, such operations may + be permitted as exceptions to the information flow control + SFP if explicitly specified. + + + + This family covers the identification of information flow + control SFPs; and, for each, specifies the scope of control + of the SFP. + + The components in this family are capable of identifying the + information flow control SFPs to be enforced by the traditional + Mandatory Access Control mechanisms that would be found in a + TOE. However, they go beyond just the traditional MAC mechanisms + and can be used to identify and describe non-interference + policies and state-transitions. It further defines the subjects + under control of the policy, the information under control of + the policy, and operations which cause controlled information to + flow to and from controlled subjects for each information flow + control SFP in the TOE. The information flow control SFP will be + defined by other families such as and . The + information flow control SFPs named here in are meant to be used throughout the remainder of + the functional components that have an operation that calls for + an assignment or selection of an ``information flow control + SFP.'' + + These components are quite flexible. They allow the domain + of flow control to be specified and there is no requirement + that the mechanism be based upon labels. The different + elements of the information flow control components also + permit different degrees of exception to the policy. + + Each SFP covers a set of triplets: subject, information, and + operations that cause information to flow to and from + subjects. Some information flow control policies may be at a + very low level of detail and explicitly describe subjects in + terms of processes within an operating system. Other + information flow control policies may be at a high level and + describe subjects in the generic sense of users or + input/output channels. If the information flow control + policy is at too high a level of detail, it may not clearly + define the desired IT security functions. In such cases, it + is more appropriate to include such descriptions of + information flow control policies as objectives. Then the + desired IT security functions can be specified as supportive + of those objectives. + + In the second component (), each + information flow control SFP will cover all possible + operations that cause information covered by that SFP to + flow to and from subjects covered by that SFP. Furthermore, + all information flows will need to be covered by a + SFP. Therefore for each action that causes information to + flow, there will be a set of rules that define whether the + action is allowed. If there are multiple SFPs that are + applicable for a given information flow, all involved SFPs + must allow this flow before it is permitted to take place. + + An information flow control SFP covers a well-defined set of + operations. The SFPs coverage may be + ``complete'' with respect to some + information flows, or it may address only some of the + operations that affect the information flow. + + An access control SFP controls access to the objects that + contain information. An information flow control SFP + controls access to the information, independent of its + container. The attributes of the information, which may be + associated with the attributes of the container (or may not, + as in the case of a multi-level database) stay with the + information as it flows. The accessor does not have the + ability, in the absence of an explicit authorisation, to + change the attributes of the information. + + Information flows and operations can be expressed at + multiple levels. In the case of a ST, the information flows + and operations might be specified at a system-specific + level: TCP/IP packets flowing through a firewall based upon + known IP addresses. For a PP, the information flows and + operations might be expressed as types: email, data + repositories, observe accesses, etc. + + The components in this family can be applied multiple times + in a PP/ST to different subsets of operations and + objects. This will accommodate TOEs that contain multiple + policies, each addressing a particular set of objects, + subjects, and operations. + + + + + + + + + This component requires that an information flow control + policy apply to a subset of the possible operations in the + TOE. + + + + , requires that each identified + information flow control SFPs be in place for a subset of + the possible operations on a subset of information flows + in the TOE. + + + The TSF shall enforce the + + + information flow control SFP + + + + the PP/ST author should specify a uniquely named + information flow control SFP to be enforced by the + TSF. + + + on + + + list of subjects, information, and operations that cause + controlled information to flow to and from controlled + subjects covered by the SFP + + + + the PP/ST author should specify the list of subjects, + information, and operations which cause controlled + information to flow to and from controlled subjects + covered by the SFP. As mentioned above, the list of + subjects could be at various levels of detail + depending on the needs of the PP/ST author. It could + specify users, machines, or processes for + example. Information could refer to data such as email + or network protocols, or more specific objects similar + to those specified under an access control policy. If + the information that is specified is contained within + an object that is subject to an access control policy, + then both the access control policy and information + flow control policy must be enforced before the + specified information could flow to or from the + object. + + . + + + + + + + + + + + This component requires that all possible operations that + cause information to flow to and from subjects included in + the SFP, are covered by an information flow control SFP. + + The PP/ST author must demonstrate that each combination of + information flows and subjects is covered by an + information flow control SFP. + + + + , requires that each identified + information flow control SFP cover all operations on + subjects and information covered by that SFP. It further + requires that all information flows and operations controlled + by the TSF are covered by at least one identified information + flow control SFP. + + + The TSF shall enforce the + + + information flow control SFP + + + + the PP/ST author should specify a uniquely named + information flow control SFP to be enforced by the + TSF. + + + on + + + list of subjects and information + + + + the PP/ST author should specify the list of subjects + and information that will be covered by the SFP. All + operations that cause that information to flow to and + from subjects will be covered by the SFP. As mentioned + above, the list of subjects could be at various levels + of detail depending on the needs of the PP/ST + author. It could specify users, machines, or processes + for example. Information could refer to data such as + email or network protocols, or more specific objects + similar to those specified under an access control + policy. If the information that is specified is + contained within an object that is subject to an + access control policy, then both the access control + policy and information flow control policy must be + enforced before the specified information could flow + to or from the object. + + + and all operations that cause that information to flow to + and from subjects covered by the SFP. + + + The TSF shall ensure that all operations that cause any + information in the TOE to flow to and from any subject in + the TOE are covered by an information flow control SFP. + + + + + + + + This family describes the rules for the specific functions + that can implement the information flow control SFPs named + in , which also specifies the scope of + control of the policy. It consists of two kinds of + requirements: one addressing the common information flow + function issues, and a second addressing illicit information + flows (i.e. covert channels). This division arises because + the issues concerning illicit information flows are, in some + sense, orthogonal to the rest of an information flow control + SFP. By their nature they circumvent the information flow + control SFP resulting in a violation of the policy. As such, + they require special functions to either limit or prevent + their occurrence. + + + + This family describes the rules for the specific functions + that can implement the information flow control SFPs named + in , which also specifies the scope of + control of the policies. It consists of two + ``trees:'' one addressing the common + information flow control function issues, and a second + addressing illicit information flows (i.e. covert channels) + with respect to one or more information flow control + SFPs. This division arises because the issues concerning + illicit information flows are, in some sense, orthogonal to + the rest of an SFP. Illicit information flows are flows in + violation of policy; thus they are not a policy issue. + + In order to implement strong protection against disclosure + or modification in the face of untrusted software, controls + on information flow are required. Access controls alone are + not sufficient because they only control access to + containers, allowing the information they contain to flow, + without controls, throughout a system. + + In this family, the phrase ``types of illicit + information flows'' is used. This phrase may be + used to refer to the categorisation of flows as + ``Storage Channels'' or + ``Timing Channels'', or it can refer to + improved categorisations reflective of the needs of a PP/ST + author. + + The flexibility of these components allows the definition of + a privilege policy within and to allow the controlled bypass of all or + part of a particular SFP. If there is a need for a + predefined approach to SFP bypass, the PP/ST author should + consider incorporating a privilege policy. + + + + + + + + + + This component requires security attributes on + information, and on subjects that cause that information + to flow and subjects that act as recipients of that + information. The attributes of the containers of the + information should also be considered if it is desired + that they should play a part in information flow control + decisions or if they are covered by an access control + policy. This component specifies the key rules that are + enforced, and describes how security attributes are + derived. + + This component does not specify the details of how a + security attribute is assigned (i.e. user versus + process). Flexibility in policy is provided by having + assignments that allow specification of additional policy + and function requirements, as necessary. + + This component also provides requirements for the + information flow control functions to be able to + explicitly authorise and deny an information flow based + upon security attributes. This could be used to implement + a privilege policy that covers exceptions to the basic + policy defined in this component. + + + + , requires security attributes on + information, and on subjects that cause that information + to flow and on subjects that act as recipients of that + information. It specifies the rules that must be enforced + by the function, and describes how security attributes are + derived by the function. + + + Managing the attributes used to make explicit access based + decisions. + + + Decisions to permit requested information flows. + + + All decisions on requests for information flow. + + + The specific security attributes used in making an + information flow enforcement decision. + + + Some specific subsets of the information that has flowed + based upon policy goals (e.g. auditing of downgraded + material). + + + The TSF shall enforce the + + + information flow control SFP + + + + the PP/ST author should specify the information flow + control SFPs enforced by the TSF. The name of the + information flow control SFP, and the scope of control + for that policy are defined in components from + . + + + based on the following types of subject and + information security attributes: + + list of subjects and information controlled under the + indicated SFP, and for each, the security attributes + + the PP/ST author should specify, for each type of + controlled subject and information, the security + attributes that are relevant to the specification of the + SFP rules. For example, such security attributes may be + things such the subject identifier, subject sensitivity + label, subject clearance label, information sensitivity + label, etc. The types of security attributes should be + sufficient to support the environmental needs.. + + + The TSF shall permit an information flow between a + controlled subject and controlled information via a + controlled operation if the following rules hold: + + + for each operation, the security attribute-based + relationship that must hold between subject and + information security attributes + + + + the PP/ST author should specify for each operation, + the security attribute-based relationship that must + hold between subject and information security + attributes that the TSF will enforce. + + . + + + The TSF shall enforce the + + + additional information flow control SFP rules + + + the PP/ST author should specify any additional information + flow control SFP rules that the TSF is to enforce. This + includes all rules of the SFP that are either not based on the + security attributes of the information and the subject or + rules that automatically modify the security attributes of + information or subjects as a result of an access operation. + An example for the first case is a rule of the SFP controlling + a threshold value for specific types of information. This + would for example be the case when the information flow SFP + contains rules on access to statistical data where a subject + is only allowed to access this type of information up to a + specific number of accesses. An example for the second case + would be a rule stating under which conditions and how the + security attributes of a subject or object change as the + result of an access operation. Some information flow policies + for example may limit the number of access operations to + information with specific security attributes. If there are + no additional rules then the PP/ST author should specify + ``none''. + . + + + + The TSF shall explicitly authorise an information flow based + on the following rules: + + + rules, based on security attributes, that explicitly + authorise information flows + + + + the PP/ST author should specify the rules, based on + security attributes, that explicitly authorise + information flows. These rules are in addition to + those specified in the preceding elements. They are + included in as they are + intended to contain exceptions to the rules in the + preceding elements. An example of rules to explicitly + authorise information flows is based on a privilege + vector associated with a subject that always grants + the subject the ability to cause an information flow + for information that is covered by the SFP that has + been specified. If such a capability is not desired, + then the PP/ST author should specify + ``none''. + + . + + + The TSF shall explicitly deny an information flow based on + the following rules: + + + rules, based on security attributes, that explicitly + deny information flows + + + + the PP/ST author should specify the rules, based on security + attributes, that explicitly deny information flows. These rules + are in addition to those specified in the preceding + elements. They are included in as they + are intended to contain exceptions to the rules in the preceding + elements. An example of rules to explicitly deny information + flows is based on a privilege vector associated with a subject + that always denies the subject the ability to cause an + information flow for information that is covered by the SFP that + has been specified. If such a capability is not desired, then + the PP/ST author should specify ``none''. + + . + + + + + + + + + + + + This component requires that the named information flow control + SFP uses hierarchical security attributes that + form a lattice. + + It is important to note that the hierarchical relationship + requirements identified in need + only apply to the information flow control security + attributes for the information flow control SFPs that have + been identified in . This + component is not meant to apply to other SFPs such as + access control SFPs. + phrases the requirements for the set of + security attributes to form a lattice. A number of information + flow policies defined in the literature and implemented in IT + products are based on a set of security attributes that form a + lattice. is specifically included to + address this type of information flow policies. + + If it is the case that multiple information flow control + SFPs are to be specified, and that each of these SFPs will + have their own security attributes that are not related to + one another, then the PP/ST author should iterate this + component once for each of those SFPs. Otherwise a + conflict might arise with the sub-items of since the required relationships will + not exist. + + + expands on the requirements + of by requiring that all + information flow control SFPs in the set of SFRs use + hierarchical security attributes that form a lattice (as defined + in mathematics). is derived from the + mathematical properties of a lattice. A lattice consists of a + set of elements with an ordering relationship with the property + defined in the first bullet, a least upper bound which is the + unique element in the set that is greater or equal (in the + ordering relationship) than any other element of the lattice, + and a greatest lower bound, which is the unique element in the set + that is smaller or equal than any other element of the lattice. + + + + + + + The TSF shall enforce the + + + information flow control SFP + + + + the PP/ST author should specify the information flow + control SFPs enforced by the TSF. The name of the + information flow control SFP, and the scope of control + for that policy are defined in components from . + + + based on the following types of subject and + information security attributes: + + list of subjects and information controlled under the + indicated SFP, and for each, the security attributes + + the PP/ST author should specify, for each type of + controlled subject and information, the security + attributes that are relevant to the specification of the + SFP rules. For example, such security attributes may be + things such the subject identifier, subject sensitivity + label, subject clearance label, information sensitivity + label, etc. The types of security attributes should be + sufficient to support the environmental needs.. + + + The TSF shall permit an information flow between a + controlled subject and controlled information via a + controlled operation if the following rules, based on the + ordering relationships between security attributes hold: + + + for each operation, the security attribute-based + relationship that must hold between subject and + information security attributes + + + + the PP/ST author should specify for each operation, + the security attribute-based relationship that must + hold between subject and information security + attributes that the TSF will enforce. These + relationships should be based upon the ordering + relationships between the security attributes. + + . + + + The TSF shall enforce the + + + additional information flow control SFP rules + + + the PP/ST author should specify any additional information + flow control SFP rules that the TSF is to enforce. This + includes all rules of the SFP that are either not based on the + security attributes of the information and the subject or + rules that automatically modify the security attributes of + information or subjects as a result of an access operation. + An example for the first case is a rule of the SFP controlling + a threshold value for specific types of information. This + would for example be the case when the information flow SFP + contains rules on access to statistical data where a subject + is only allowed to access this type of information up to a + specific number of accesses. An example for the second case + would be a rule stating under which conditions and how the + security attributes of a subject or object change as the + result of an access operation. Some information flow policies + for example may limit the number of access operations to + information with specific security attributes. If there are + no additional rules then the PP/ST author should specify + ``none''. + . + + + + The TSF shall explicitly authorise an information flow based + on the following rules: + + + rules, based on security attributes, that explicitly + authorise information flows + + + + the PP/ST author should specify the rules, based on + security attributes, that explicitly authorise + information flows. These rules are in addition to + those specified in the preceding elements. They are + included in as they are + intended to contain exceptions to the rules in the + preceding elements. An example of rules to explicitly + authorise information flows is based on a privilege + vector associated with a subject that always grants + the subject the ability to cause an information flow + for information that is covered by the SFP that has + been specified. If such a capability is not desired, + then the PP/ST author should specify + ``none''. + + . + + + The TSF shall explicitly deny an information flow based on + the following rules: + + + rules, based on security attributes, that explicitly + deny information flows + + + + the PP/ST author should specify the rules, based on security + attributes, that explicitly deny information flows. These rules + are in addition to those specified in the preceding + elements. They are included in as they are intended to contain exceptions to the + rules in the preceding elements. An example of rules to + explicitly deny information flows is based on a privilege vector + associated with a subject that always denies the subject the + ability to cause an information flow for information that is + covered by the SFP that has been specified. If such a capability + is not desired, then the PP/ST author should specify + ``none''. + + . + + + The TSF shall enforce the following relationships for any + two valid information flow control security attributes: + + + There exists an ordering function that, given two valid + security attributes, determines if the security + attributes are equal, if one security attribute is + greater than the other, or if the security attributes + are incomparable; and + + + There exists a ``least upper bound'' + in the set of security attributes, such that, given any + two valid security attributes, there is a valid security + attribute that is greater than or equal to the two valid + security attributes; and + + + There exists a ``greatest lower + bound'' in the set of security attributes, + such that, given any two valid security attributes, + there is a valid security attribute that is not greater + than the two valid security attributes. + + + + + + + + + + + + This component should be used when at least one of the + SFPs that requires control of illicit information flows + does not require elimination of flows. + + For the specified illicit information flows, certain + maximum capacities should be provided. In addition a PP/ST + author has the ability to specify whether the illicit + information flows must be audited. + + + + , requires the SFP to cover illicit + information flows, but not necessarily eliminate them. + + + Decisions to permit requested information flows. + + + All decisions on requests for information flow. + + + The use of identified illicit information flow channels. + + + The specific security attributes used in making an + information flow enforcement decision. + + + Some specific subsets of the information that has flowed + based upon policy goals (e.g. auditing of downgraded + material). + + + The use of identified illicit information flow channels with + estimated maximum capacity exceeding a specified value. + + + The TSF shall enforce the + + + information flow control SFP + + + + the PP/ST author should specify the information flow + control SFPs enforced by the TSF. The name of the + information flow control SFP, and the scope of control + for that policy are defined in components from . + + + to limit the capacity of + + + types of illicit information flows + + + + the PP/ST author should specify the types of illicit + information flows that are subject to a maximum + capacity limitation. + + + to a + + + maximum capacity + + + + the PP/ST author should specify the maximum capacity + permitted for any identified illicit information + flows. + + . + + + + + + + + + + + This component should be used when all the SFPs that + requires control of illicit information flows require + elimination of some (but not necessarily all) illicit + information flows. + + + + , requires the SFP to cover the + elimination of some (but not necessarily all) illicit + information flows. + + + + + + The TSF shall enforce the + + + information flow control SFP + + + + the PP/ST author should specify the information flow + control SFPs enforced by the TSF. The name of the + information flow control SFP, and the scope of control + for that policy are defined in components from + . + + + to limit the capacity of + + + types of illicit information flows + + + + the PP/ST author should specify the types of illicit + information flows which are subject to a maximum + capacity limitation. + + + to a + + + maximum capacity + + + + the PP/ST author should specify the maximum capacity + permitted for any identified illicit information + flows. + + . + + + The TSF shall prevent + + + types of illicit information flows + + + + the PP/ST author should specify the types of illicit + information flows to be eliminated. This list may not + be empty as this component requires that some illicit + information flows are to be eliminated. + + . + + + + + + + + + + + This component should be used when the SFPs that require + control of illicit information flows require elimination + of all illicit information flows. However, the PP/ST + author should carefully consider the potential impact that + eliminating all illicit information flows might have on + the normal functional operation of the TOE. Many practical + applications have shown that there is an indirect + relationship between illicit information flows and normal + functionality within a TOE and eliminating all illicit + information flows may result in less than desired + functionality. + + + + , requires SFP to cover the + elimination of all illicit information flows. + + + + + + The TSF shall ensure that no illicit information flows exist + to circumvent + + + name of information flow control SFP + + + + the PP/ST author should specify the information flow + control SFP for which illicit information flows are to + be eliminated. The name of the information flow + control SFP, and the scope of control for that policy + are defined in components from . + + . + + + + + + + + + + This component should be used when it is desired that the + TSF provide the ability to monitor the use of illicit + information flows that exceed a specified capacity. If it + is desired that such flows be audited, then this component + could serve as the source of audit events to be used by + components from the family. + + + + , requires the SFP to monitor + illicit information flows for specified and maximum + capacities. + + + The enabling or disabling of the monitoring function. + + + Modification of the maximum capacity at which the monitoring + occurs. + + + + + + The TSF shall enforce the + + + information flow control SFP + + + + the PP/ST author should specify the information flow + control SFPs enforced by the TSF. The name of the + information flow control SFP, and the scope of control + for that policy are defined in components from + . + + + to monitor + + + types of illicit information flows + + + + the PP/ST author should specify the types of illicit + information flows that will be monitored for exceeding + a maximum capacity. + + + when it exceeds the + + + maximum capacity + + + + the PP/ST author should specify the maximum capacity + above which illicit information flows will be + monitored by the TSF. + + . + + + + + + + + This family defines the mechanisms for TSF-mediated importing of user + data into the TOE such that it has appropriate security + attributes and is appropriately protected. It is concerned + with limitations on importation, determination of desired + security attributes, and interpretation of security + attributes associated with the user data. + + + + This family defines mechanisms for TSF-mediated importing of user data from + outside the TOE into the TOE such that the user data + security attributes can be preserved. Consistency of these + security attributes are addressed by . + + is concerned with limitations on + import, user specification of security attributes, and + association of security attributes with the user data. + + This family, and the corresponding export family , address how the TOE deals with user data + outside its control. This family is concerned with assigning + and abstraction of the user data security attributes. + + A variety of activities might be involved here: + + + importing user data from an unformatted medium + (e.g. floppy disk, tape, scanner, video or audit + signal), without including any security attributes, and + physically marking the medium to indicate its contents; + + + importing user data, including security attributes, from + a medium and verifying that the object security + attributes are appropriate; + + + importing user data, including security attributes, from + a medium using a cryptographic sealing technique to + protect the association of user data and security + attributes. + + + + This family is not concerned with the determination of + whether the user data may be imported. It is concerned with + the values of the security attributes to associate with the + imported user data. + + There are two possibilities for the import of user data: + either the user data is unambiguously associated with + reliable object security attributes (values and meaning of + the security attributes is not modified), or no reliable + security attributes (or no security attributes at all) are + available from the import source. This family addresses both + cases. + + If there are reliable security attributes available, they + may have been associated with the user data by physical + means (the security attributes are on the same media), or by + logical means (the security attributes are distributed + differently, but include unique object identification, + e.g. cryptographic checksum). + + This family is concerned with TSF-mediated importing of user data and + maintaining the association of security attributes as + required by the SFP. Other families are concerned with other + import aspects such as consistency, trusted channels, and + integrity that are beyond the scope of this + family. Furthermore, is only concerned + with the interface to the import medium. is responsible for the other end point of the + medium (the source). + + Some of the well known import requirements are: + + + importing of user data without any security attributes; + + + importing of user data including security attributes + where the two are associated with one another and the + security attributes unambiguously represent the + information being imported. + + + + These import requirements may be handled by the TSF with or + without human intervention, depending on the IT limitations + and the organisational security policy. For example, if user + data is received on a ``confidential'' + channel, the security attributes of the objects will be set + to ``confidential''. + + If there are multiple SFPs (access control and/or + information flow control) then it may be appropriate to + iterate these components once for each named SFP. + + + + + + + + + + + + + This component is used to specify the import of user data + that does not have reliable (or any) security attributes + associated with it. This function requires that the + security attributes for the imported user data be + initialised within the TSF. It could also be the case that + the PP/ST author specifies the rules for import. It may be + appropriate, in some environments, to require that these + attributes be supplied via a trusted path or a trusted + channel mechanism. + + + + , requires that the security + attributes correctly represent the user data and are + supplied separately from the object. + + + The modification of the additional control rules used for + import. + + + Successful import of user data, including any security + attributes. + + + All attempts to import user data, including any security + attributes. + + + The specification of security attributes for imported user + data supplied by an authorised user. + + + The TSF shall enforce the + + access control SFP(s) and/or information flow control SFP(s) + + the PP/ST author should specify the access control SFP(s) + and/or information flow control SFP(s) that will be + enforced when importing user data from outside of the + TOE. The user data that this function imports is + scoped by the assignment of these SFPs. + when importing user data, controlled under the SFP, from + outside of the TOE. + + + The TSF shall ignore any security attributes associated with + the user data when imported from outside the TOE. + + + The TSF shall enforce the following rules when importing + user data controlled under the SFP from outside the TOE: + + + additional importation control rules + + + + the PP/ST author should specify any additional + importation control rules or + ``none'' if there are no + additional importation control rules. These rules will + be enforced by the TSF in addition to the access + control SFPs and/or information flow control SFPs + selected in . + + . + + + + + + + + + + + + + + + + + + This component is used to specify the import of user data + that has reliable security attributes associated with + it. This function relies upon the security attributes that + are accurately and unambiguously associated with the + objects on the import medium. Once imported, those objects + will have those same attributes. This requires to ensure the consistency of the data. It + could also be the case that the PP/ST author specifies the + rules for import. + + + + , requires that security attributes + correctly represent the user data and are accurately and + unambiguously associated with the user data imported from + outside the TOE. + + + + + + + The TSF shall enforce the + + + access control SFP(s) and/or information flow control + SFP(s) + + + + the PP/ST author should specify the access control + SFP(s) and/or information flow control SFP(s) that + will be enforced when importing user data from outside + of the TOE. The user data that this function imports + is scoped by the assignment of these SFPs. + + + when importing user data, controlled under the SFP, from + outside of the TOE. + + + The TSF shall use the security attributes associated with + the imported user data. + + + The TSF shall ensure that the protocol used provides for the + unambiguous association between the security attributes and + the user data received. + + + The TSF shall ensure that interpretation of the security + attributes of the imported user data is as intended by the + source of the user data. + + + The TSF shall enforce the following rules when importing + user data controlled under the SFP from outside the TOE: + + + additional importation control rules + + + + the PP/ST author should specify any additional + importation control rules or + ``none'' if there are no + additional importation control rules. These rules will + be enforced by the TSF in addition to the access + control SFPs and/or information flow control SFPs + selected in . + + . + + + + + + + + This family provides requirements that address protection of + user data when it is transferred between separated parts of a TOE + across an internal channel. This may be contrasted with the + and families, + which provide protection for user data when it is + transferred between distinct TSFs across an external + channel, and and , + which address TSF-mediated transfer of data to or from outside the + TOE. + + + + This family provides requirements that address protection of + user data when it is transferred between parts of a TOE + across an internal channel. This may be contrasted with the + and family, which + provide protection for user data when it is transferred + between distinct TSFs across an external channel, and and , which address + TSF-mediated transfer of data to or from outside the TOE. + + The requirements in this family allow a PP/ST author to + specify the desired security for user data while in transit + within the TOE. This security could be protection against + disclosure, modification, or loss of availability. + + The determination of the degree of physical separation above + which this family should apply depends on the intended + environment of use. In a hostile environment, there may be + risks arising from transfers between parts of the TOE + separated by only a system bus. In more benign environments, + the transfers may be across more traditional network media. + + If there are multiple SFPs (access control and/or + information flow control) then it may be appropriate to + iterate these components once for each named SFP. + + + + + + + + + + + + , requires that user data be + protected when transmitted between parts of the TOE. + + + If the TSF provides multiple methods to protect user data + during transmission between physically separated parts of + the TOE, the TSF could provide a pre-defined role with the + ability to select the method that will be used. + + + Successful transfers of user data, including identification + of the protection method used. + + + All attempts to transfer user data, including the protection + method used and any errors that occurred. + + + The TSF shall enforce the + + + access control SFP(s) and/or information flow control + SFP(s) + + + + the PP/ST author should specify the access control + SFP(s) and/or information flow control SFP(s) covering + the information being transferred. + + + to prevent the + + + disclosure + + + modification + + + loss of use + + + + the PP/ST author should specify the types of + transmission errors that the TSF should prevent + occurring for user data while in transport. The options + are disclosure, modification, loss of use. + + + of user data when it is transmitted between + physically-separated parts of the TOE. + + + + + + + + + + + + + + This component could, for example, be used to provide + different forms of protection to information with + different clearance levels. + + One of the ways to achieve separation of data when it is + transmitted is through the use of separate logical or + physical channels. + + + + , requires separation of data based + on the value of SFP-relevant attributes in addition to the + first component. + + + + + + The TSF shall enforce the + + + access control SFP(s) and/or information flow control + SFP(s) + + + + the PP/ST author should specify the access control + SFP(s) and/or information flow control SFP(s) covering + the information being transferred. + + + to prevent the + + + disclosure + + + modification + + + loss of use + + + + the PP/ST author should specify the types of + transmission errors that the TSF should prevent + occurring for user data while in transport. The options + are disclosure, modification, loss of use. + + + of user data when it is transmitted between + physically-separated parts of the TOE. + + + The TSF shall separate data controlled by the SFP(s) when + transmitted between physically-separated parts of the TOE, + based on the values of the following: + + + security attributes that require separation + + + + the PP/ST author should specify the security + attributes, the values of which the TSF will use to + determine when to separate data that is being + transmitted between physically-separated parts of the + TOE. An example is that user data associated with the + identity of one owner is transmitted separately from + the user data associated with the identify of a + different owner. In this case, the value of the + identity of the owner of the data is what is used to + determine when to separate the data for transmission. + + . + + + + + + + + + + + + + + This component is used in combination with either or . It ensures + that the TSF checks received user data (and their + attributes) for integrity. or will provide the data in a manner such + that it is protected from modification (so that can detect any modifications). + + The PP/ST author has to specify the types of errors that + must be detected. The PP/ST author should consider: + modification of data, substitution of data, unrecoverable + ordering change of data, replay of data, incomplete data, + in addition to other integrity errors. + + The PP/ST author must specify the actions that the TSF + should take on detection of a failure. For example: ignore + the user data, request the data again, inform the + authorised administrator, reroute traffic for other lines. + + + + , requires that the TSF monitor user + data transmitted between parts of the TOE for identified + integrity errors. + + + The specification of the actions to be taken upon detection + of an integrity error could be configurable. + + + Successful transfers of user data, including identification + of the integrity protection method used. + + + All attempts to transfer user data, including the integrity + protection method used and any errors that occurred. + + + Unauthorised attempts to change the integrity protection + method. + + + The action taken upon detection of an integrity error. + + + The TSF shall enforce the + + + access control SFP(s) and/or information flow control + SFP(s) + + + + the PP/ST author should specify the access control + SFP(s) and/or information flow control SFP(s) covering + the information being transferred and monitored for + integrity errors. + + + to monitor user data transmitted between + physically-separated parts of the TOE for the following + errors: + + + integrity errors + + + + the PP/ST author should specify the type of possible + integrity errors to be monitored during transmission + of the user data. + + . + + + Upon detection of a data integrity error, the TSF shall + + + specify the action to be taken upon integrity error + + + + the PP/ST author should specify the action to be taken + by the TSF when an integrity error is encountered. An + example might be that the TSF should request the + resubmission of the user data. The SFP(s) specified in + will be enforced as the + actions are taken by the TSF. + + . + + + + + + + + + + + + + + + This component is used in combination with . It ensures that the TSF checks received + user data, that has been transmitted by separate channels + (based on values of specified security attributes), for + integrity. It allows the PP/ST author to specify actions + to be taken upon detection of an integrity error. + + For example, this component could be used to provide + different integrity error detection and action for + information at different integrity levels. + + The PP/ST author has to specify the types of errors that + must be detected. The PP/ST author should consider: + modification of data, substitution of data, unrecoverable + ordering change of data, replay of data, incomplete data, + in addition to other integrity errors. + + The PP/ST author should specify the attributes (and + associated transmission channels) that necessitate + integrity error monitoring + + The PP/ST author must specify the actions that the TSF + should take on detection of a failure. For example: ignore + the user data, request the data again, inform the + authorised administrator, reroute traffic for other lines. + + + + expands on the third component by + allowing the form of integrity monitoring to differ by + SFP-relevant attribute. + + + + + + + + The TSF shall enforce the + + + access control SFP(s) and/or information flow + control SFP(s) + + + + the PP/ST author should specify the access control + SFP(s) and/or information flow control SFP(s) covering + the information being transferred and monitored for + integrity errors. + + + to monitor user data transmitted between + physically-separated parts of the TOE for the following + errors: + + + integrity errors + + + + the PP/ST author should specify the type of possible + integrity errors to be monitored during transmission + of the user data. + + , based on the following attributes: + + + security attributes that require separate transmission + channels + + + + the PP/ST author should specify a list of security + attributes that require separate transmission + channels. This list is used to determine which user + data to monitor for integrity errors., based on its + security attributes and its transmission channel. This + element is directly related to . + + . + + + Upon detection of a data integrity error, the TSF shall + + + specify the action to be taken upon integrity + error + + + + the PP/ST author should specify the action to be taken + by the TSF when an integrity error is encountered. An + example might be that the TSF should request the + resubmission of the user data. The SFP(s) specified in + will be enforced as the + actions are taken by the TSF. + + . + + + + + + + + This family addresses the need to ensure that any data contained + in a resource is not available when the resource is de-allocated + from one object and reallocated to a different object. This + family requires protection for any data contained in a resource + that has been logically deleted or released, but may still be + present within the TSF-controlled resource which in turn may be + re-allocated to another object. + + + + Residual information protection ensures that TSF-controlled + resources when de-allocated from an object and before they are + reallocated to another object are treated by the TSF in a way + that it is not possible to reconstruct all or part of the data + contained in the resource before it was de-allocated. + + A TOE usually has a number of functions that potentially + de-allocate resources from an object and potentially re-allocate + those resources to objects. Some, but not all of those resources + may have been used to store critical data from the previous use + of the resource and for those resources FDP_RIP requires that + they are prepared for reuse. Object reuse applies to explicit + requests of a subject or user to release resources as well as + implicit actions of the TSF that result in the de-allocation and + subsequent re-allocation of resources to different + objects. Examples of explicit requests are the deletion or + truncation of a file or the release of an area of main + memory. Examples of implicit actions of the TSF are the + de-allocation and re-allocation of cache regions. + The requirement for object reuse is related to the content of + the resource belonging to an object, not all information about + the resource or object that may be stored elsewhere in the + TSF. As an example to satisfy the FDP_RIP requirement for files + as objects requires that all sectors that make up the file need + to be prepared for re-use. + + It also applies to resources that are serially reused by + different subjects within the system. For example, most + operating systems typically rely upon hardware registers + (resources) to support processes within the system. As + processes are swapped from a ``run'' state to a ``sleep'' + state (and vice versa), these registers are serially reused + by different subjects. While this ``swapping'' action may + not be considered an allocation or deallocation of a + resource, could apply to + such events and resources. + + typically controls access + to information that is not part of any currently defined or + accessible object; however, in certain cases this may not be + true. For example, object ``A'' is a file and object ``B'' + is the disk upon which that file resides. If object ``A'' is + deleted, the information from object ``A'' is under the + control of even though it + is still part of object ``B''. + + It is important to note that applies only to on-line objects and not + off-line objects such as those backed-up on tapes. For + example, if a file is deleted in the TOE, can be instantiated to require that no + residual information exists upon deallocation; however, the + TSF cannot extend this enforcement to that same file that + exists on the off-line back-up. Therefore that same file is + still available. If this is a concern, then the PP/ST author + should make sure that the proper environmental objectives + are in place to support operational user guidance to address + off-line objects. + + and can conflict when is instantiated to require that residual + information be cleared at the time the application releases + the object to the TSF (i.e. upon deallocation). Therefore, + the selection of + ``deallocation'' should not be used with since there would be no information to roll + back. The other selection, ``unavailability upon + allocation'', may be used with , but there is the risk that the resource + which held the information has been allocated to a new + object before the roll back took place. If that were to + occur, then the roll back would not be possible. + + There are no audit requirements in because this is not a user-invokable + function. Auditing of allocated or deallocated resources + would be auditable as part of the access control SFP or the + information flow control SFP operations. + + This family should apply to the objects specified in the + access control SFP(s) or the information flow control SFP(s) + as specified by the PP/ST author. + + + + + + This component requires that, for a subset of the objects + in the TOE, the TSF will ensure that there is no available + residual information contained in a resource allocated to + those objects or deallocated from those objects. + + + + , requires that the TSF + ensure that any residual information content of any + resources is unavailable to a defined subset of the + objects controlled by the TSF upon the resource's + allocation or deallocation. + + + The choice of when to perform residual information + protection (i.e. upon allocation or deallocation) could be + made configurable within the TOE. + + + The TSF shall ensure that any previous information content + of a resource is made unavailable upon the + + + allocation of the resource to + + + deallocation of the resource from + + + + the PP/ST author should specify the event, allocation + of the resource to or deallocation of the resource + from, that invokes the residual information protection + function. + + + the following objects: + + + list of objects + + + + the PP/ST author should specify the list of objects + subject to residual information protection. + + . + + + + + + + + This component requires that for all objects in the TOE, + the TSF will ensure that there is no available residual + information contained in a resource allocated to those + objects or deallocated from those objects. + + + + , requires that the TSF ensure that + any residual information content of any resources is + unavailable to all objects upon the resource's + allocation or deallocation. + + + + The TSF shall ensure that any previous information content + of a resource is made unavailable upon the + + + allocation of the resource to + + + deallocation of the resource from + + + + the PP/ST author should specify the event, allocation + of the resource to or deallocation of the resource + from, that invokes the residual information protection + function. + + + all objects. + + + + + + + + The rollback operation involves undoing the last operation + or a series of operations, bounded by some limit, such as a + period of time, and return to a previous known + state. Rollback provides the ability to undo the effects of + an operation or series of operations to preserve the + integrity of the user data. + + + + This family addresses the need to return to a well defined + valid state, such as the need of a user to undo + modifications to a file or to undo transactions in case of + an incomplete series of transaction as in the case of + databases. + + This family is intended to assist a user in returning to a + well defined valid state after the user undoes the last set + of actions, or, in distributed databases, the return of all + of the distributed copies of the databases to the state + before an operation failed. + + and conflict when + enforces that the contents will be made + unavailable at the time that a resource is deallocated from + an object. Therefore, this use of + cannot be combined with as there would + be no information to roll back. can be + used only with when it enforces that + the contents will be unavailable at the time that a resource + is allocated to an object. This is because the mechanism will have an opportunity to access + the previous information that may still be present in the + TOE in order to successfully roll back the operation. + + The rollback requirement is bounded by certain limits. For + example a text editor typically only allows you roll back up + to a certain number of commands. Another example would be + backups. If backup tapes are rotated, after a tape is + reused, the information can no longer be retrieved. This + also poses a bound on the rollback requirement. + + + + + + + + + + + + This component allows a user or subject to undo a set of + operations on a predefined set of objects. The undo is + only possible within certain limits, for example up to a + number of characters or up to a time limit. + + + + addresses a need to roll back or + undo a limited number of operations within the defined + bounds. + + + The boundary limit to which rollback may be performed could + be a configurable item within the TOE. + + + Permission to perform a rollback operation could be + restricted to a well defined role. + + + All successful rollback operations. + + + All attempts to perform rollback operations. + + + All attempts to perform rollback operations, including + identification of the types of operations rolled back. + + + The TSF shall enforce + + + access control SFP(s) and/or information flow control + SFP(s) + + + + the PP/ST author should specify the access control + SFP(s) and/or information flow control SFP(s) that + will be enforced when performing rollback + operations. This is necessary to make sure that roll + back is not used to circumvent the specified SFPs. + + + to permit the rollback of the + + + list of operations + + + + the PP/ST author should specify the list of operations + that can be rolled back. + + + on the + + information and/or list of objects + + the PP/ST author should specify the information and/or + list of objects that are subjected to the rollback policy.. + + + The TSF shall permit operations to be rolled back within the + + + boundary limit to which rollback may be performed + + + + the PP/ST author should specify the boundary limit to + which rollback operations may be performed. The + boundary may be specified as a predefined period of + time, for example, operations may be undone which were + performed within the past two minutes. Other possible + boundaries may be defined as the maximum number of + operations allowable or the size of a buffer. + + . + + + + + + + + + + + + + + This component enforces that the TSF provide the + capability to rollback all operations; however, the user + can choose to rollback only a part of them. + + + + addresses the need to roll back or + undo all operations within the defined bounds. + + + + + + + The TSF shall enforce + + + access control SFP(s) and/or information flow control + SFP(s) + + + + the PP/ST author should specify the access control + SFP(s) and/or information flow control SFP(s) that + will be enforced when performing rollback + operations. This is necessary to make sure that roll + back is not used to circumvent the specified SFPs. + + + to permit the rollback of all the operations on the + + + list of objects + + + + the PP/ST author should specify the list of objects + that are subjected to the rollback policy. + + . + + + The TSF shall permit operations to be rolled back within the + + + boundary limit to which rollback may be performed + + + + the PP/ST author should specify the boundary limit to + which rollback operations may be performed. The + boundary may be specified as a predefined period of + time, for example, operations may be undone which were + performed within the past two minutes. Other possible + boundaries may be defined as the maximum number of + operations allowable or the size of a buffer. + + . + + + + + + + + This family provides requirements that address protection of + user data while it is stored within containers controlled by the TSF. Integrity + errors may affect user data stored in memory, or in a + storage device. This family differs from which protects the user data from integrity + errors while being transferred within the TOE. + + + + This family provides requirements that address protection of + user data while it is stored within containers controlled by the TSF. + + Hardware glitches or errors may affect data stored in + memory. This family provides requirements to detect these + unintentional errors. The integrity of user data while + stored on storage devices controlled by the TSF are also addressed + by this family. + + To prevent a subject from modifying the data, the or families are required + (rather than this family). + + This family differs from that protects + the user data from integrity errors while being transferred + within the TOE. + + + + + + This component monitors data stored on media for integrity + errors. The PP/ST author can specify different kinds of + user data attributes that will be used as the basis for + monitoring. + + + + , requires that the TSF monitor user + data stored within containers controlled by the TSF for identified integrity + errors. + + + Successful attempts to check the integrity of user data, + including an indication of the results of the check. + + + All attempts to check the integrity of user data, including + an indication of the results of the check, if performed. + + + The type of integrity error that occurred. + + + The TSF shall monitor user data stored in containers controlled by the TSF for + + + integrity errors + + + + the PP/ST author should specify the integrity errors + that the TSF will detect. + + + on all objects, based on the following attributes: + + + user data attributes + + + + the PP/ST author should specify the user data + attributes that will be used as the basis for the + monitoring. + + . + + + + + + + + This component monitors data stored on media for integrity + errors. The PP/ST author can specify which action should + be taken in case an integrity error is detected. + + + + adds the additional capability to + the first component by allowing for actions to be taken as + a result of an error detection. + + + The actions to be taken upon the detection of an integrity + error could be configurable. + + + Successful attempts to check the integrity of user data, + including an indication of the results of the check. + + + All attempts to check the integrity of user data, including + an indication of the results of the check, if performed. + + + The type of integrity error that occurred. + + + The action taken upon detection of an integrity error. + + + The TSF shall monitor user data stored in containers controlled by the TSF for + + + integrity errors + + + + the PP/ST author should specify the integrity errors + that the TSF will detect. + + + on all objects, based on the following attributes: + + + user data attributes + + + + the PP/ST author should specify the user data + attributes that will be used as the basis for the + monitoring. + + . + + + Upon detection of a data integrity error, the TSF shall + + + action to be taken + + + + the PP/ST author should specify the actions to be + taken in case an integrity error is detected. + + . + + + + + + + + This family defines the requirements for ensuring the + confidentiality of user data when it is transferred using an + external channel between the TOE and another trusted IT product. + + + + This family defines the requirements for ensuring the + confidentiality of user data when it is transferred using an + external channel between the TOE and another trusted IT + product. Confidentiality is enforced by preventing + unauthorised disclosure of user data in transit between the + two end points. The end points may be a TSF or a user. + + This family provides a requirement for the protection of user + data during transit. In contrast, handles TSF data. + + + + + + + + + + + + + + + + Depending on the access control or information flow policies the TSF is + required to send or receive user data in a manner such that the + confidentiality of the user data is protected. + + + + In , the goal is to provide + protection from disclosure of user data while in transit. + + + The identity of any user or subject using the data exchange + mechanisms. + + + The identity of any unauthorised user or subject attempting + to use the data exchange mechanisms. + + + A reference to the names or other indexing information + useful in identifying the user data that was transmitted or + received. This could include security attributes associated + with the information. + + + The TSF shall enforce the + + access control SFP(s) and/or information flow control SFP(s) + the PP/ST author should specify the access control SFP(s) + and/or information flow control SFP(s) that will be enforced when exchanging + user data. The specified policies will be enforced to make decisions about + who can exchange data and which data can be exchanged. + to + transmitreceivethe PP/ST author should specify whether this element + applies to a mechanism that transmits or receives user data. + user data in a manner protected from unauthorised disclosure. + + + + + + + + This family defines the requirements for providing integrity + for user data in transit between the TOE and another trusted + IT product and recovering from detectable errors. At a + minimum, this family monitors the integrity of user data for + modifications. Furthermore, this family supports different + ways of correcting detected integrity errors. + + + + This family defines the requirements for providing integrity + for user data in transit between the TSF and another trusted + IT product and recovering from detectable errors. At a + minimum, this family monitors the integrity of user data for + modifications. Furthermore, this family supports different + ways of correcting detected integrity errors. + + This family defines the requirements for providing integrity + for user data in transit; while handles + TSF data. + + and are duals of + each other, as addresses user data + confidentiality. Therefore, the same mechanism that + implements could possibly be used to + implement other families such as and + . + + + + + + + + + + + + + + + + Depending on the access control or information flow policies the TSF is + required to send or receive user data in a manner such that modification + of the user data is detected. There is no requirement for a TSF mechanism + to attempt to recover from the modification. + + + + addresses detection of + modifications, deletions, insertions, and replay errors of + the user data transmitted. + + + The identity of any user or subject using the data exchange + mechanisms. + + + The identity of any user or subject attempting to use the + user data exchange mechanisms, but who is unauthorised to do + so. + + + A reference to the names or other indexing information + useful in identifying the user data that was transmitted or + received. This could include security attributes associated + with the user data. + + + Any identified attempts to block transmission of user data. + + + The types and/or effects of any detected modifications of + transmitted user data. + + + The TSF shall enforce the + access control SFP(s) and/or information flow control SFP(s) + the PP/ST author should specify the access control SFP(s) + and/or information flow control SFP(s) that will be enforced on the transmitted + data or on the received data. The specified policies will be enforced to make + decisions about who can transmit or who can receive data, and which data can be + transmitted or received. + to + transmitreceivethe PP/ST author should specify whether this element applies + to a TSF that is transmitting or receiving objects. + user data in a manner protected from + modificationdeletioninsertionreplaythe PP/ST author should specify whether the data should be + protected from modification, deletion, insertion or replay. + errors. + + + The TSF shall be able to determine on receipt of user data, + whether + + + modification + + + deletion + + + insertion + + + replay + + + + the PP/ST author should specify whether the errors of + the type: modification, deletion, insertion or replay + are detected. + + + has occurred. + + + + + + + + + + + + + + + + + This component provides the ability to recover from a set + of identified transmission errors, if required, with the + help of the other trusted IT product. As the other trusted + IT product is outside the TOE, the TSF cannot control its + behaviour. However, it can provide functions that have the + ability to cooperate with the other trusted IT product for + the purposes of recovery. For example, the TSF could + include functions that depend upon the source trusted IT + product to re-send the data in the event that an error is + detected. This component deals with the ability of the TSF + to handle such an error recovery. + + + + addresses recovery of the original + user data by the receiving TSF with help from the source + trusted IT product. + + + The identity of any user or subject using the data exchange + mechanisms. + + + Successful recovery from errors including they type of error + that was detected. + + + The identity of any user or subject attempting to use the + user data exchange mechanisms, but who is unauthorised to do + so. + + + A reference to the names or other indexing information + useful in identifying the user data that was transmitted or + received. This could include security attributes associated + with the user data. + + + Any identified attempts to block transmission of user data. + + + The types and/or effects of any detected modifications of + transmitted user data. + + + The TSF shall enforce the + + + access control SFP(s) and/or information flow control + SFP(s) + + + + the PP/ST author should specify the access control + SFP(s) and/or information flow control SFP(s) that + will be enforced when recovering user data. The + specified policies will be enforced to make decisions + about which data can be recovered and how it can be + recovered. + + + to be able to recover from + + + list of recoverable errors + + + + the PP/ST author should specify the list of integrity + errors from which the TSF, with the help of the source + trusted IT product, is be able to recover the original + user data. + + + with the help of the source trusted IT product. + + + + + + + + + + + + + + + + + + + + This component provides the ability to recover from a set + of identified transmission errors. It accomplishes this + task without help from the source trusted IT product. For + example, if certain errors are detected, the transmission + protocol must be robust enough to allow the TSF to recover + from the error based on checksums and other information + available within that protocol. + + + + addresses recovery of the original + user data by the receiving TSF on its own without any help + from the source trusted IT product. + + + + + + The TSF shall enforce the + + + access control SFP(s) and/or information flow control + SFP(s) + + + + the PP/ST author should specify the access control + SFP(s) and/or information flow control SFP(s) that + will be enforced when recovering user data. The + specified policies will be enforced to make decisions + about which data can be recovered and how it can be + recovered. + + + to be able to recover from + + + list of recoverable errors + + + + the PP/ST author should specify the list of integrity + errors from which the receiving TSF, alone, is able to + recover the original user data. + + + without any help from the source trusted IT product. + + + + + + + + Families in this class address the requirements for functions + to establish and verify a claimed user identity. + + Identification and Authentication is required to ensure that + users are associated with the proper security attributes + (e.g. identity, groups, roles, security or integrity levels). + + The unambiguous identification of authorised users and the + correct association of security attributes with users and + subjects is critical to the enforcement of the intended + security policies. The families in this class deal with + determining and verifying the identity of users, determining + their authority to interact with the TOE, and with the correct + association of security attributes for each authorised + user. Other classes of requirements (e.g. User Data + Protection, Security Audit) are dependent upon correct + identification and authentication of users in order to be + effective. + + + + A common security requirement is to unambiguously identify the + person and/or entity performing functions in a TOE. This + involves not only establishing the claimed identity of each + user, but also verifying that each user is indeed who he/she + claims to be. This is achieved by requiring users to provide + the TSF with some information that is known by the TSF to be + associated with the user in question. + + Families in this class address the requirements for functions + to establish and verify a claimed user + identity. Identification and Authentication is required to + ensure that users are associated with the proper security + attributes (e.g. identity, groups, roles, security or + integrity levels). + + The unambiguous identification of authorised users and the + correct association of security attributes with users and + subjects is critical to the enforcement of the security + policies. + + The family addresses determining the + identity of a user. + + The family addresses verifying the + identity of a user. + + The family addresses defining limits on + repeated unsuccessful authentication attempts. + + The family address the definition of user + attributes that are used in the enforcement of the SFRs. + + The family addresses the correct + association of security attributes for each authorised user. + + The family addresses the generation and + verification of secrets that satisfy a defined metric. + + + + + + This family contains requirements for defining values for + some number of unsuccessful authentication attempts and TSF + actions in cases of authentication attempt + failures. Parameters include, but are not limited to, the + number of failed authentication attempts and time + thresholds. + + + + This family addresses requirements for defining values for + authentication attempts and TSF actions in cases of + authentication attempt failure. Parameters include, but are + not limited to, the number of attempts and time thresholds. + + The session establishment process is the interaction with + the user to perform the session establishment independent of + the actual implementation. If the number of unsuccessful + authentication attempts exceeds the indicated threshold, + either the user account or the terminal (or both) will be + locked. If the user account is disabled, the user cannot + log-on to the system. If the terminal is disabled, the + terminal (or the address that the terminal has) cannot be + used for any log-on. Both of these situations continue until + the condition for re-establishment is satisfied. + + + + + + + + + The PP/ST author may define the number of unsuccessful + authentication attempts or may choose to let the TOE + developer or the authorised user to define this + number. The unsuccessful authentication attempts need not + be consecutive, but rather related to an authentication + event. Such an authentication event could be the count + from the last successful session establishment at a given + terminal. + + The PP/ST author could specify a list of actions that the + TSF shall take in the case of authentication failure. An + authorised administrator could also be allowed to manage + the events, if deemed opportune by the PP/ST author. These + actions could be, among other things, terminal + deactivation, user account deactivation, or administrator + alarm. The conditions under which the situation will be + restored to normal must be specified on the action. + + In order to prevent denial of service, TOEs usually ensure + that there is at least one user account that cannot be + disabled. + + Further actions for the TSF can be stated by the PP/ST + author, including rules for re-enabling the user session + establishment process, or sending an alarm to the + administrator. Examples of these actions are: until a + specified time has lapsed, until the authorised + administrator re-enables the terminal/account, a time + related to failed previous attempts (every time the + attempt fails, the disabling time is doubled). + + + + , requires that the TSF be able to + terminate the session establishment process after a + specified number of unsuccessful user authentication + attempts. It also requires that, after termination of the + session establishment process, the TSF be able to disable + the user account or the point of entry (e.g. workstation) + from which the attempts were made until an + administrator-defined condition occurs. + + + management of the threshold for unsuccessful authentication + attempts; + + + management of actions to be taken in the event of an + authentication failure. + + + the reaching of the threshold for the unsuccessful + authentication attempts and the actions (e.g. disabling of a + terminal) taken and the subsequent, if appropriate, + restoration to the normal state (e.g. re-enabling of a + terminal). + + + The TSF shall detect when + + positive integer number + + if the assignment of a positive integer is selected, + the PP/ST author should specify the default number + (positive integer) of unsuccessful authentication + attempts that, when met or surpassed, will trigger + the events. + an administrator configurable positive integer within + + range of acceptable values + + if an administrator configurable positive integer is + selected, the PP/ST author should specify the range of + acceptable values from which the administrator of the + TOE may configure the number of unsuccessful + authentication attempts. The number of authentication + attempts should be less than or equal to the upper + bound and greater or equal to the lower bound values. + the PP/ST author should select either the assignment of a positive integer, + or the phrase ``an administrator configurable positive integer'' specifying + the range of acceptable values. + unsuccessful authentication attempts occur related to + + + list of authentication events + + + + the PP/ST author should specify the authentication + events. Examples of these authentication events are: + the unsuccessful authentication attempts since the + last successful authentication for the indicated user + identity, the unsuccessful authentication attempts + since the last successful authentication for the + current terminal, the number of unsuccessful + authentication attempts in the last 10 minutes. At + least one authentication event must be specified. + + . + + + When the defined number of unsuccessful authentication + attempts has been + metsurpassed + the PP/ST author should select whether the event of + meeting or surpassing the defined number of unsuccessful + authentication attemps shall trigger an action by the + TSF., the TSF shall + + list of actions + + the PP/ST author should specify the actions to be taken in + case the threshold is met or surpassed, as selected. These + actions could be disabling of an account for 5 minutes, + disabling the terminal for an increasing amount of time (2 + to the power of the number of unsuccessful attempts in + seconds), or disabling of the account until unlocked by + the administrator and simultaneously informing the + administrator. The actions should specify the measures and + if applicable the duration of the measure (or the + conditions under which the measure will be ended).. + + + + + + + + All authorised users may have a set of security attributes, + other than the user's identity, that is used to + enforce the SFRs. This family defines the requirements for + associating user security attributes with users as needed to + support the TSF in making security decisions. + + + + All authorised users may have a set of security attributes, + other than the user's identity, that are used to + enforce the SFRs. This family defines the requirements for + associating user security attributes with users as needed to + support the TSF in making security decisions. + + There are dependencies on the individual security policy (SFP) + definitions. These individual definitions should contain the + listing of attributes that are necessary for policy + enforcement. + + + + + + This component specifies the security attributes that + should be maintained at the level of the user. This means + that the security attributes listed are assigned to and + can be changed at the level of the user. In other words, + changing a security attribute in this list associated with + a user should have no impact on the security attributes of + any other user. + + In case security attributes belong to a group of users + (such as Capability List for a group), the user will need + to have a reference (as security attribute) to the + relevant group. + + + + , allows user security attributes + for each user to be maintained individually. + + + if so indicated in the assignment, the authorised + administrator might be able to define additional security + attributes for users. + + + The TSF shall maintain the following list of security + attributes belonging to individual users: + + + list of security attributes + + + + the PP/ST author should specify the security + attributes that are associated to an individual + user. An example of such a list is + {``clearance'', ``group + identifier'', ``rights''}. + + . + + + + + + + + This family defines requirements for mechanisms that enforce + defined quality metrics on provided secrets and generate + secrets to satisfy the defined metric. + + + + This family defines requirements for mechanisms that enforce + defined quality metrics on provided secrets, and generate + secrets to satisfy the defined metric. Examples of such + mechanisms may include automated checking of user supplied + passwords, or automated password generation. + + A secret can be generated outside the TOE (e.g. selected by + the user and introduced in the TOE). In such cases, the + component can be used to + ensure that the external generated secret adheres to certain + standards, for example a minimum size, not present in a + dictionary, and/or not previously used. + + Secrets can also be generated by the TOE. In those cases, + the component can be used + to require the TOE to ensure that the secrets that will + adhere to some specified metrics. + + Secrets contain the authentication data provided by the user + for an authentication mechanism that is based on knowledge + the user possesses. When cryptographic keys are employed, + the class should be used instead of this + family. + + + + + + Secrets can be generated by the user. This component + ensures that those user generated secrets can be verified + to meet a certain quality metric. + + + + , requires the TSF to verify that + secrets meet defined quality metrics. + + + the management of the metric used to verify the secrets. + + + Rejection by the TSF of any tested secret; + + + Rejection or acceptance by the TSF of any tested secret; + + + Identification of any changes to the defined quality + metrics. + + + The TSF shall provide a mechanism to verify that secrets + meet + + + a defined quality metric + + + + the PP/ST author should provide a defined quality + metric. The quality metric specification can be as + simple as a description of the quality checks to be + performed, or as formal as a reference to a government + published standard that defines the quality metrics + that secrets must meet. Examples of quality metrics + could include a description of the alphanumeric + structure of acceptable secrets and/or the space size + that acceptable secrets must meet. + + . + + + + + + + This component allows the TSF to generate secrets for + specific functions such as authentication by means of + passwords. + + When a pseudo-random number generator is used in a secret + generation algorithm, it should accept as input random + data that would provide output that has a high degree of + unpredictability. This random data (seed) can be derived + from a number of available parameters such as a system + clock, system registers, date, time, etc. The parameters + should be selected to ensure that the number of unique + seeds that can be generated from these inputs should be at + least equal to the minimum number of secrets that must be + generated. + + + + , requires the TSF to be able to + generate secrets that meet defined quality metrics. + + + the management of the metric used to generate the secrets. + + + + + + The TSF shall provide a mechanism to generate secrets that + meet + + + a defined quality metric + + + + the PP/ST author should provide a defined quality + metric. The quality metric specification can be as + simple as a description of the quality checks to be + performed or as formal as a reference to a government + published standard that defines the quality metrics + that secrets must meet. Examples of quality metrics + could include a description of the alphanumeric + structure of acceptable secrets and/or the space size + that acceptable secrets must meet. + + . + + + The TSF shall be able to enforce the use of TSF generated + secrets for + + + list of TSF functions + + + + the PP/ST author should provide a list of TSF + functions for which the TSF generated secrets must be + used. An example of such a function could include a + password based authentication mechanism. + + . + + + + + + + + This family defines the types of user authentication + mechanisms supported by the TSF. This family also defines + the required attributes on which the user authentication + mechanisms must be based. + + + + This family defines the types of user authentication + mechanisms supported by the TSF. This family defines the + required attributes on which the user authentication + mechanisms must be based. + + + + + + + + + This component requires that the PP/ST author define the + TSF-mediated actions that can be performed by the TSF on + behalf of the user before the claimed identity of the user + is authenticated. The TSF-mediated actions should have no + security concerns with users incorrectly identifying + themselves prior to being authenticated. For all other + TSF-mediated actions not in the list, the user must be + authenticated before the action can be performed by the + TSF on behalf of the user. + + This component cannot control whether the actions can also + be performed before the identification took place. This + requires the use of either or + with the appropriate assignments. + + + + , allows a user to perform certain + actions prior to the authentication of the + user's identity. + + + management of the authentication data by an administrator; + + + management of the authentication data by the associated + user; + + + managing the list of actions that can be taken before the + user is authenticated. + + + Unsuccessful use of the authentication mechanism; + + + All use of the authentication mechanism; + + + All TSF mediated actions performed before authentication of + the user. + + + The TSF shall allow + + + list of TSF mediated actions + + + + the PP/ST author should specify a list of TSF-mediated + actions that can be performed by the TSF on behalf of + a user before the claimed identity of the user is + authenticated. This list cannot be empty. If no + actions are appropriate, component should be used instead. An example of + such an action might include the request for help on + the login procedure. + + + on behalf of the user to be performed before the user is + authenticated. + + + The TSF shall require each user to be successfully + authenticated before allowing any other TSF-mediated actions + on behalf of that user. + + + + + + + + + + + This component requires that a user is authenticated before any other + TSF-mediated action can take place on behalf of that user. + + + , requires that users are + authenticated before any other action will be allowed by the TSF. + + + management of the authentication data by an administrator; + + + management of the authentication data by the user associated + with this data. + + + Unsuccessful use of the authentication mechanism; + + + All use of the authentication mechanism. + + + The TSF shall require each user to be successfully + authenticated before allowing any other TSF-mediated actions + on behalf of that user. + + + + + + + This component addresses requirements for mechanisms that + provide protection of authentication data. Authentication + data that is copied from another user, or is in some way + constructed should be detected and/or rejected. These + mechanisms provide confidence that users authenticated by + the TSF are actually who they claim to be. + + This component may be useful only with authentication + mechanisms that are based on authentication data that + cannot be shared (e.g. biometrics). It is impossible for a + TSF to detect or prevent the sharing of passwords outside + the control of the TSF. + + + + Unforgeable authentication, + requires the authentication mechanism to be able to detect + and prevent the use of authentication data that has been + forged or copied. + + + Detection of fraudulent authentication data; + + + All immediate measures taken and results of checks on the + fraudulent data. + + + The TSF shall + + + detect + + + prevent + + + + the PP/ST author should specify whether the TSF will + detect, prevent, or detect and prevent forging of + authentication data. + + + use of authentication data that has been forged by any user + of the TSF. + + + The TSF shall + + + detect + + + prevent + + + + the PP/ST author should specify whether the TSF will + detect, prevent, or detect and prevent copying of + authentication data. + + + use of authentication data that has been copied from any + other user of the TSF. + + + + + + + This component addresses requirements for authentication + mechanisms based on single-use authentication + data. Single-use authentication data can be something the + user has or knows, but not something the user is. Examples + of single-use authentication data include single-use + passwords, encrypted time-stamps, and/or random numbers + from a secret lookup table. + + The PP/ST author can specify to which authentication + mechanism(s) this requirement applies. + + + + , requires an authentication + mechanism that operates with single-use authentication + data. + + + Attempts to reuse authentication data. + + + The TSF shall prevent reuse of authentication data related + to + + + identified authentication mechanism(s) + + + + the PP/ST author should specify the list of + authentication mechanisms to which this requirement + applies. This assignment can be ``all + authentication mechanisms''. An example of + this assignment could be ``the + authentication mechanism employed to authenticate + people on the external network''. + + . + + + + + + + The use of this component allows specification of + requirements for more than one authentication mechanism to + be used within a TOE. For each distinct mechanism, + applicable requirements must be chosen from the class to be applied to each + mechanism. It is possible that the same component could be + selected multiple times in order to reflect different + requirements for the different use of the authentication + mechanism. + + The management functions in the class FMT may provide + maintenance capabilities for the set of authentication + mechanisms, as well as the rules that determine whether + the authentication was successful. + + To allow anonymous users to interact with the TOE, a + ``none'' authentication mechanism can be incorporated. The + use of such access should be clearly explained in the + rules of . + + + + , requires that different + authentication mechanisms be provided and used to + authenticate user identities for specific events. + + + the management of authentication mechanisms; + + + the management of the rules for authentication. + + + The final decision on authentication; + + + The result of each activated mechanism together with the + final decision. + + + The TSF shall provide + + + list of multiple authentication mechanisms + + + + the PP/ST author should define the available + authentication mechanisms. An example of such a list + could be: ``none, password mechanism, + biometric (retinal scan), S/key mechanism''. + + + to support user authentication. + + + The TSF shall authenticate any user's claimed + identity according to the + + + rules describing how the multiple authentication + mechanisms provide authentication + + + + the PP/ST author should specify the rules that + describe how the authentication mechanisms provide + authentication and when each is to be used. This means + that for each situation the set of mechanisms that + might be used for authenticating the user must be + described. An example of a list of such rules is: + ``if the user has special privileges a + password mechanism and a biometric mechanism both + shall be used, with success only if both succeed; for + all other users a password mechanism shall be + used.'' + + The PP/ST author might give the boundaries within + which the authorised administrator may specify + specific rules. An example of a rule is: + ``the user shall always be authenticated by + means of a token; the administrator might specify + additional authentication mechanisms that also must be + used.'' The PP/ST author also might choose + not to specify any boundaries but leave the + authentication mechanisms and their rules completely + up to the authorised administrator. + + . + + + + + + + This component addresses potential needs to + re-authenticate users at defined points in time. These may + include user requests for the TSF to perform security + relevant actions, as well as requests from non-TSF + entities for re-authentication (e.g. a server application + requesting that the TSF re-authenticate the client it is + serving). + + + + , requires the ability to specify + events for which the user needs to be re-authenticated. + + + if an authorised administrator could request + re-authentication, the management includes a + re-authentication request. + + + Failure of reauthentication; + + + All reauthentication attempts. + + + The TSF shall re-authenticate the user under the conditions + + + list of conditions under which re-authentication is + required + + + + the PP/ST author should specify the list of conditions + requiring re-authentication. This list could include a + specified user inactivity period that has elapsed, the + user requesting a change in active security + attributes, or the user requesting the TSF to perform + some security critical function. + + The PP/ST author might give the boundaries within + which the reauthentication should occur and leave the + specifics to the authorised administrator. An example + of such a rule is: ``the user shall always + be re-authenticated at least once a day; the + administrator might specify that the re-authentication + should happen more often but not more often than once + every 10 minutes.'' + + . + + + + + + + + + + This component addresses the feedback on the + authentication process that will be provided to the + user. In some systems the feedback consists of indicating + how many characters have been typed but not showing the + characters themselves, in other systems even this + information might not be appropriate. + + This component requires that the authentication data is + not provided as-is back to the user. In a workstation + environment, it could display a + ``dummy'' (e.g. star) for each + password character provided, and not the original + character. + + + + , requires that only limited + feedback information is provided to the user during the + authentication. + + + The TSF shall provide only + + + list of feedback + + + + the PP/ST author should specify the feedback related + to the authentication process that will be provided to + the user. An example of a feedback assignment is + ``the number of characters + typed'', another type of feedback is + ``the authentication mechanism that failed + the authentication''. + + + to the user while the authentication is in progress. + + + + + + + + This family defines the conditions under which users shall + be required to identify themselves before performing any + other actions that are to be mediated by the TSF and which + require user identification. + + + + This family defines the conditions under which users are + required to identify themselves before performing any other + actions that are to be mediated by the TSF and that require + user identification. + + + + + + This component poses requirements for the user to be + identified. The PP/ST author can indicate specific actions + that can be performed before the identification takes + place. + + If is used, the TSF-mediated + actions mentioned in should also + appear in this . + + + + , allows users to perform certain + actions before being identified by the TSF. + + + the management of the user identities; + + + if an authorised administrator can change the actions + allowed before identification, the managing of the action + lists. + + + Unsuccessful use of the user identification mechanism, + including the user identity provided; + + + All use of the user identification mechanism, including the + user identity provided. + + + The TSF shall allow + + + list of TSF-mediated actions + + + + the PP/ST author should specify a list of TSF-mediated + actions that can be performed by the TSF on behalf of + a user before the user has to identify itself. If no + actions are appropriate, component should be used instead. An example of + such an action might include the request for help on + the login procedure. + + + on behalf of the user to be performed before the user is + identified. + + + The TSF shall require each user to be successfully identified before + allowing any other TSF-mediated actions on behalf of that user. + + + + + + + + In this component users will be identified. A user is not + allowed by the TSF to perform any action before being + identified. + + + + , requires that users identify + themselves before any other action will be allowed by the TSF. + + + the management of the user identities. + + + + + The TSF shall require each user to be successfully identified before + allowing any other TSF-mediated actions on behalf of that user. + + + + + + + + An authenticated user, in order to use the TOE, typically + activates a subject. The user's security + attributes are associated (totally or partially) with this + subject. This family defines requirements to create and + maintain the association of the user's security + attributes to a subject acting on the user's + behalf. + + + + An authenticated user, in order to use the TOE, typically + activates a subject. The user's security + attributes are associated (totally or partially) with this + subject. This family defines requirements to create and + maintain the association of the user's security + attributes to a subject acting on the user's + behalf. + + + + It is intended that a subject is + acting on behalf of the user who caused the subject to come into + being or to be activated to perform a certain task. + Therefore, when a subject is created, that subject is acting on + behalf of the user who initiated the creation. In cases where + anonymity is used, the subject is still acting on behalf of a + user, but the identity of that user is unknown. A special + category of subjects are those subjects that serve multiple + users (e.g. a server process). In such cases the user that + created this subject is assumed to be the ``owner''., requires the specification of any rules + governing the association between user attributes and the + subject attributes into which they are mapped. + an authorised administrator can define default subject security + attributes. + + an authorised administrator can change subject security + attributes. + + Unsuccessful binding of user security attributes to a subject + (e.g. creation of a subject). + + Success and failure of binding of user security attributes to a + subject (e.g. success or failure to create a subject). + + The TSF shall associate the following user security attributes + with subjects acting on the behalf of that user: + + list of user security attributes + + the PP/ST author should specify a list of the user security + attributes that are to be bound to subjects.. + + The TSF shall enforce the following rules on the initial + association of user security attributes with subjects acting on + the behalf of users: + + rules for the initial association of attributes + + the PP/ST author should specify any rules that are to apply + upon initial association of attributes with subjects, or + ``none''.. + + The TSF shall enforce the following rules governing changes to the + user security attributes associated with subjects acting on the + behalf of users: + + rules for the changing of attributes + + the PP/ST author should specify any rules that are to apply + when changes are made to the user security attributes + associated with subjects acting on behalf of users, or + ``none''.. + + + + + + + This class is intended to specify the management of several + aspects of the TSF: security attributes, TSF data and + functions. The different management roles and their + interaction, such as separation of capability, can be + specified. + + This class has several objectives: + + + management of TSF data, which include, for example, + banners; + + + management of security attributes, which include, for + example, the Access Control Lists, and Capability Lists; + + + management of functions of the TSF, which includes, for + example, the selection of functions, and rules or + conditions influencing the behaviour of the TSF; + + + definition of security roles. + + + + + + This class specifies the management of several aspects of the + TSF: security attributes, TSF data and functions in the + TSF. The different management roles and their interaction, + such as separation of capability, can also be specified + + In an environment where the TOE is made up of multiple + physically separated parts, the timing issues with respect to + propagation of security attributes, TSF data, and function + modification become very complex, especially if the + information is required to be replicated across the parts of + the TOE. This should be considered when selecting components + such as , or , where the behaviour might be + impaired. In such situations, use of components from is advisable. + + + + + + This family allows authorised users control over the + management of functions in the TSF. Examples of functions in + the TSF include the audit functions and the multiple + authentication functions. + + + + The TSF management functions enable authorised users to set + up and control the secure operation of the TOE. These + administrative functions typically fall into a number of + different categories: + + + Management functions that relate to access control, + accountability and authentication controls enforced by + the TOE. For example, definition and update of user + security characteristics (e.g. unique identifiers + associated with user names, user accounts, system entry + parameters) or definition and update of auditing system + controls (e.g. selection of audit events, management of + audit trails, audit trail analysis, and audit report + generation), definition and update of per-user policy + attributes (such as user clearance), definition of known + system access control labels, and control and management + of user groups. + + + Management functions that relate to controls over + availability. For example, definition and update of + availability parameters or resource quotas. + + + Management functions that relate to general installation + and configuration. For example, TOE configuration, + manual recovery, installation of TOE security fixes (if + any), repair and reinstallation of hardware. + + + Management functions that relate to routine control and + maintenance of TOE resources. For example, enabling and + disabling peripheral devices, mounting of removable + storage media, backup and recovery. + + + + Note that these functions need to be present in a TOE based + on the families included in the PP or ST. It is the + responsibility of the PP/ST author to ensure that adequate + functions will be provided to manage the TOE in a secure + fashion. + + The TSF might contain functions that can be controlled by an + administrator. For example, the auditing functions could be + switched off, the time synchronisation could be switchable, + and/or the authentication mechanism could be modifiable. + + + + + + + + + + This component allows identified roles to manage the + security functions of the TSF. This might entail obtaining + the current status of a security function, disabling or + enabling the security function, or modifying the behaviour + of the security function. An example of modifying the + behaviour of the security functions is changing of + authentication mechanisms. + + + + allows the authorised users (roles) + to manage the behaviour of functions in the TSF that use + rules or have specified conditions that may be manageable. + + + managing the group of roles that can interact with the + functions in the TSF; + + + All modifications in the behaviour of the functions in the + TSF. + + + The TSF shall restrict the ability to + + + determine the behaviour of + + + disable + + + enable + + + modify the behaviour of + + + + the PP/ST author should select whether the role can + determine the behaviour of, disable, enable, and/or + modify the behaviour of the security functions. + + + the functions + + + list of functions + + + + the PP/ST author should specify the functions that can + be modified by the identified roles. Examples include + auditing and time determination. + + + to + + + the authorised identified roles + + + + the PP/ST author should specify the roles that are + allowed to modify the functions in the TSF. The + possible roles are specified in . + + . + + + + + + + + This family allows authorised users control over the + management of security attributes. This management might + include capabilities for viewing and modifying of security + attributes. + + + + This family defines the requirements on the management of + security attributes. + + Security attributes affect the behaviour of the TSF. Examples of + security attributes are the groups to which a user belongs, the + roles he/she might assume, the priority of a process (subject), + and the rights belonging to a role or a user. These security + attributes might need to be managed by the user, a subject, a + specific authorised user (a user with explicitly given rights + for this management) or inherit values according to a given + policy/set of rules. + + It is noted that the right to assign rights to users is + itself a security attribute and/or potentially subject to + management by . + can be used to ensure that any + accepted combination of security attributes is within a + secure state. The definition of what + ``secure'' means is left to the TOE guidance. + + In some instances subjects, objects or user accounts are + created. If no explicit values for the related security + attributes are given, default values need to be used. can be used to specify that these default + values can be managed. + + + + + + + + + + + + + This component allows users acting in certain roles to + manage identified security attributes. The users are + assigned to a role within the component . + + The default value of a parameter is the value the + parameter takes when it is instantiated without + specifically assigned values. An initial value is provided + during the instantiation (creation) of a parameter, and + overrides the default value. + + + + allows authorised users (roles) to + manage the specified security attributes. + + + managing the group of roles that can interact with the + security attributes; + + management of rules by which security attributes inherit + specified values. + + + All modifications of the values of security attributes. + + + The TSF shall enforce the + + access control SFP(s), information flow control SFP(s) + + the PP/ST author should list the access control SFP(s) or + the information flow control SFP(s) for which the security + attributes are applicable. + to restrict the ability to + + + change_default + + + query + + + modify + + + delete + + + + + other operations + + + + if selected, the PP/ST author should specify which + other operations the role could perform. An + example of such an operation could be + ``create''. + + + + + + the PP/ST author should specify the operations that + can be applied to the identified security + attributes. The PP/ST author can specify that the role + can modify the default value (change_default), query, + modify the security attribute, delete the security + attributes entirely or define their own operation. + + + the security attributes + + + list of security attributes + + + + the PP/ST author should specify the security + attributes that can be operated on by the identified + roles. It is possible for the PP/ST author to specify + that the default value such as default access-rights + can be managed. Examples of these security attributes + are user-clearance, priority of service level, access + control list, default access rights. + + + to + + + the authorised identified roles + + + + the PP/ST author should specify the roles that are + allowed to operate on the security attributes. The + possible roles are specified in . + + . + + + + + + + + + + + + + + + This component contains requirements on the values that + can be assigned to security attributes. The assigned + values should be such that the TOE will remain in a secure + state. + + The definition of what ``secure'' means is + not answered in this component but is left to the + development of the TOE and the resulting information in the + guidance. An example could be that if a user account is + created, it should have a non-trivial password. + + + + ensures that values assigned to + security attributes are valid with respect to the secure + state. + + management of rules by which security attributes inherit + specified values. + + + All offered and rejected values for a security attribute; + + + All offered and accepted secure values for a security + attribute. + + + The TSF shall ensure that only secure values are accepted + for + list of security attributes + + the PP/ST author should specify the list of security + attributes that require only secure values to be provided.. + + + + + + + + + + + This component requires that the TSF provide default + values for relevant object security attributes, which can + be overridden by an initial value. It may still be + possible for a new object to have different security + attributes at creation, if a mechanism exists to specify + the permissions at time of creation. + + + + ensures that the default values of + security attributes are appropriately either permissive or + restrictive in nature. + + + managing the group of roles that can specify initial values; + + + managing the permissive or restrictive setting of default values + for a given access control SFP; + + management of rules by which security attributes inherit specified values. + + + Modifications of the default setting of permissive or + restrictive rules. + + + All modifications of the initial values of security + attributes. + + + The TSF shall enforce the + + + access control SFP, information flow control SFP + + + + the PP/ST author should list the access control SFP or + the information flow control SFP for which the + security attributes are applicable. + + + to provide + + + restrictive + + + permissive + + + other property + + if the PP/ST author selects another property, the PP/ST + author should specify the desired characteristics of the + default values. + + + the PP/ST author should select whether the default property + of the access control attribute will be restrictive, + permissive, or another property. Only one of these options + may be chosen. + + + default values for security attributes that are used to + enforce the SFP. + + + The TSF shall allow the + + + the authorised identified roles + + + + the PP/ST author should specify the roles that are + allowed to modify the values of the security + attributes. The possible roles are specified in . + + + to specify alternative initial values to override the + default values when an object or information is created. + + + This component requires specification of the set of rules + through which the security attribute inherits values and the + conditions to be met for these rules to be applied. allows the rules/policies + to be specified that will dictate the value to be inherited + by a security attribute. + specification of the role permitted to establish or modify + security attributes. + + Modifications of security attributes, possibly with the old + and/or values of security attributes that were modified. + + The TSF shall use the following rules to set the value of security attributes: + + rules for setting the values of security attributes + + the PP/ST author specifies the rules governing the value + that will be inherited by the specified security + attribute, including the conditions that are to be met + for the rules to be applied. For example, if a new file + or directory is created (in a multilevel filesystem), + its label is the label at which the user is logged in at + the time it is created. + + + + + + This family allows authorised users (roles) control over the + management of TSF data. Examples of TSF data include audit + information, clock and other TSF + configuration parameters. + + + + This component imposes requirements on the management of TSF + data. Examples of TSF data are the current time and the + audit trail. So, for example, this family allows the + specification of whom can read, delete or create the audit + trail. + + + + + + + + + This component allows users with a certain role to manage + values of TSF data. The users are assigned to a role + within the component . + + The default value of a parameter is the values the + parameter takes when it is instantiated without + specifically assigned values. An initial value is provided + during the instantiation (creation) of a parameter and + overrides the default value. + + + + allows authorised users to manage + TSF data. + + + managing the group of roles that can interact with the TSF + data. + + + All modifications to the values of TSF data. + + + The TSF shall restrict the ability to + + + change_default + + + query + + + modify + + + delete + + + clear + + + + + other operations + + + + if selected, the PP/ST author should specify which + other operations the role could perform. An + example could be + ``create''. + + + + + + the PP/ST author should specify the operations that + can be applied to the identified TSF data. The PP/ST + author can specify that the role can modify the + default value (change_default), clear, query or modify + the TSF data, or delete the TSF data entirely. If so + desired the PP/ST author could specify any type of + operation. To clarify ``clear TSF data'' means that + the content of the TSF data is removed, but that the + entity that stores the TSF data remains in the + TOE. + + + the + + + list of TSF data + + + + the PP/ST author should specify the TSF data that can + be operated on by the identified roles. It is possible + for the PP/ST author to specify that the default value + can be managed. + + + to + + + the authorised identified roles + + + + the PP/ST author should specify the roles that are + allowed to operate on the TSF data. The possible roles + are specified in . + + . + + + + + + + + + + + This component specifies limits on TSF data, and actions + to be taken if these limits are exceeded. This component, + for example, will allow limits on the size of the audit + trail to be defined, and specification of the actions to + be taken when these limits are exceeded. + + + + specifies the action to be taken if + limits on TSF data are reached or exceeded. + + + managing the group of roles that can interact with the + limits on the TSF data. + + + All modifications to the limits on TSF data; + + + All modifications in the actions to be taken in case of + violation of the limits. + + + The TSF shall restrict the specification of the limits for + + + list of TSF data + + + + the PP/ST author should specify the TSF data that can + have limits, and the value of those limits. An example + of such TSF data is the number of users logged-in. + + + to + + + the authorised identified roles + + + + the PP/ST author should specify the roles that are + allowed to modify the limits on the TSF data and the + actions to be taken. The possible roles are specified + in . + + . + + + The TSF shall take the following actions, if the TSF data + are at, or exceed, the indicated limits: + + + actions to be taken + + + + the PP/ST author should specify the actions to be + taken if the specified limit on the specified TSF data + is exceeded. An example of such TSF action is that the + authorised user is informed and an audit record is + generated. + + . + + + + + + + + + + This component covers requirements on the values that can + be assigned to TSF data. The assigned values should be + such that the TOE will remain in a secure state. + + The definition of what ``secure'' means is not + answered in this component but is left to the development of + the TOE and the + resulting information in the guidance. + + + + ensures that values assigned to TSF + data are valid with respect to the secure state. + + + All rejected values of TSF data. + + + The TSF shall ensure that only secure values are accepted + for + list of TSF data + + the PP/ST author should specify what TSF data require only + secure values to be accepted.. + + + + + + + + This family addresses revocation of security attributes for + a variety of entities within a TOE. + + + + This family addresses revocation of security attributes for + a variety of entities within a TOE. + + + + + + + + + This component specifies requirements on the revocation of + rights. It requires the specification of the revocation + rules. Examples are: + + + Revocation will take place on the next login of the + user; + + + Revocation will take place on the next attempt to open + the file; + + + Revocation will take place within a fixed time. This + might mean that all open connections are re-evaluated + every x minutes. + + + + + + provides for revocation of security + attributes to be enforced at some point in time. + + + managing the group of roles that can invoke revocation of + security attributes; + + + managing the lists of users, subjects, objects and other + resources for which revocation is possible; + + + managing the revocation rules. + + + Unsuccessful revocation of security attributes; + + + All attempts to revoke security attributes. + + + The TSF shall restrict the ability to revoke + + list of security attributes + + the PP/ST author should specify which security attributes + are to be revoked when a change is made to the associated + object/subject/user/other resource. + associated with the + + users + + subjects + + objects + other additional resources + the PP/ST author should, if additional resources is + selected, specify whether the ability to revoke their + security attributes shall be provided by the + TSF. + the PP/ST author should specify whether the ability to + revoke security attributes from users, subjects, objects, + or any additional resources shall be provided by the + TSF. + under the control of the TSF to + + the authorised identified roles + + the PP/ST author should specify the roles that are allowed + to modify the functions in the TSF. The possible roles are + specified in .. + + + The TSF shall enforce the rules + + + specification of revocation rules + + + + the PP/ST author should specify the revocation + rules. Examples of these rules could include: + ``prior to the next operation on the + associated resource'', or ``for + all new subject creations''. + + . + + + + + + + + This family addresses the capability to enforce time limits + for the validity of security attributes. + + + + This family addresses the capability to enforce time limits + for the validity of security attributes. This family can be + applied to specify expiration requirements for access + control attributes, identification and authentication + attributes, certificates (key certificates such as ANSI X509 + for example), audit attributes, etc. + + + + + + + + + + provides the capability for an + authorised user to specify an expiration time on specified + security attributes. + + + managing the list of security attributes for which + expiration is to be supported; + + + the actions to be taken if the expiration time has passed. + + + Specification of the expiration time for an attribute; + + + Action taken due to attribute expiration. + + + The TSF shall restrict the capability to specify an + expiration time for + + + list of security attributes for which expiration is to + be supported + + + + the PP/ST author should provide the list of security + attributes for which expiration is to be supported. An + example of such an attribute might be a + user's security clearance. + + + to + + + the authorised identified roles + + + + the PP/ST author should specify the roles that are + allowed to modify the security attributes in the + TSF. The possible roles are specified in . + + . + + + For each of these security attributes, the TSF shall be able + to + + + list of actions to be taken for each security attribute + + + + the PP/ST author should provide a list of actions to + be taken for each security attribute when it + expires. An example might be that the + user's security clearance, when it expires, + is set to the lowest allowable clearance on the + TOE. If immediate revocation is desired by the PP/ST, + the action ``immediate + revocation'' should be specified. + + + after the expiration time for the indicated security + attribute has passed. + + + + This family allows the specification of the management + functions to be provided by the TOE. Management functions + provide TSFI that allow administrators to define the + parameters that control the operation of security-related + aspects of the TOE, such as data protection attributes, TOE + protection attributes, audit attributes, and identification + and authentication attributes. Management functions also + include those functions performed by an operator to ensure + continued operation of the TOE, such as backup and + recovery. This family works in conjunction with the other + components in the class: the component in + this family calls out the management functions, and other + families in restrict the ability to use + these management functions. + This family allows the specification of the management + functions to be provided by the TOE. Each security + management function that is listed in fulfilling the + assignment is either security attribute management, TSF data + management, or security function management. + This component specifies the management functions to be + provided. + PP/ST authors should consult the ``Management'' sections + for components included in their PP/ST to provide a basis + for the management functions to be listed via this + component. requires that the TSF provide + specific management functions. + Use of the management functions. + + The TSF shall be capable of performing the following + management functions: + + list of management functions to be provided by + the TSF + + the PP/ST author should specify the management + functions to be provided by the TSF, either security + attribute management, TSF data management, or security + function management.. + + + + + + This family is intended to control the assignment of + different roles to users. The capabilities of these roles + with respect to security management are described in the + other families in this class. + + + + This family reduces the likelihood of damage resulting from + users abusing their authority by taking actions outside + their assigned functional responsibilities. It also + addresses the threat that inadequate mechanisms have been + provided to securely administer the TSF. + + This family requires that information be maintained to + identify whether a user is authorised to use a particular + security-relevant administrative function. + + Some management actions can be performed by users, others + only by designated people within the organisation. This + family allows the definition of different roles, such as + owner, auditor, administrator, daily-management. + + The roles as used in this family are security related + roles. Each role can encompass an extensive set of + capabilities (e.g. root in UNIX), or can be a single right + (e.g. right to read a single object such as the + helpfile). This family defines the roles. The capabilities + of the role are defined in , and . + + Some type of roles might be mutually exclusive. For example + the daily-management might be able to define and activate + users, but might not be able to remove users (which is + reserved for the administrator (role)). This class will + allow policies such as two-person control to be specified. + + + + + + + + + This component specifies the different roles that the TSF + should recognise. Often the system distinguishes between + the owner of an entity, an administrator and other users. + + + + specifies the roles with respect to + security that the TSF recognises. + + + managing the group of users that are part of a role. + + + modifications to the group of users that are part of a role; + + + every use of the rights of a role. + + + The TSF shall maintain the roles + + + the authorised identified roles + + + + the PP/ST author should specify the roles that are + recognised by the system. These are the roles that + users could occupy with respect to security. Examples + are: owner, auditor and administrator. + + . + + + The TSF shall be able to associate users with roles. + + + + + + + + + + + This component specifies the different roles that the TSF + should recognise, and conditions on how those roles could + be managed. Often the system distinguishes between the + owner of an entity, an administrator and other users. + + The conditions on those roles specify the + interrelationship between the different roles, as well as + restrictions on when the role can be assumed by a user. + + + + specifies that in addition to the + specification of the roles, there are rules that control + the relationship between the roles. + + + managing the group of users that are part of a role; + + + managing the conditions that the roles must satisfy. + + + modifications to the group of users that are part of a role; + + + unsuccessful attempts to use a role due to the given + conditions on the roles; + + + every use of the rights of a role. + + + The TSF shall maintain the roles: + + + authorised identified roles + + + + the PP/ST author should specify the roles that are + recognised by the system. These are the roles that + users could occupy with respect to security. Examples + are: owner, auditor, administrator. + + . + + + The TSF shall be able to associate users with roles. + + + The TSF shall ensure that the conditions + + + conditions for the different roles + + + + the PP/ST author should specify the conditions that + govern role assignment. Examples of these conditions + are: ``an account cannot have both the + auditor and administrator role'' or + ``a user with the assistant role must also + have the owner role''. + + + are satisfied. + + + + + + + + + + This component specifies that an explicit request must be + given to assume the specific role. + + + + , requires that an explicit request + is given to the TSF to assume a role. + + + explicit request to assume a role. + + + The TSF shall require an explicit request to assume the + following roles: + + + the roles + + + + the PP/ST author should specify the roles that require + an explicit request to be assumed. Examples are: + auditor and administrator. + + . + + + + + + + + This class contains privacy requirements. These requirements + provide a user protection against discovery and misuse of + identity by other users. + + + + This class describes the requirements that could be levied to + satisfy the users' privacy needs, while still allowing + the system flexibility as far as possible to maintain + sufficient control over the operation of the system. + + In the components of this class there is flexibility as to + whether or not authorised users are covered by the required + security functionality. For example, a PP/ST author might + consider it appropriate not to require protection of the privacy + of users against a suitably authorised user. + + This class, together with other classes (such as those + concerned with audit, access control, trusted path, and + non-repudiation) provides the flexibility to specify the + desired privacy behaviour. On the other hand, the requirements + in this class might impose limitations on the use of the + components of other classes, such as or . For example, if + authorised users are not allowed to see the user identity + (e.g. Anonymity or Pseudonymity), it will obviously not be + possible to hold individual users accountable for any security + relevant actions they perform that are covered by the privacy + requirements. However, it may still be possible to include + audit requirements in a PP/ST, where the fact that a + particular security relevant event has occurred is more + important than knowing who was responsible for it. + + Additional information is provided in the application notes + for class , where it is explained that the + definition of ``identity'' in the context of + auditing can also be an alias or other information that could + identify a user. + + This class describes four families: Anonymity, Pseudonymity, + Unlinkability and Unobservability. Anonymity, Pseudonymity and + Unlinkability have a complex interrelationship. When choosing + a family, the choice should depend on the threats + identified. For some types of privacy threats, pseudonymity + will be more appropriate than anonymity (e.g. if there is a + requirement for auditing). In addition, some types of privacy + threats are best countered by a combination of components from + several families. + + All families assume that a user does not explicitly perform an + action that discloses the user's own identity. For + example, the TSF is not expected to screen the user name in + electronic messages or databases. + + All families in this class have components that can be scoped + through operations. These operations allow the PP/ST author to + state the cooperating users/subjects to which the TSF must be + resistant. An example of an instantiation of anonymity could + be: `` The TSF shall ensure that the users and/or + subjects are unable to determine the user identity bound to + the teleconsulting application''. + + It is noted that the TSF should not only provide this + protection against individual users, but also against users + cooperating to obtain the information. + + + + + + This family ensures that a user may use a resource or + service without disclosing the user's identity. The + requirements for Anonymity provide protection of the user + identity. Anonymity is not intended to protect the subject + identity. + + + + Anonymity ensures that a subject may use a resource or + service without disclosing its user identity. + + The intention of this family is to specify that a user or + subject might take action without releasing its user + identity to others such as users, subjects, or objects. The + family provides the PP/ST author with a means to identify + the set of users that cannot see the identity of someone + performing certain actions. + + Therefore if a subject, using anonymity, performs an action, + another subject will not be able to determine either the + identity or even a reference to the identity of the user + employing the subject. The focus of the anonymity is on the + protection of the users identity, not on the protection of + the subject identity; hence, the identity of the subject is + not protected from disclosure. + + Although the identity of the subject is not released to + other subjects or users, the TSF is not explicitly + prohibited from obtaining the users identity. In case the + TSF is not allowed to know the identity of the user, could be invoked. In that case + the TSF should not request the user information. + + The interpretation of ``determine'' should be + taken in the broadest sense of the word. + + The component levelling distinguishes between the users and + an authorised user. An authorised user is often excluded + from the component, and therefore allowed to retrieve a + user's identity. However, there is no specific + requirement that an authorised user must be able to have the + capability to determine the user's identity. For + ultimate privacy the components would be used to say that no + user or authorised user can see the identity of anyone + performing any action. + + Although some systems will provide anonymity for all + services that are provided, other systems provide anonymity + for certain subjects/operations. To provide this + flexibility, an operation is included where the scope of the + requirement is defined. If the PP/ST author wants to address + all subjects/operations, the words ``all subjects and + all operations'' could be provided. + + Possible applications include the ability to make enquiries + of a confidential nature to public databases, respond to + electronic polls, or make anonymous payments or donations. + + Examples of potential hostile users or subjects are + providers, system operators, communication partners and + users, who smuggle malicious parts (e.g. Trojan Horses) into + systems. All of these users can investigate usage patterns + (e.g. which users used which services) and misuse this + information. + + + + + + This component ensures that the identity of a user is + protected from disclosure. There may be instances, + however, that a given authorised user can determine who + performed certain actions. This component gives the + flexibility to capture either a limited or total privacy + policy. + + + + , requires that other users or + subjects are unable to determine the identity of a user + bound to a subject or operation. + + + The invocation of the anonymity mechanism. + + + The TSF shall ensure that + + + set of users and/or subjects + + + + the PP/ST author should specify the set of users + and/or subjects against which the TSF must provide + protection. For example, even if the PP/ST author + specifies a single user or subject role, the TSF must + not only provide protection against each individual + user or subject, but must protect with respect to + cooperating users and/or subjects. A set of users, for + example, could be a group of users which can operate + under the same role or can all use the same + process(es). + + + are unable to determine the real user name bound to + + + list of subjects and/or operations and/or objects + + + + the PP/ST author should identify the list of subjects + and/or operations and/or objects where the real user + name of the subject should be protected, for example, + ``the voting application''. + + . + + + + + + + + This component is used to ensure that the TSF is not + allowed to know the identity of the user. + + + + enhances the + requirements of by + ensuring that the TSF does not ask for the user + identity. + + + + The TSF shall ensure that + + + set of users and/or subjects + + + + the PP/ST author should specify the set of users + and/or subjects against which the TSF must provide + protection. For example, even if the PP/ST author + specifies a single user or subject role, the TSF must + not only provide protection against each individual + user or subject, but must protect with respect to + cooperating users and/or subjects. A set of users, for + example, could be a group of users which can operate + under the same role or can all use the same + process(es). + + + are unable to determine the real user name bound to + + + list of subjects and/or operations and/or objects + + + + the PP/ST author should identify the list of subjects + and/or operations and/or objects where the real user + name of the subject should be protected, for example, + ``the voting application''. + + . + + + The TSF shall provide + + + list of services + + + + the PP/ST author should identify the list of services + which are subject to the anonymity requirement, for + example, ``the accessing of job + descriptions''. + + + to + + + list of subjects + + + + the PP/ST author should identify the list of subjects + from which the real user name of the subject should be + protected when the specified services are provided. + + + without soliciting any reference to the real user name. + + + + + + + + This family ensures that a user may use a resource or + service without disclosing its user identity, but can still + be accountable for that use. + + + + Pseudonymity ensures that a user may use a resource or + service without disclosing its identity, but can still be + accountable for that use. The user can be accountable by + directly being related to a reference (alias) held by the + TSF, or by providing an alias that will be used for + processing purposes, such as an account number. + + In several respects, pseudonymity resembles anonymity. Both + pseudonymity and anonymity protect the identity of the user, + but in pseudonymity a reference to the user's + identity is maintained for accountability or other purposes. + + The component does not + specify the requirements on the reference to the user's + identity. For the purpose of specifying requirements on this + reference two sets of requirements are presented: and . + + A way to use the reference is by being able to obtain the + original user identity. For example, in a digital cash + environment it would be advantageous to be able to trace the + user's identity when a check has been issued multiple times + (i.e. fraud). In general, the user's identity needs to be + retrieved under specific conditions. The PP/ST author might + want to incorporate to + describe those services. + + Another usage of the reference is as an alias for a + user. For example, a user who does not wish to be + identified, can provide an account to which the resource + utilisation should be charged. In such cases, the reference + to the user identity is an alias for the user, where other + users or subjects can use the alias for performing their + functions without ever obtaining the user's + identity (for example, statistical operations on use of the + system). In this case, the PP/ST author might wish to + incorporate to specify the rules to + which the reference must conform. + + Using these constructs above, digital money can be created + using specifying that the user + identity will be protected and, if so specified in the + condition, that there be a requirement to trace the user + identity if the digital money is spent twice. When the user + is honest, the user identity is protected; if the user tries + to cheat, the user identity can be traced. + + A different kind of system could be a digital credit card, + where the user will provide a pseudonym that indicates an + account from which the cash can be subtracted. In such + cases, for example, could be + used. This component would specify that the user identity + will be protected and, furthermore, that the same user will + only get assigned values for which he/she has provided money + (if so specified in the conditions). + + It should be realised that the more stringent components + potentially cannot be combined with other requirements, such + as identification and authentication or audit. The + interpretation of ``determine the identity'' + should be taken in the broadest sense of the word. The + information is not provided by the TSF during the operation, + nor can the entity determine the subject or the owner of the + subject that invoked the operation, nor will the TSF record + information, available to the users or subjects, which might + release the user identity in the future. + + The intent is that the TSF not reveal any information that + would compromise the identity of the user, e.g. the identity + of subjects acting on the user's behalf. The + information that is considered to be sensitive depends on + the effort an attacker is capable of spending. + + Possible applications include the ability to charge a caller + for premium rate telephone services without disclosing his + or her identity, or to be charged for the anonymous use of + an electronic payment system. + + Examples of potential hostile users are providers, system + operators, communication partners and users, who smuggle + malicious parts (e.g. Trojan Horses) into systems. All of + these attackers can investigate which users used which + services and misuse this information. Additionally to + Anonymity services, Pseudonymity Services contains methods + for authorisation without identification, especially for + anonymous payment (``Digital Cash''). This + helps providers to obtain their payment in a secure way + while maintaining customer anonymity. + + + + + + This component provides the user protection against + disclosure of identity to other users. The user will + remain accountable for its actions. + + + + requires that a set of users and/or + subjects are unable to determine the identity of a user + bound to a subject or operation, but that this user is + still accountable for its actions. + + + The subject/user that requested resolution of the user + identity should be audited. + + + The TSF shall ensure that + + + set of users and/or subjects + + + + the PP/ST author should specify the set of users + and/or subjects against which the TSF must provide + protection. For example, even if the PP/ST author + specifies a single user or subject role, the TSF must + not only provide protection against each individual + user or subject, but must protect with respect to + cooperating users and/or subjects. A set of users, for + example, could be a group of users which can operate + under the same role or can all use the same + process(es). + + + are unable to determine the real user name bound to + + + list of subjects and/or operations and/or objects + + + + the PP/ST author should identify the list of subjects + and/or operations and/or objects where the real user + name of the subject should be protected, for example, + ``the accessing of job offers''. Note + that ``objects'' includes any other + attributes that might enable another user or subject + to derive the actual identity of the user. + + . + + + The TSF shall be able to provide + + + number of aliases + + + + the PP/ST author should identify the (one or more) + number of aliases the TSF is able to provide. + + + aliases of the real user name to + + + list of subjects + + + + the PP/ST author should identify the list of subjects + to whom the TSF is able to provide an alias. + + . + + + The TSF shall + + + determine an alias for a user + + + accept the alias from the user + + + + the PP/ST author should specify whether the user alias is + generated by the TSF, or supplied by the user. Only one of + these options may be chosen. + + + and verify that it conforms to the + + + alias metric + + + + the PP/ST author should identify the metric to which + the TSF-generated or user-generated alias should + conform. + + . + + + + + + + + + + + In this component, the TSF shall ensure that under + specified conditions the user identity related to a + provided reference can be determined. + + In the TSF shall provide an alias + instead of the user identity. When the specified + conditions are satisfied, the user identity to which the + alias belong can be determined. An example of such a + condition in an electronic cash environment is: `` + The TSF shall provide the notary a capability to determine + the user identity based on the provided alias only under + the conditions that a check has been issued + twice.''. + + + + , requires the TSF to provide a + capability to determine the original user identity based + on a provided alias. + + + + The TSF shall ensure that + + + set of users and/or subjects + + + + the PP/ST author should specify the set of users + and/or subjects against which the TSF must provide + protection. For example, even if the PP/ST author + specifies a single user or subject role, the TSF must + not only provide protection against each individual + user or subject, but must protect with respect to + cooperating users and/or subjects. A set of users, for + example, could be a group of users which can operate + under the same role or can all use the same + process(es). + + + are unable to determine the real user name bound to + + + list of subjects and/or operations and/or objects + + + + the PP/ST author should identify the list of subjects + and/or operations and/or objects where the real user + name of the subject should be protected, for example, + ``the accessing of job offers''. Note + that ``objects'' includes any other + attributes that might enable another user or subject + to derive the actual identity of the user. + + . + + + The TSF shall be able to provide + + + number of aliases + + + + the PP/ST author should identify the (one or more) + number of aliases the TSF, is able to provide. + + + aliases of the real user name to + + + list of subjects + + + + the PP/ST author should identify the list of subjects + to whom the TSF is able to provide an alias. + + . + + + The TSF shall + + + determine an alias for a user + + + accept the alias from the user + + + + the PP/ST author should specify whether the user alias is + generated by the TSF or supplied by the user. Only one of + these options may be chosen. + + + and verify that it conforms to the + + + alias metric + + + + the PP/ST author should identify the metric to which + the TSF-generated or user-generated alias should + conform. + + . + + + The TSF shall provide + + + an authorised user + + + + + list of trusted subjects + + + + the PP/ST author should identify the list of trusted + subjects that can obtain the real user name under a + specified condition, for example, a notary or + special authorised user. + + + + + + the PP/ST author should select whether the authorised + user and/or trusted subjects can determine the real + user name. + + + a capability to determine the user identity based on the + provided alias only under the following + + + list of conditions + + + + the PP/ST author should identify the list of + conditions under which the trusted subjects and + authorised user can determine the real user name based + on the provided reference. These conditions can be + conditions such as time of day, or they can be + administrative such as on a court order. + + . + + + + + + + + In this component, the TSF shall ensure that the provided + reference meets certain construction rules, and thereby + can be used in a secure way by potentially insecure + subjects. + + If a user wants to use disk resources without disclosing + its identity, pseudonymity can be used. However, every + time the user accesses the system, the same alias must be + used. Such conditions can be specified in this component. + + + + , requires the TSF to + follow certain construction rules for the alias to the user + identity. + + + + The TSF shall ensure that + + + set of users and/or subjects + + + + the PP/ST author should specify the set of users + and/or subjects against which the TSF must provide + protection. For example, even if the PP/ST author + specifies a single user or subject role, the TSF must + not only provide protection against each individual + user or subject, but must protect with respect to + cooperating users and/or subjects. A set of users, for + example, could be a group of users which can operate + under the same role or can all use the same + process(es). + + + are unable to determine the real user name bound to + + + list of subjects and/or operations and/or objects + + + + the PP/ST author should identify the list of subjects + and/or operations and/or objects where the real user + name of the subject should be protected, for example, + ``the accessing of job offers''. Note + that ``objects'' includes any other + attributes which might enable another user or subject + to derive the actual identity of the user. + + . + + + The TSF shall be able to provide + + + number of aliases + + + + the PP/ST author should identify the (one or more) + number of aliases the TSF is able to provide. + + + aliases of the real user name to + + + list of subjects + + + + the PP/ST author should identify the list of subjects + to whom the TSF is able to provide an alias. + + . + + + The TSF shall + + + determine an alias for a user + + + accept the alias from the user + + + + the PP/ST author should specify whether the user alias is + generated by the TSF, or supplied by the user. Only one of + these options may be chosen. + + + and verify that it conforms to the + + + alias metric + + + + the PP/ST author should identify the metric to which + the TSF-generated or user-generated alias should + conform. + + . + + + The TSF shall provide an alias to the real user name which + shall be identical to an alias provided previously under the + following + + + list of conditions + + + + the PP/ST author should identify the list of + conditions that indicate when the used reference for + the real user name shall be identical and when it + shall be different, for example, ``when the + user logs on to the same host'' it will use a + unique alias. + + + otherwise the alias provided shall be unrelated to + previously provided aliases. + + + + + + + This family ensures that a user may make multiple uses of + resources or services without others being able to link + these uses together. + + + + Unlinkability ensures that a user may make multiple uses of + resources or services without others being able to link + these uses together. Unlinkability differs from pseudonymity + that, although in pseudonymity the user is also not known, + relations between different actions can be provided. + + The requirements for unlinkability are intended to protect + the user identity against the use of profiling of the + operations. For example, when a telephone smart card is + employed with a unique number, the telephone company can + determine the behaviour of the user of this telephone + card. When a telephone profile of the users is known, the + card can be linked to a specific user. Hiding the + relationship between different invocations of a service or + access of a resource will prevent this kind of information + gathering. + + As a result, a requirement for unlinkability could imply + that the subject and user identity of an operation must be + protected. Otherwise this information might be used to link + operations together. + + Unlinkability requires that different operations cannot be + related. This relationship can take several forms. For + example, the user associated with the operation, or the + terminal which initiated the action, or the time the action + was executed. The PP/ST author can specify what kind of + relationships are present that must be countered. + + Possible applications include the ability to make multiple + use of a pseudonym without creating a usage pattern that + might disclose the user's identity. + + Examples for potential hostile subjects and users are + providers, system operators, communication partners and + users, who smuggle malicious parts, (e.g. Trojan Horses) + into systems, they do not operate but want to get + information about. All of these attackers can investigate + (e.g. which users used which services) and misuse this + information. Unlinkability protects users from linkages, + which could be drawn between several actions of a + customer. An example is a series of phone calls made by an + anonymous customer to different partners, where the + combination of the partner's identities might disclose the + identity of the customer. + + + + + + This component ensures that users cannot link different + operations in the system and thereby obtain information. + + + + , requires that users and/or subjects + are unable to determine whether the same user caused + certain specific operations. + + + the management of the unlinkability function. + + + The invocation of the unlinkability mechanism. + + + The TSF shall ensure that + + + set of users and/or subjects + + + + the PP/ST author should specify the set of users + and/or subjects against which the TSF must provide + protection. For example, even if the PP/ST author + specifies a single user or subject role, the TSF must + not only provide protection against each individual + user or subject, but must protect with respect to + cooperating users and/or subjects. A set of users, for + example, could be a group of users which can operate + under the same role or can all use the same + process(es). + + + are unable to determine whether + + + list of operations + + + + the PP/ST author should identify the list of + operations which should be subjected to the + unlinkability requirement, for example, + ``sending email''. + + + + + were caused by the same user + + + are related as follows + + + list of relations + + + + the PP/ST author should identify the list of + relations which should be protected against, for + example, ``originate from the same + terminal''. + + + + + + the PP/ST author should select the relationships that + should be obscured. The selection allows either the + user identity or an assignment of relations to be + specified. + + . + + + + + + + + This family ensures that a user may use a resource or + service without others, especially third parties, being able + to observe that the resource or service is being used. + + + + Unobservability ensures that a user may use a resource or + service without others, especially third parties, being able + to observe that the resource or service is being used. + + Unobservability approaches the user identity from a + different direction than the previous families Anonymity, + Pseudonymity and Unlinkability. In this case, the intent is + to hide the use of a resource or service, rather than to + hide the user's identity. + + A number of techniques can be applied to implement + unobservability. Examples of techniques to provide + unobservability are: + + + Allocation of information impacting unobservability: + Unobservability relevant information (e.g. information + that describes that an operation occurred) can be + allocated in several locations within the TOE. The + information might be allocated to a single randomly + chosen part of the TOE such that an attacker does not + know which part of the TOE should be attacked. An + alternative system might distribute the information such + that no single part of the TOE has sufficient + information that, if circumvented, the privacy of the + user would be compromised. This technique is explicitly + addressed in . + + + Broadcast: When information is broadcast (e.g. ethernet, + radio), users cannot determine who actually received and + used that information. This technique is especially + useful when information should reach receivers which + have to fear a stigma for being interested in that + information (e.g. sensitive medical information). + + + Cryptographic protection and message padding: People + observing a message stream might obtain information from + the fact that a message is transferred and from + attributes on that message. By traffic padding, message + padding and encrypting the message stream, the + transmission of a message and its attributes can be + protected. + + + + Sometimes, users should not see the use of a resource, but an + authorised user must be allowed to see the use of the resource + in order to perform his duties. In such cases, the could be used, which provides the + capability for one or more authorised users to see the + usage. + + This family makes use of the concept ``parts of the + TOE''. This is considered any part of the TOE that is either + physically or logically separated from other parts of the + TOE. + + Unobservability of communications may be an important factor + in many areas, such as the enforcement of constitutional + rights, organisational policies, or in defence related + applications. + + + + + + This component requires that the use of a function or + resource cannot be observed by unauthorised users. + + + + , requires that users and/or + subjects cannot determine whether an operation is being + performed. + + + the management of the behaviour of the unobservability + function. + + + The invocation of the unobservability mechanism. + + + The TSF shall ensure that + + + list of users and/or subjects + + + + the PP/ST author should specify the list of users and/or + subjects against which the TSF must provide + protection. For example, even if the PP/ST author + specifies a single user or subject role, the TSF must + not only provide protection against each individual user + or subject, but must protect with respect to cooperating + users and/or subjects. A set of users, for example, + could be a group of users which can operate under the + same role or can all use the same process(es). + + + are unable to observe the operation + + + list of operations + + + + the PP/ST author should identify the list of + operations that are subjected to the unobservability + requirement. Other users/subjects will then not be + able to observe the operations on a covered object in + the specified list (e.g. reading and writing to the + object). + + + on + + + list of objects + + + + the PP/ST author should identify the list of objects + which are covered by the unobservability + requirement. An example could be a specific mail + server or ftp site. + + + by + + + list of protected users and/or subjects + + + + the PP/ST author should specify the set of protected + users and/or subjects whose unobservability + information will be protected. An example could be: + ``users accessing the system through the + internet''. + + . + + + + + + + + + This component requires that the use of a function or + resource cannot be observed by specified users or + subjects. Furthermore this component specifies that + information related to the privacy of the user is + distributed within the TOE such that attackers might not + know which part of the TOE to target, or they need to + attack multiple parts of the TOE. + + An example of the use of this component is the use of a + randomly allocated node to provide a function. In such a + case the component might require that the privacy related + information shall only be available to one identified part + of the TOE, and will not be communicated outside this part + of the TOE. + + A more complex example can be found in some + ``voting algorithms''. Several parts of the + TOE will be involved in the service, but no individual + part of the TOE will be able to violate the policy. So a + person may cast a vote (or not) without the TOE being able + to determine whether a vote has been cast and what the + vote happened to be (unless the vote was unanimous). + + + + + , requires that the TSF + provide specific mechanisms to avoid the concentration of + privacy related information within the TOE. Such + concentrations might impact unobservability if a security + compromise occurs. + + + + + + The TSF shall ensure that + + + list of users and/or subjects + + + + the PP/ST author should specify the list of users + and/or subjects against which the TSF must provide + protection. For example, even if the PP/ST author + specifies a single user or subject role, the TSF must + not only provide protection against each individual + user or subject, but must protect with respect to + cooperating users and/or subjects. A set of users, for + example, could be a group of users which can operate + under the same role or can all use the same + process(es). + + + are unable to observe the operation + + + list of operations + + + + the PP/ST author should identify the list of + operations that are subjected to the unobservability + requirement. Other users/subjects will then not be + able to observe the operations on a covered object in + the specified list (e.g. reading and writing to the + object). + + + on + + + list of objects + + + + the PP/ST author should identify the list of objects + which are covered by the unobservability + requirement. An example could be a specific mail + server or ftp site. + + + by + + + list of protected users and/or subjects + + + + the PP/ST author should specify the set of protected + users and/or subjects whose unobservability + information will be protected. An example could be: + ``users accessing the system through the + internet''. + + . + + + The TSF shall allocate the + + + unobservability related information + + + + the PP/ST author should identify which privacy related + information should be distributed in a controlled + manner. Examples of this information could be: IP + address of subject, IP address of object, time, used + encryption keys. + + + among different parts of the TOE such that the following + conditions hold during the lifetime of the information: + + + list of conditions + + + + the PP/ST author should specify the conditions to + which the dissemination of the information should + adhere. These conditions should be maintained + throughout the lifetime of the privacy related + information of each instance. Examples of these + conditions could be: ``the information shall + only be present at a single separated part of the TOE + and shall not be communicated outside this part of the + TOE.'', ``the information shall only + reside in a single separated part of the TOE, but + shall be moved to another part of the TOE + periodically'', ``the information shall + be distributed between the different parts of the TOE + such that compromise of any 5 separated parts of the + TOE will not compromise the security policy''. + + . + + + + + + + + + + This component is used to require that the TSF does not + try to obtain information that might compromise + unobservability when provided specific services. Therefore + the TSF will not solicit (i.e. try to obtain from other + entities) any information that might be used to compromise + unobservability. + + + + , requires that the TSF + does not try to obtain privacy related information that + might be used to compromise unobservability. + + + The TSF shall provide + + + list of services + + + + the PP/ST author should identify the list of services + which are subject to the unobservability requirement, + for example, ``the accessing of job + descriptions''. + + + to + + + list of subjects + + + + the PP/ST author should identify the list of subjects + from which privacy related information should be + protected when the specified services are provided. + + + without soliciting any reference to + + + privacy related information + + + + the PP/ST author should specify the privacy related + information that will be protected from the specified + subjects. Examples include the identity of the subject + that used a service and the quantity of a service that + has been used such as memory resource + utilisation. + + . + + + + + + + This component is used to require that there will be one + or more authorised users with the rights to view the + resource utilisation. Without this component, this review + is allowed, but not mandated. + + + + , requires the TSF to + provide one or more authorised users with a capability to + observe the usage of resources and/or services. + + + the list of authorised users that are capable of determining + the occurrence of operations. + + + The observation of the use of a resource or service by a + user or subject. + + + The TSF shall provide + + + set of authorised users + + + + the PP/ST author should specify the set of authorised + users for which the TSF must provide the capability to + observe the resource utilisation. A set of authorised + users, for example, could be a group of authorised users + which can operate under the same role or can all use the + same process(es). + + + with the capability to observe the usage of + + + list of resources and/or services + + + + the PP/ST author should specify the set of resources + and/or services that the authorised user must be able + to observe. + + . + + + + + + + + This class contains families of functional requirements that + relate to the integrity and management of the mechanisms that + constitute the TSF and to the integrity of TSF data. In some + sense, families in this class may appear to duplicate + components in the class; they may + even be implemented using the same mechanisms. However, focuses on user data protection, while + focuses on TSF data + protection. In fact, components from the class are necessary to provide requirements that + the SFPs in the TOE cannot be tampered with or + bypassed. + + From the point of view of this class, regarding to the + TSF there are three significant elements: + + The TSF's implementation, which executes and implements the + mechanisms that enforce the SFRs. + + The TSF's data, which are the administrative databases that guide the + enforcement of the SFRs. + + The external entities that the TSF may interact with in order to + enforce the SFRs. + + + + + This class contains families of functional requirements that + relate to the integrity and management of the mechanisms that + constitute the TSF and to the + integrity of TSF data. In some sense, families in this class may + appear to duplicate components in the + class; they may even be implemented using the + same mechanisms. However, focuses on user + data protection, while focuses on TSF data + protection. In fact, components from the + class are necessary to provide requirements that the SFPs in + the TOE cannot be tampered with or bypassed. + + From the point of view of this class, regarding to the + TSF there are three significant elements: + + The TSF's implementation, which executes and implements the + mechanisms that enforce the SFRs. + + The TSF's data, which are the administrative databases that guide the + enforcement of the SFRs. + + The external entities that the TSF may interact with in order to + enforce the SFRs. + + + All of the families in the class can be + related to these areas, and fall into the following groupings: + , which provides an authorised user + with the ability to detect external attacks on the parts + of the TOE that comprise the TSF. + and , + which provide an authorised user with the ability to verify the correct + operation of the external entities interacting with the TSF to enforce + the SFRs, and the integrity of the TSF data and TSF itself. + , , and , which address the behaviour of the TSF + when failure occurs and immediately after. + , , , + which address the protection and availability of TSF data between the TSF and another trusted IT product. + , which addresses protection of TSF + data when it is transmitted between physically-separated + parts of the TOE. + , which addresses the replay of + various types of information and/or operations. + , which addresses the synchronisation + of states, based upon TSF data, between different parts of + a distributed TSF. + , which addresses reliable timing. + , which addresses the consistency of + TSF data shared between the TSF and another trusted IT product. + + + + + + + + + The requirements of this family ensure that the TOE will always enforce + its SFRs in the event of identified categories of + failures in the TSF. + + + + The requirements of this family ensure that the TOE will + always enforce its SFRs in the event of certain + types of failures in the TSF. + + + + + + The term ``secure state'' refers to a state in which the + TSF data are consistent and the TSF continues correct + enforcement of the SFRs. + + Although it is desirable to audit situations in which + failure with preservation of secure state occurs, it is + not possible in all situations. The PP/ST author should + specify those situations in which audit is desired and + feasible. + + Failures in the TSF may include + ``hard'' failures, which indicate an + equipment malfunction and which may require maintenance, + service or repair of the TSF. Failures in the TSF may also + include recoverable ``soft'' failures, + which may only require initialisation or resetting of the + TSF. + + + + This family consists of only one component, , which requires that the TSF preserve a + secure state in the face of the identified failures. + + + Failure of the TSF. + + + The TSF shall preserve a secure state when the following + types of failures occur: + + + list of types of failures in the TSF + + + + the PP/ST author should list the types of failures in + the TSF for which the TSF should ``fail + secure,'' that is, should preserve a secure + state and continue to correctly enforce the SFRs. + + . + + + + + + + + This family defines the rules for the prevention of loss of + availability of TSF data moving between the TSF and another + trusted IT product. This data could, for example, be TSF + critical data such as passwords, keys, audit data, or TSF + executable code. + + + + This family defines the rules for the prevention of loss of + availability of TSF data moving between the TSF and another + trusted IT product. This data could be TSF critical data + such as passwords, keys, audit data, or TSF executable code. + + This family is used in a distributed context where the TSF + is providing TSF data to another trusted IT product. The + TSF can only take the measures at its site and cannot be + held responsible for the TSF at the other trusted IT + product. + + If there are different availability metrics for different + types of TSF data, then this component should be iterated + for each unique pairing of metrics and types of TSF data. + + + + + + This family consists of only one component, . + This component requires that the TSF ensure, to an identified degree of probability, the + availability of TSF data provided to another trusted IT product. + + + management of the list of types of TSF data that must be + available to another trusted IT product. + + + the absence of TSF data when required by a TOE. + + + The TSF shall ensure the availability of + + list of types of TSF data + + the PP/ST author should specify the types of TSF data + that are subject to the availability metric. + provided to another trusted IT product within + + a defined availability metric + + the PP/ST should specify the availability metric for + the applicable TSF data. + given the following conditions + + conditions to ensure availability + + the PP/ST author should specify the conditions under + which availability must be ensured. For example: + there must be a connection between the TOE and + another trusted IT product.. + + + + + + + + This family defines the rules for the protection from + unauthorised disclosure of TSF data during transmission + between the TSF and another trusted IT product. This data + could, for example, be TSF critical data such as passwords, + keys, audit data, or TSF executable code. + + + + This family defines the rules for the protection from + unauthorised disclosure of TSF data moving between the TSF + and another trusted IT product. Examples of this data are + TSF critical data such as passwords, keys, audit data, or + TSF executable code. + + This family is used in a distributed context where + the TSF is providing TSF data to another trusted IT + product. The TSF can only take the measures at its site and + cannot be held responsible for the behaviour of the other + trusted IT product. + + + + + + Confidentiality of TSF Data during transmission is + necessary to protect such information from + disclosure. Some possible implementations that could + provide confidentiality include the use of cryptographic + algorithms as well as spread spectrum techniques. + + + + This family consists of only one component, , + which requires that the TSF ensure that data transmitted between the TSF and another trusted IT + product is protected from disclosure while in transit. + + + The TSF shall protect all TSF data transmitted from the TSF + to another trusted IT product from unauthorised disclosure + during transmission. + + + + + + + + This family defines the rules for the protection, from + unauthorised modification, of TSF data during transmission + between the TSF and another trusted IT product. This data + could, for example, be TSF critical data such as passwords, + keys, audit data, or TSF executable code. + + + + This family defines the rules for the protection, from + unauthorised modification, of TSF data during transmission + between the TSF and another trusted IT product. Examples of + this data are TSF critical data such as passwords, keys, + audit data, or TSF executable code. + + This family is used in a distributed context where + the TSF is exchanging TSF data with another trusted IT + product. Note that a requirement that addresses + modification, detection, or recovery at another trusted + IT product cannot be specified, as the mechanisms that + another trusted IT product will use to protect its data + cannot be determined in advance. For this reason, these + requirements are expressed in terms of the ``TSF + providing a capability'' which another trusted + IT product can use. + + + + + + This component should be used in situations where it is + sufficient to detect when data have been modified. An + example of such a situation is one in which another + trusted IT product can request the TOE's TSF to + retransmit data when modification has been detected, or + respond to such types of request. + + The desired strength of modification detection is based + upon a specified modification metric that is a function of + the algorithm used, which may range from a weak checksum + and parity mechanisms that may fail to detect multiple bit + changes, to more complicated cryptographic checksum + approaches. + + + , provides the ability to detect + modification of TSF data during transmission between the + TSF and another trusted IT product, under the assumption + that another trusted IT product is cognisant of the mechanism used. + + + the detection of modification of transmitted TSF data. + + + the action taken upon detection of modification of + transmitted TSF data. + + + The TSF shall provide the capability to detect modification + of all TSF data during transmission between the TSF and + another trusted IT product within the following metric: + + a defined modification metric + + the PP/ST should specify the modification metric that + the detection mechanism must satisfy. This + modification metric shall specify the desired strength + of the modification detection.. + + + The TSF shall provide the capability to verify the integrity + of all TSF data transmitted between the TSF and another + trusted IT product and perform + + action to be taken + + the PP/ST should specify the actions to be taken if a + modification of TSF data has been detected. An example + of an action is: ``ignore the TSF data, and + request the originating trusted product to send the + TSF data again''. + if modifications are detected. + + + + + + + + This component should be used in situations where it is + necessary to detect or correct modifications of TSF + critical data. + + The desired strength of modification detection is based + upon a specified modification metric that is a function of + the algorithm used, which may range from a checksum and + parity mechanisms that may fail to detect multiple bit + changes, to more complicated cryptographic checksum + approaches. The metric that needs to be defined can either + refer to the attacks it will resist (e.g. only 1 in a 1000 + random messages will be accepted), or to mechanisms that + are well known in the public literature (e.g. the strength + must be conformant to the strength offered by Secure Hash + Algorithm). + + The approach taken to correct modification might be done + through some form of error correcting checksum. + + + + Some possible means of satisfying this requirement + involves the use of cryptographic functions or some form + of checksum. + + + , provides the ability for + another trusted IT product not only to detect modification, + but to correct modified TSF data under the assumption that + another trusted IT product is cognisant of the mechanism used. + + + management of the types of TSF data that the TSF should try + to correct if modified in transit; + + + management of the types of action that the TSF could take if + TSF data is modified in transit. + + + the detection of modification of transmitted TSF data; + + + the action taken upon detection of modification of + transmitted TSF data. + + + the use of the correction mechanism. + + + The TSF shall provide the capability to detect modification + of all TSF data during transmission between the TSF and + another trusted IT product within the following metric: + + a defined modification metric + + the PP/ST should specify the modification metric that + the detection mechanism must satisfy. This + modification metric shall specify the desired strength + of the modification detection.. + + + The TSF shall provide the capability to verify the integrity + of all TSF data transmitted between the TSF and another + trusted IT product and perform + + action to be taken + + the PP/ST should specify the actions to be taken if a + modification of TSF data has been detected. An example + of an action is: ``ignore the TSF data, and + request the originating trusted product to send the + TSF data again''. + if modifications are detected. + + + The TSF shall provide the capability to correct + + type of modification + + the PP/ST author should define the types of + modification from which the TSF should be capable of + recovering. + of all TSF data transmitted between the TSF and another + trusted IT product. + + + + + + + + This family provides requirements that address protection of + TSF data when it is transferred between separate parts of a + TOE across an internal channel. + + + + This family provides requirements that address protection of + TSF data when it is transferred between separate parts of a + TOE across an internal channel. + + The determination of the degree of separation (i.e., + physical or logical) that would make application of this + family useful depends on the intended environment of use. In + a hostile environment, there may be risks arising from + transfers between parts of the TOE separated by only a + system bus or an inter-process communications channel. In + more benign environments, the transfers may be across more + traditional network media. + + + + One practical mechanism available to a TSF to provide this + protection is cryptographically-based. + + + + + + , requires that TSF data be + protected when transmitted between separate parts of the + TOE. + + + management of the types of modification against which the + TSF should protect; + + + management of the mechanism used to provide the protection + of the data in transit between different parts of the TSF. + + + The TSF shall protect TSF data from + + + disclosure + + + modification + + + + the PP/ST author should specify the desired type of + protection to be provided from the choices: + disclosure, modification. + + + when it is transmitted between separate parts of the TOE. + + + + + + + + One of the ways to achieve separation of TSF data based on + SFP-relevant attributes is through the use of separate + logical or physical channels. + + + + , requires that the TSF separate + user data from TSF data during transmission. + + + management of the types of modification against which the + TSF should protect; + + + management of the mechanism used to provide the protection + of the data in transit between different parts of the TSF; + + + management of the separation mechanism. + + + The TSF shall protect TSF data from + + + disclosure + + + modification + + + + the PP/ST author should specify the desired type of + protection to be provided from the choices: + disclosure, modification. + + + when it is transmitted between separate parts of the TOE. + + + The TSF shall separate user data from TSF data when such + data is transmitted between separate parts of the TOE. + + + + + + + + + + , requires that the TSF data + transmitted between separate parts of the TOE is monitored + for identified integrity errors. + + + management of the types of modification against which the + TSF should protect; + + + management of the mechanism used to provide the protection + of the data in transit between different parts of the TSF; + + + management of the types of modification of TSF data the TSF + should try to detect; + + + management of the action>s that will be taken. + + + the detection of modification of TSF data; + + + the action taken following detection of an integrity error. + + + The TSF shall be able to detect + + + modification of data + + + substitution of data + + + re-ordering of data + + + deletion of data + + + + + other integrity errors + + + + if the PP/ST author chooses the latter selection + noted in the preceding paragraph, then the author + should also specify what those other integrity + errors are that the TSF should be capable of + detecting. + + + + + + the PP/ST author should specify the desired type of + modification that the TSF shall be able to detect. The + PP/ST author should select from: modification of data, + substitution of data, re-ordering of data, deletion of + data, or any other integrity errors. + + + for TSF data transmitted between separate parts of the TOE. + + + Upon detection of a data integrity error, the TSF shall take + the following actions: + + + specify the action to be taken + + + + the PP/ST author should specify the action to be taken + when an integrity error is identified. + + . + + + + + + + + TSF physical protection components refer to restrictions on + unauthorised physical access to the TSF, and to the + deterrence of, and resistance to, unauthorised physical + modification, or substitution of the TSF. + + The requirements of components in this family ensure that + the TSF is protected from physical tampering and + interference. Satisfying the requirements of these + components results in the TSF being packaged and used in + such a manner that physical tampering is detectable, or + resistance to physical tampering is enforced. Without these + components, the protection functions of a TSF lose their + effectiveness in environments where physical damage cannot + be prevented. This family also provides requirements + regarding how the TSF shall respond to physical tampering + attempts. + + + + TSF physical protection components refer to restrictions on + unauthorised physical access to the TSF, and to the + deterrence of, and resistance to, unauthorised physical + modification, or substitution of the TSF. + + The requirements in this family ensure that the TSF is + protected from physical tampering and + interference. Satisfying the requirements of these + components results in the TSF being packaged and used in + such a manner that physical tampering is detectable, or + resistance to physical tampering is measurable based on + defined work factors. Without these components, the + protection functions of a TSF lose their effectiveness in + environments where physical damage cannot be prevented. This + component also provides requirements regarding how the TSF + must respond to physical tampering attempts. + + Examples of physical tampering scenarios include mechanical + attack, radiation, changing the temperature. + + It is acceptable for the functions that are available to an + authorised user for detecting physical tampering to be + available only in an off-line or maintenance mode. Controls + should be in place to limit access during such modes to + authorised users. As the TSF may not be + ``operational'' during those modes, it + may not be able to provide normal enforcement for authorised + user access. The physical implementation of a TOE might + consist of several structures: for example an outer + shielding, cards, and chips. This set of + ``elements'' as a whole must protect + (protect, notify and resist) the TSF from physical + tampering. This does not mean that all devices must provide + these features, but the complete physical construct as a + whole should. + + Although there is only minimal auditing associating with + these components, this is solely because there is the + potential that the detection and alarm mechanisms may be + implemented completely in hardware, below the level of + interaction with an audit subsystem (for example, a + hardware-based detection system based on breaking a circuit + and lighting a light emitting diode (LED) if the circuit is + broken when a button is pressed by the authorised + user). Nevertheless, a PP/ST author may determine that for a + particular anticipated threat environment, there is a need + to audit physical tampering. If this is the case, the PP/ST + author should include appropriate requirements in the list + of audit events. Note that inclusion of these requirements + may have implications on the hardware design and its + interface to the software. + + + + + + should be used when threats from + unauthorised physical tampering with parts of the TOE are not + countered by procedural methods. It addresses the threat of + undetected physical tampering with the TSF. Typically, an + authorised user would be given the function to verify whether + tampering took place. As written, this component simply provides + a TSF capability to detect tampering. Specification of + management functions in should be + considered to specify who can make use of that capability, and + how they can make use of that capability. If this is done by non-IT mechanisms + (e.g. physical inspection) management functions are not required. + + + + , provides for features that + indicate when a TSF device or TSF element is subject to + tampering. However, notification of tampering is not + automatic; an authorised user must invoke a security + administrative function or perform manual inspection to + determining if tampering has occurred. + + management of the user or role that determines whether physical + tampering has occurred. + + + if detection by IT means, detection of intrusion. + + + The TSF shall provide unambiguous detection of physical + tampering that might compromise the TSF. + + + The TSF shall provide the capability to determine whether + physical tampering with the TSF's devices or + TSF's elements has occurred. + + + + + + + + + + should be used when threats from + unauthorised physical tampering with parts of the TOE are + not countered by procedural methods, and it is required + that designated individuals be notified of physical + tampering. It addresses the threat that physical tampering + with TSF elements, although detected, may not be noticed. + Specification of management functions in FMT_MOF.1 Management of + security functions behaviour should be considered to specify who + can make use of that capability, and how they can make use of that capability. + + + + , provides for automatic + notification of tampering for an identified subset of + physical penetrations. + + + management of the user or role that gets informed about + intrusions; + + + management of the list of devices that should inform the + indicated user or role about the intrusion. + + + detection of intrusion. + + + The TSF shall provide unambiguous detection of physical + tampering that might compromise the TSF. + + + The TSF shall provide the capability to determine whether physical + tampering with the TSF's devices or + TSF's elements has occurred. + + + For + + + list of TSF devices/elements for which active detection + is required + + + + the PP/ST author should provide a list of TSF + devices/elements for which active detection of + physical tampering is required. + + , the TSF shall monitor the devices and + elements and notify + + + a designated user or role + + + + the PP/ST author should designate a user or role that + is to be notified when tampering is detected. The type + of user or role may vary depending on the particular + security administration component (from the family) included in the PP/ST. + + + when physical tampering with the + TSF's devices or TSF's elements has + occurred. + + + + + + + For some forms of tampering, it is necessary that the TSF + not only detects the tampering, but actually resists it or + delays the attacker. + + This component should be used when TSF devices and TSF + elements are expected to operate in an environment where a + physical tampering (e.g. observation, analysis, or + modification) of the internals of a TSF device or TSF + element itself is a threat. + + + + , provides for features that prevent + or resist physical tampering with TSF devices and TSF + elements. + + + management of the automatic responses to physical tampering. + + + The TSF shall resist + + + physical tampering scenarios + + + + the PP/ST author should specify tampering scenarios to + a list of TSF devices/elements for which the TSF + should resist physical tampering. This list may be + applied to a defined subset of the TSF physical + devices and elements based on considerations such as + technology limitations and relative physical exposure + of the device. Such subsetting should be clearly + defined and justified. Furthermore, the TSF should + automatically respond to physical tampering. The + automatic response should be such that the policy of + the device is preserved; for example, with a + confidentiality policy, it would be acceptable to + physically disable the device so that the protected + information may not be retrieved. + + + to the + + + list of TSF devices/elements + + + + the PP/ST author should specify the list of TSF + devices/elements for which the TSF should resist + physical tampering in the scenarios that have been + identified. + + + by responding automatically such that the SFRs are always enforced. + + + + + + + + The requirements of this family ensure that the TSF can + determine that the TOE is started up without protection + compromise and can recover without protection compromise + after discontinuity of operations. This family is important + because the start-up state of the TSF determines the + protection of subsequent states. + + + + The requirements of this family ensure that the TSF can + determine that the TOE is started-up without protection + compromise and can recover without protection compromise + after discontinuity of operations. This family is important + because the start-up state of the TSF determines the + protection of subsequent states. + + Recovery components reconstruct the TSF secure states, or + prevent transitions to insecure states, as a direct response + to occurrences of expected failures, discontinuity of + operation or start-up. Failures that must be generally + anticipated include the following: + + + Unmaskable action failures that always result in a + system crash (e.g. persistent inconsistency of critical + system tables, uncontrolled transfers within the TSF + code caused by transient failures of hardware or + firmware, power failures, processor failures, + communication failures). + + + Media failures causing part or all of the media + representing the TSF objects to become inaccessible or + corrupt (e.g. parity errors, disk head crash, persistent + read/write failure caused by misaligned disk heads, + worn-out magnetic coating, dust on the disk surface). + + + Discontinuity of operation caused by erroneous + administrative action or lack of timely administrative + action (e.g. unexpected shutdowns by turning off power, + ignoring the exhaustion of critical resources, + inadequate installed configuration). + + + + Note that recovery may be from either a complete or partial + failure scenario. Although a complete failure might occur in + a monolithic operating system, it is less likely to occur in + a distributed environment. In such environments, subsystems + may fail, but other portions remain operational. Further, + critical components may be redundant (disk mirroring, + alternative routes), and checkpoints may be available. Thus, + recovery is expressed in terms of recovery to a secure + state. + There are different interactions between + and components to be considered when + selecting : + + The need for trusted recovery may be indicated through + the results of TSF self-testing, where the results of + the self-tests indicate that the TSF is in an insecure + state and return to a secure state or entrance in + maintenance mode is required. + + A failure, as discussed above, may be identified by an + administrator. Either the administrator may perform + the actions to return the TOE to a secure state and + then invoke TSF self-tests to confirm that the secure + state has been achieved. Or, the TSF self-tests may be + invoked to complete the recovery process. + + A combination of a. and b. above, where the need for + trusted recovery is indicated through the results of + TSF self-testing, the administrator performs the + actions to return the TOE to a secure state and then + invokes TSF self-tests to confirm that the secure + state has been achieved. + + Self tests detect a failure/service discontinuity, + then either automated recovery or entrance to a + maintenance mode. + + + This family identifies a maintenance mode. In this + maintenance mode normal operation might be impossible or + severely restricted, as otherwise insecure situations might + occur. Typically, only authorised users should be allowed + access to this mode but the real details of who can access + this mode is a function of . If does not put any controls on who can access this + mode, then it may be acceptable to allow any user to restore + the system if the TOE enters such a state. However, in + practice, this is probably not desirable as the user + restoring the system has an opportunity to configure the TOE + in such a way as to violate the SFRs. + + Mechanisms designed to detect exceptional conditions during + operation fall under , , and other areas that address the + concept of ``Software Safety.'' It is likely that the use of + one of these families will be required to support the adoption + of . This is to ensure that + the TOE will be able to detect when recovery is + required. + + Throughout this family, the phrase ``secure state'' is + used. This refers to some state in which the TOE has + consistent TSF data and a TSF that can correctly enforce the + policy. This state may be the initial ``boot'' of a clean + system, or it might be some checkpointed state. + + Following recovery, it may be necessary to confirm that the + secure state has been achieved through self-testing of the + TSF. However, if the recovery is performed in a manner such + that only a secure state can be achieved, else recovery + fails, then the dependency to the TSF + self-test component may be argued away. + + + + + + + + + In the hierarchy of the trusted recovery family, recovery + that requires only manual intervention is the least + desirable, for it precludes the use of the system in an + unattended fashion. + + This component is intended for use in TOEs that do not + require unattended recovery to a secure state. The + requirements of this component reduce the threat of + protection compromise resulting from an attended TOE + returning to an insecure state after recovery from a + failure or other discontinuity. + + + + It is acceptable for the functions that are available to + an authorised user for trusted recovery to be available + only in a maintenance mode. Controls should be in place to + limit access during maintenance to authorised users. + + + + , allows a TOE to only provide + mechanisms that involve human intervention to return to a + secure state. + + + management of who can access the restore capability within + the maintenance mode. + + + the fact that a failure or service discontinuity occurred; + + + resumption of the regular operation; + + + type of failure or service discontinuity. + + + After + + list of failures/service discontinuities + + the PP/ST author should specify the list of failures or + service discontinuities (e.g. power failure, audit + storage exhaustion, any failure or discontinuity) + following which the TOE will enter a maintenance mode. the TSF shall enter a maintenance mode where + the ability to return to a secure state is provided. + + + + + + + + + + + Automated recovery is considered to be more useful than + manual recovery, as it allows the machine to operate in an + unattended fashion. + + The component extends the feature + coverage of by requiring that there + be at least one automated method of recovery from failure + or service discontinuity. It addresses the threat of + protection compromise resulting from an unattended TOE + returning to an insecure state after recovery from a + failure or other discontinuity. + + + + It is acceptable for the functions that are available to + an authorised user for trusted recovery to be available + only in a maintenance mode. Controls should be in place to + limit access during maintenance to authorised users. + + For , it is the responsibility of + the developer of the TSF to determine the set of + recoverable failures and service discontinuities. + + It is assumed that the robustness of the automated + recovery mechanisms will be verified. + + + + , provides, for at least one type of + service discontinuity, recovery to a secure state without + human intervention; recovery for other discontinuities may + require human intervention. + + + management of who can access the restore capability within + the maintenance mode; + + + management of the list of failures/service discontinuities + that will be handled through the automatic procedures. + + + + + When automated recovery from + + list of failures/service discontinuities + + the PP/ST author should specify the list of failures or + service discontinuities (e.g. power failure, audit + storage exhaustion) following which the TOE will need to + enter a maintenance mode. is not possible, the TSF shall enter a + maintenance mode where the ability to return to a secure state + is provided. + + + For + + + list of failures/service discontinuities + + + + the PP/ST author should specify the list of failures + or other discontinuities for which automated recovery + must be possible. + + , the TSF shall ensure the return of the TOE + to a secure state using automated procedures. + + + + + + + + + + + Automated recovery is considered to be more useful than + manual recovery, but it runs the risk of losing a + substantial number of objects. Preventing undue loss of + objects provides additional utility to the recovery + effort. + + The component extends the feature + coverage of by requiring that there + not be undue loss of TSF data or objects under the control + of the TSF. At , the automated recovery + mechanisms could conceivably recover by deleting all + objects and returning the TSF to a known secure + state. This type of drastic automated recovery is + precluded in . + + This component addresses the threat of protection + compromise resulting from an unattended TOE returning to + an insecure state after recovery from a failure or other + discontinuity with a large loss of TSF data or objects + under the control of the TSF. + + + + It is acceptable for the functions that are available to + an authorised user for trusted recovery to be available + only in a maintenance mode. Controls should be in place to + limit access during maintenance to authorised users. + + It is assumed that the evaluators will verify the + robustness of the automated recovery mechanisms. + + + + , also provides for automated + recovery, but strengthens the requirements by disallowing + undue loss of protected objects. + + + + + + When automated recovery from + + list of failures/service discontinuities + + the PP/ST author should specify the list of failures or + service discontinuities (e.g. power failure, audit + storage exhaustion) following which the TOE will need to + enter a maintenance mode. + is not possible, the TSF shall enter a maintenance mode where + the ability to return to a secure state is provided. + + + For + + + list of failures/service discontinuities + + + + the PP/ST author should specify the list of failures + or other discontinuities for which automated recovery + must be possible. + + , the TSF shall ensure the return of the TOE + to a secure state using automated procedures. + + + The functions provided by the TSF to recover from failure or + service discontinuity shall ensure that the secure initial + state is restored without exceeding + + + quantification + + + + the PP/ST author should provide a quantification for + the amount of loss of TSF data or objects that is + acceptable. + + + for loss of TSF data or objects under the control of the TSF. + + + The TSF shall provide the capability to determine the + objects that were or were not capable of being recovered. + + + + + + + Function recovery requires that if there should be some + failure in the TSF, that certain functions in the TSF should + either complete successfully or recover to a secure state. + + + + , provides for recovery at the level + of particular functions, ensuring either successful completion + or rollback of TSF data to a secure state. + + + if possible, the impossibility to return to a secure state + after a failure of the TSF; + + + if possible, the detection of a failure of a function. + + + The TSF shall ensure that + + + list of functions and failure scenarios + + + + the PP/ST author should specify a list the functions and + failure scenarios. In the event that any of the + identified failure scenarios happen, the functions that have + been specified must either complete successfully or + recover to a consistent and secure state. + + + have the property that the function either completes successfully, + or for the indicated failure scenarios, recovers to a + consistent and secure state. + + + + + + + + This family addresses detection of replay for various types + of entities (e.g. messages, service requests, service + responses) and subsequent actions to correct. In the case + where replay may be detected, this effectively prevents it. + + + + This family addresses detection of replay for various types + of entities and subsequent actions to correct. + + + + + + The entities included here are, for example, messages, + service requests, service responses, or sessions. + + + + The family consists of only one component, , which requires that the TSF shall be + able to detect the replay of identified entities. + + + management of the list of identified entities for which + replay shall be detected; + + + management of the list of actions that need to be taken in + case of replay. + + + Detected replay attacks. + + + Action to be taken based on the specific actions. + + + The TSF shall detect replay for the following entities: + + + list of identified entities + + + + the PP/ST author should provide a list of identified + entities for which detection of replay should be + possible. Examples of such entities might include: + messages, service requests, service responses, and + user sessions. + + . + + + The TSF shall perform + + + list of specific actions + + + + the PP/ST author should specify the list of actions to + be taken by the TSF when replay is detected. The + potential set of actions that can be taken includes: + ignoring the replayed entity, requesting confirmation + of the entity from the identified source, and + terminating the subject from which the re-played + entity originated. + + + when replay is detected. + + + + + + + + + Distributed TOEs may give rise to greater complexity than + monolithic TOEs through the potential for differences in + state between parts of the TOE, and through delays in + communication. In most cases synchronisation of state + between distributed functions involves an exchange protocol, + not a simple action. When malice exists in the distributed + environment of these protocols, more complex defensive + protocols are required. + + establishes the requirement for certain + critical functions of the TSF to use this trusted + protocol. ensures that two distributed + parts of the TOE (e.g. hosts) have synchronised their states + after a security-relevant action. + + + + Distributed TOEs may give rise to greater complexity than + monolithic TOEs through the potential for differences in + state between parts of the TOE, and through delays in + communication. In most cases, synchronisation of state + between distributed functions involves an exchange protocol, + not a simple action. When malice exists in the distributed + environment of these protocols, more complex defensive + protocols are required. + + establishes the requirement for certain + critical functions of the TSF to use a trusted + protocol. ensures that two distributed + parts of the TOE (e.g. hosts) have synchronised their states + after a security-relevant action. + + Some states may never be synchronised, or the transaction + cost may be too high for practical use; encryption key + revocation is an example, where knowing the state after the + revocation action is initiated can never be known. Either + the action was taken and acknowledgment cannot be sent, or + the message was ignored by hostile communication partners + and the revocation never occurred. Indeterminacy is unique + to distributed TOEs. Indeterminacy and state synchrony + are related, and the same solution may apply. It is futile + to design for indeterminate states; the PP/ST author should + express other requirements in such cases (e.g. raise an + alarm, audit the event). + + + + + + + + + In this component, the TSF must supply an acknowledgement + to another part of the TSF when requested. This + acknowledgement should indicate that one part of a + distributed TOE successfully received an unmodified + transmission from a different part of the distributed TOE. + + + + , requires only a simple + acknowledgment by the data recipient. + + + failure to receive an acknowledgement when expected. + + + The TSF shall acknowledge, when requested by another part of + the TSF, the receipt of an unmodified TSF data transmission. + + + + + + + + + + + In this component, in addition to the TSF being able to + provide an acknowledgement for the receipt of a data + transmission, the TSF must comply with a request from + another part of the TSF for an acknowledgement to the + acknowledgement. + + For example, the local TSF transmits some data to a remote + part of the TSF. The remote part of the TSF acknowledges + the successful receipt of the data and requests that the + sending TSF confirm that it receives the + acknowledgement. This mechanism provides additional + confidence that both parts of the TSF involved in the data + transmission know that the transmission completed + successfully. + + + + , requires mutual acknowledgment of + the data exchange. + + + + The TSF shall acknowledge, when requested by another part of + the TSF, the receipt of an unmodified TSF data + transmission. + + + The TSF shall ensure that the relevant parts of the TSF know + the correct status of transmitted data among its different + parts, using acknowledgements. + + + + + + + + This family addresses requirements for a reliable time stamp + function within a TOE. + + + + This family addresses requirements for a reliable time stamp + function within a TOE. + + It is the responsibility of the PP/ST author to clarify the + meaning of the phrase ``reliable time + stamp'', and to indicate where the responsibility + lies in determining the acceptance of trust. + + + + + + Some possible uses of this component include providing + reliable time stamps for the purposes of audit as well as + for security attribute expiration. + + + + This family consists of only one component, , which requires that the TSF provide + reliable time stamps for TSF functions. + + + management of the time. + + + changes to the time; + + + providing a timestamp. + + + The TSF shall be able to provide reliable time stamps. + + + + + + + + In a distributed environment, a TOE may + need to exchange TSF data (e.g. the SFP-attributes + associated with data, audit information, identification + information) with another trusted IT product, This family + defines the requirements for sharing and consistent + interpretation of these attributes between the TSF of the + TOE and a different trusted IT product. + + + + In a distributed or composite environment, a TOE may + need to exchange TSF data (e.g. the SFP-attributes + associated with data, audit information, identification + information) with another trusted IT Product, This family + defines the requirements for sharing and consistent + interpretation of these attributes between the TSF of the + TOE and that of a different trusted IT Product. + + The components in this family are intended to provide + requirements for automated support for TSF data consistency + when such data is transmitted between the TSF of the TOE and + another trusted IT Product. It is also possible that wholly + procedural means could be used to produce security attribute + consistency, but they are not provided for here. + + This family is different from FDP_ETC and FDP_ITC, as those + two families are concerned only with resolving the security + attributes between the TSF and its import/export medium. + + If the integrity of the TSF data is of concern, requirements + should be chosen from the family. These + components specify requirements for the TSF to be able to + detect or detect and correct modifications to TSF data in + transit. + + + + + + The TSF is responsible for maintaining the consistency of + TSF data used by or associated with the specified function + and that are common between two or more trusted + systems. For example, the TSF data of two different + systems may have different conventions internally. For the + TSF data to be used properly (e.g. to afford the user data + the same protection as within the TOE) by the receiving + trusted IT product, the TOE and the other trusted IT + product must use a pre-established protocol to exchange + TSF data. + + + + , requires that the TSF provide the + capability to ensure consistency of attributes between + TSFs. + + + Successful use of TSF data consistency mechanisms. + + + Use of the TSF data consistency mechanisms. + + + Identification of which TSF data have been interpreted. + + + Detection of modified TSF data. + + + The TSF shall provide the capability to consistently + interpret + + + list of TSF data types + + + + the PP/ST author should define the list of TSF data + types, for which the TSF shall provide the capability + to consistently interpret, when shared between the TSF + and another trusted IT product. + + + when shared between the TSF and another trusted IT product. + + + The TSF shall use + + + list of interpretation rules to be applied by the TSF + + + + the PP/ST should assign the list of interpretation + rules to be applied by the TSF, + + + when interpreting the TSF data from another trusted IT + product. + + + + This family defines requirements for the TSF to perform tests + on one or more external entities. + This component is not intended to be applied to human users. + External entities may include applications running on the TOE, hardware or + software running ``underneath'' the TOE (platforms, operating systems etc.) + or applications/boxes connected to the TOE (intrusion detection systems, + firewalls, login servers, time servers etc.). + This family defines requirements for the testing of one or more external + entities by the TSF. These external entities are not human users, and they can + include combinations of software and/or hardware interacting with the TOE. + Examples of the types of tests that may be run are: + + Tests for the presence of a firewall, and possibly whether it is + correctly configured; + + Tests of some of the properties of the operating system that an + application TOE runs on; + + Tests of some of the properties of the IC that a smart card OS TOE + runs on (e.g. the random number generator). + + Note that the external entity may ``lie'' about the test results, either on + purpose or because it is not working correctly. + These tests can be carried out either in some maintenance state, at start-up, + on-line, or continuously. The actions to be taken by the TOE as the result of + testing are defined also in this family. + The tests of external entities should be sufficient to test all of the + characteristics of them upon which the TSF relies. + This component is not intended to be applied to human users. + This component provides support for the periodic testing of properties + related to external entities upon which the TSF's operation depends, by + requiring the ability to periodically invoke testing functions. + The PP/ST author may refine the requirement to state whether the function + should be available in off-line, on-line or maintenance mode. + It is acceptable for the functions for periodic testing to be available only in + an off-line or maintenance mode. Controls should be in place to limit access, + during maintenance, to authorised users., provides for testing of the + external entities by the TSF. + management of the conditions under which the testing of external + entities occurs, such as during initial start-up, regular interval, or + under specified conditions; + + management of the time interval if appropriate. + + Execution of the tests of the external entities and the results of + the tests. + + The TSF shall run a suite of tests + + during initial start-up + + periodically during normal operation + + at the request of an authorised user + + other conditions + + the PP/ST author should, if other conditions are + selected, specify the frequency with which the testing of external entities will be run. + An example of this other frecuency or condition may be to run the + tests each time a user requests to initiate a session with the TOE. For + instance, this could be the case of testing a directory server before its + interaction with the TSF during the user authentication process. + the PP/ST author should specify when the TSF will + run the testing of external entities, during initial start-up, periodically + during normal operation, at the request of an authorised user, or under + other conditions. If the tests are run often, then the end users should + have more confidence that the TOE is operating correctly than if the + tests are run less frequently. However, this need for confidence that + the TOE is operating correctly must be balanced with the potential + impact on the availability of the TOE, as often times, the testing of external entities may + delay the normal operation of a TOE. + to check the fulfillment of + + list of properties of the external entities + + the PP/ST author should specify the properties of the + external entities to be checked by the tests. Examples of these + properties may include configuration or availability properties of + a directory server supporting some access control part of the TSF. + . + + If the test fails, the TSF shall + + action(s) + + the PP/ST author should specify what are the action(s) + that the TSF shall perform when the testing fails. Examples of these + action(s), illustrated by a directory server instance, may include to + connect to an alternative available server or otherwise to look for a + backup server. + . + + + + + + The requirements of this family are needed to ensure the + consistency of TSF data when such data is replicated + internal to the TOE. Such data may become inconsistent if + the internal channel between parts of the TOE becomes + inoperative. If the TOE is internally structured as a + network and parts of the TOE network connections are broken, + this may occur when parts become disabled. + + + + The requirements of this family are needed to ensure the + consistency of TSF data when such data is replicated + internal to the TOE. Such data may become inconsistent if an + internal channel between parts of the TOE becomes + inoperative. If the TOE is internally structured as a + network of parts of the TOE, this can occur when parts + become disabled, network connections are broken, and so on. + + The method of ensuring consistency is not specified in this + component. It could be attained through a form of + transaction logging (where appropriate transactions are + ``rolled back'' to a site upon + reconnection); it could be updating the replicated data + through a synchronisation protocol. If a particular protocol + is necessary for a PP/ST, it can be specified through + refinement. + + It may be impossible to synchronise some states, or the cost + of such synchronisation may be too high. Examples of this + situation are communication channel and encryption key + revocations. Indeterminate states may also occur; if a + specific behaviour is desired, it should be specified via + refinement. + + + + + + + + + This family consists of only one component, , which requires that the TSF ensure the + consistency of TSF data that is replicated in multiple + locations. + + + restoring consistency upon reconnection. + + + Detected inconsistency between TSF data. + + + The TSF shall ensure that TSF data is consistent when + replicated between parts of the TOE. + + + When parts of the TOE containing replicated TSF data are + disconnected, the TSF shall ensure the consistency of the + replicated TSF data upon reconnection before processing any + requests for + + + list of functions dependent on TSF data replication + consistency + + + + the PP/ST author should specify the list of functions + dependent on TSF data replication consistency. + + . + + + + + + + + The family defines the requirements for the self-testing of + the TSF with respect to some expected correct + operation. Examples are interfaces to enforcement functions, + and sample arithmetical operations on critical parts of the + TOE. These tests can be carried out at start-up, + periodically, at the request of the authorised user, or when + other conditions are met. The actions to be taken by the TOE + as the result of self testing are defined in other families. + + The requirements of this family are also needed to detect + the corruption of TSF data and TSF itself (i.e. TSF executable code or + TSF hardware component) by various failures that do not necessarily + stop the TOE's operation (which would be handled by other + families). These checks must be performed because these + failures may not necessarily be prevented. Such failures can + occur either because of unforeseen failure modes or + associated oversights in the design of hardware, firmware, + or software, or because of malicious corruption of the TSF + due to inadequate logical and/or physical protection. + + + + The family defines the requirements for the self-testing of + the TSF with respect to some expected correct + operation. Examples are interfaces to enforcement functions, + and sample arithmetical operations on critical parts of the + TOE. These tests can be carried out at start-up, + periodically, at the request of an authorised user, or when + other conditions are met. The actions to be taken by the TOE + as the result of self testing are defined in other families. + + The requirements of this family are also needed to detect + the corruption of TSF data and TSF itself (i.e. TSF executable code or + TSF hardware component) by various failures that do not necessarily + stop the TOE's operation (which would be handled by other + families). These checks must be performed because these + failures may not necessarily be prevented. Such failures can + occur either because of unforeseen failure modes or + associated oversights in the design of hardware, firmware, + or software, or because of malicious corruption of the TSF + due to inadequate logical and/or physical protection. + + In addition, use of this component may, with appropriate + conditions, help to prevent inappropriate or damaging TSF + changes being applied to an operational TOE as the result of + maintenance activities. + + The term ``correct operation of the TSF'' refers primarily to + the operation of the TSF and the integrity of the TSF data. + + + + + + + This component provides support for the testing of the + critical functions of the TSF's operation by + requiring the ability to invoke testing functions and + check the integrity of TSF data and executable code. + + + + It is acceptable for the functions that are available to + the authorised user for periodic testing to be available + only in an off-line or maintenance mode. Controls should + be in place to limit access during these modes to + authorised users. + + + , provides the ability to test the + TSF's correct operation. These tests may be + performed at start-up, periodically, at the request of the + authorised user, or when other conditions are met. It also + provides the ability to verify the integrity of TSF data + and TSF itself. + + + management of the conditions under which TSF self testing + occurs, such as during initial start-up, regular interval, + or under specified conditions; + + + management of the time interval if appropriate. + + + Execution of the TSF self tests and the results of the + tests. + + + The TSF shall run a suite of self tests + + during initial start-up + + periodically during normal operation + + at the request of the authorised user + + at the conditions + + conditions under which self test should occur + + the PP/ST author should, if selected, specify the + conditions under which the self test should take + place. + the PP/ST author should specify when the TSF will execute + the TSF test; during initial start-up, periodically during + normal operation, at the request of an authorised user, at + other conditions. In the case of the latter option, the + PP/ST author should also assign what those conditions are + via the following assignment. + to demonstrate the correct operation of + + parts of TSF + + the PP/ST author should, if selected, specify the + list of parts of the TSF that will be subject to TSF + self-testing. + the TSF + + the PP/ST author should specify whether the self tests + are to be carried out to demonstrate the correct + operation of the entire TSF, or of only specified parts + of TSF.. + + + The TSF shall provide authorised users with the capability to + verify the integrity of + + parts of TSF data + + the PP/ST author should, if selected, specify the + list of TSF data that will be verified for + integrity. + TSF data + + the PP/ST author should specify whether data integrity + is to be verified for all TSF data, or only for selected + data.. + + + The TSF shall provide authorised users with the capability to + verify the integrity of + + parts of TSF + + the PP/ST author should, if selected, specify the + list of TSF that will be verified for + integrity. + TSF + + the PP/ST author should specify whether TSF integrity + is to be verified for all TSF, or only for selected + TSF.. + + + + + + + + This class provides three families that support the + availability of required resources such as processing + capability and/or storage capacity. The family Fault Tolerance + provides protection against unavailability of capabilities + caused by failure of the TOE. The family Priority of Service + ensures that the resources will be allocated to the more + important or time-critical tasks and cannot be monopolised by + lower priority tasks. The family Resource Allocation provides + limits on the use of available resources, therefore preventing + users from monopolising the resources. + + + + This class provides three families that support the + availability of required resources such as processing + capability and/or storage capacity. The family Fault Tolerance + provides protection against unavailability of capabilities + caused by failure of the TOE. The family Priority of Service + ensures that the resources will be allocated to the more + important or time-critical tasks, and cannot be monopolised by + lower priority tasks. The family Resource Allocation provides + limits on the use of available resources, therefore preventing + users from monopolising the resources. + + + + + + The requirements of this family ensure that the TOE will + maintain correct operation even in the event of failures. + + + + This family provides requirements for the availability of + capabilities even in the case of failures. Examples of such + failures are power failure, hardware failure, or software + error. In case of these errors, if so specified, the TOE + will maintain the specified capabilities. The PP/ST author + could specify, for example, that a TOE used in a nuclear + plant will continue the operation of the shut-down procedure + in the case of power-failure or communication-failure. + + Because the TOE can only continue its correct operation if + the SFRs are enforced, there is a requirement that the system + must remain in a secure state after a failure. This + capability is provided by . + + The mechanisms to provide fault tolerance could be active or + passive. In case of an active mechanism, specific functions + are in place that are activated in case the error + occurs. For example, a fire alarm is an active mechanism: + the TSF will detect the fire and can take action such as + switching operation to a backup. In a passive scheme, the + architecture of the TOE is capable of handling the + error. For example, the use of a majority voting scheme with + multiple processors is a passive solution; failure of one + processor will not disrupt the operation of the TOE + (although it needs to be detected to allow correction). + + For this family, it does not matter whether the failure has + been initiated accidentally (such as flooding or unplugging + the wrong device) or intentionally (such as monopolising). + + + + + + + + + This component is intended to specify which capabilities + the TOE will still provide after a failure of the + system. Since it would be difficult to describe all + specific failures, categories of failures may be + specified. Examples of general failures are flooding of + the computer room, short term power interruption, + breakdown of a CPU or host, software failure, or buffer + overflow. + + + + , requires the TOE to continue + correct operation of identified capabilities in the event + of identified failures. + + + Any failure detected by the TSF. + + + All TOE capabilities being discontinued due to a failure. + + + The TSF shall ensure the operation of + + + list of TOE capabilities + + + + the PP/ST author should specify the list of TOE + capabilities the TOE will maintain during and after a + specified failure. + + + when the following failures occur: + + + list of type of failures + + + + the PP/ST author should specify the list of type of + failures against which the TOE has to be explicitly + protected. If a failure in this list occurs, the TOE + will be able to continue its operation. + + . + + + + + + + + + + + This component is intended to specify against what type of + failures the TOE must be resistant. Since it would be + difficult to describe all specific failures, categories of + failures may be specified. Examples of general failures + are flooding of the computer room, short term power + interruption, breakdown of a CPU or host, software + failure, or overflow of buffer. + + + + , requires the TOE to continue + correct operation of all capabilities in the event of + identified failures. + + + Any failure detected by the TSF. + + + The TSF shall ensure the operation of all the + TOE's capabilities when the following failures + occur: + + + list of type of failures + + + + the PP/ST author should specify the list of type of + failures against which the TOE has to be explicitly + protected. If a failure in this list occurs, the TOE + will be able to continue its operation. + + . + + + + + + + + The requirements of this family allow the TSF to control the + use of resources under the control of the TSF by users and subjects such + that high priority activities under the control of the TSF will always be + accomplished without undue interference or delay caused by + low priority activities. + + + + The requirements of this family allow the TSF to control the + use of resources under the control of the TSF by users and subjects such + that high priority activities under the control of the TSF will always be + accomplished without interference or delay due to low + priority activities. In other words, time critical tasks + will not be delayed by tasks that are less time critical. + + This family could be applicable to several types of + resources, for example, processing capacity, and + communication channel capacity. + + The Priority of Service mechanism might be passive or + active. In a passive Priority of Service system, the system + will select the task with the highest priority when given a + choice between two waiting applications. While using passive + Priority of Service mechanisms, when a low priority task is + running, it cannot be interrupted by a high priority + task. While using an active Priority of Service mechanisms, + lower priority tasks might be interrupted by new high + priority tasks. + + The audit requirement states that all reasons for rejection + should be audited. It is left to the developer to argue that + an operation is not rejected but delayed. + + + + + + This component defines priorities for a subject, and the + resources for which this priority will be used. If a + subject attempts to take action on a resource controlled + by the Priority of Service requirements, the access and/or + time of access will be dependent on the subject's + priority, the priority of the currently acting subject, + and the priority of the subjects still in the queue. + + + + , provides priorities for a + subject's use of a subset of the resources + under the control of the TSF. + + + assignment of priorities to each subject in the TSF. + + + Rejection of operation based on the use of priority within + an allocation. + + + All attempted uses of the allocation function which involves + the priority of the service functions. + + + The TSF shall assign a priority to each subject in the TSF. + + + The TSF shall ensure that each access to + + + controlled resources + + + + the PP/ST author should specify the list of controlled + resources for which the TSF enforces priority of service + (e.g. resources such as processes, disk space, memory, + bandwidth). + + + shall be mediated on the basis of the subjects assigned + priority. + + + + + + + + This component defines priorities for a subject. All + shareable resources under the control of the TSF will be subjected to the + Priority of Service mechanism. If a subject attempts to + take action on a shareable TSF resource, the access and/or + time of access will be dependent on the subject's + priority, the priority of the currently acting subject, + and the priority of the subjects still in the queue. + + + + , provides priorities for a + subject's use of all of the resources under the control of the TSF. + + + + + + The TSF shall assign a priority to each subject in the TSF. + + + The TSF shall ensure that each access to all shareable + resources shall be mediated on the basis of the subjects + assigned priority. + + + + + + + + The requirements of this family allow the TSF to control the + use of resources by users and subjects such that denial of + service will not occur because of unauthorised + monopolisation of resources. + + + + The requirements of this family allow the TSF to control the + use of resources under the control of the TSF by users and subjects such + that unauthorised denial of service will not take place by + means of monopolisation of resources by other users or + subjects. + + Resource allocation rules allow the creation of quotas or + other means of defining limits on the amount of resource + space or time that may be allocated on behalf of a specific + user or subjects. These rules may, for example: + + + Provide for object quotas that constrain the number + and/or size of objects a specific user may allocate. + + + Control the allocation/deallocation of preassigned + resource units where these units are under the control + of the TSF. + + + + In general, these functions will be implemented through the + use of attributes assigned to users and resources. + + The objective of these components is to ensure a certain + amount of fairness among the users (e.g. a single user + should not allocate all the available space) and + subjects. Since resource allocation often goes beyond the + lifespan of a subject (i.e. files often exist longer than + the applications that generated them), and multiple + instantiations of subjects by the same user should not + negatively affect other users too much, the components allow + that the allocation limits are related to the users. In some + situations the resources are allocated by a subject + (e.g. main memory or CPU cycles). In those instances the + components allow that the resource allocation be on the + level of subjects. + + This family imposes requirements on resource allocation, not + on the use of the resource itself. The audit requirements + therefore, as stated, also apply to the allocation of the + resource, not to the use of the resource. + + + + + + This component provides requirements for quota mechanisms + that apply to only a specified set of the shareable + resources in the TOE. The requirements allow the quotas to + be associated with a user, possibly assigned to groups of + users or subjects as applicable to the TOE. + + + + , provides requirements for quota + mechanisms that ensure that users and subjects will not + monopolise a controlled resource. + + + specifying maximum limits for a resource for groups and/or + individual users and/or subjects by an administrator. + + + Rejection of allocation operation due to resource limits. + + + All attempted uses of the resource allocation functions for + resources that are under control of the TSF. + + + The TSF shall enforce maximum quotas of the following + resources: + + + controlled resources + + + + the PP/ST author should specify the list of controlled + resources for which maximum resource allocation limits + are required (e.g. processes, disk space, memory, + bandwidth). If all resources under the control of the TSF need to be + included, the words ``all TSF + resources'' can be specified. + + + that + + + individual user + + + defined group of users + + + subjects + + + + the PP/ST author should select whether the maximum + quotas apply to individual users, to a defined group + of users, or subjects or any combination of these. + + + can use + + + simultaneously + + + over a specified period of time + + + + the PP/ST author should select whether the maximum + quotas are applicable to any given time + (simultaneously), or over a specific time interval. + + . + + + + + + + + This component provides requirements for quota mechanisms + that apply to a specified set of the shareable resources + in the TOE. The requirements allow the quotas to be + associated with a user, or possibly assigned to groups of + users as applicable to the TOE. + + + + , provides requirements for quota + mechanisms that ensure that users and subjects will always + have at least a minimum of a specified resource and that + they will not be able to monopolise a controlled resource. + + + specifying minimum and maximum limits for a resource for + groups and/or individual users and/or subjects by an + administrator. + + + + + The TSF shall enforce maximum quotas of the following + resources + + + controlled resources + + + + the PP/ST author should specify the controlled + resources for which maximum and minimum resource + allocation limits are required (e.g. processes, disk + space, memory, bandwidth). If all resources under the control of the TSF + need to be included, the words ``all TSF + resources'' can be specified. + + + that + + + individual user + + + defined group of users + + + subjects + + + + the PP/ST author should select whether the maximum + quotas apply to individual users, to a defined group + of users, or subjects or any combination of these. + + + can use + + + simultaneously + + + over a specified period of time + + + + the PP/ST author should select whether the maximum + quotas are applicable to any given time + (simultaneously), or over a specific time interval. + + . + + + The TSF shall ensure the provision of minimum quantity of + each + + + controlled resource + + + + the PP/ST author should specify the controlled + resources for which a minimum allocation limit needs + to be set (e.g. processes, disk space, memory, + bandwidth). If all resources under the control of the TSF need to be + included the words ``all TSF resources'' + can be specified. + + + that is available for + + + an individual user + + + defined group of users + + + subjects + + + + the PP/ST author should select whether the minimum + quotas apply to individual users, to a defined group + of users, or subjects or any combination of these. + + + to use + + + simultaneously + + + over a specified period of time + + + + the PP/ST author should select whether the minimum + quotas are applicable to any given time + (simultaneously), or over a specific time interval. + + . + + + + + + + + This family specifies functional requirements for controlling + the establishment of a user's session. + + + + The establishment of a user's session typically + consists of the creation of one or more subjects that perform + operations in the TOE on behalf of the user. At the end of the + session establishment procedure, provided the TOE access + requirements are satisfied, the created subjects bear the + attributes determined by the identification and authentication + functions. This family specifies functional requirements for + controlling the establishment of a user's session. + + A user session is defined as the period starting at the time + of the identification/authentication, or if more appropriate, + the start of an interaction between the user and the system, + up to the moment that all subjects (resources and attributes) + related to that session have been deallocated. + + + + + + This family defines requirements to limit the scope of + session security attributes that a user may select for a + session. + + + + This family defines requirements that will limit the session + security attributes a user may select, and the subjects to + which a user may be bound, based on: the method of access; + the location or port of access; and/or the time + (e.g. time-of-day, day-of-week). + + This family provides the capability for a PP/ST author to + specify requirements for the TSF to place limits on the + domain of an authorised user's security attributes + based on an environmental condition. For example, a user may + be allowed to establish a ``secret session'' + during normal business hours but outside those hours the + same user may be constrained to only establishing + ``unclassified sessions''. The identification of + relevant constraints on the domain of selectable attributes + can be achieved through the use of the selection + operation. These constraints can be applied on an + attribute-by-attribute basis. When there exists a need to + specify constraints on multiple attributes this component + will have to be replicated for each attribute. Examples of + attributes that could be used to limit the session security + attributes are: + + + The method of access can be used to specify in which + type of environment the user will be operating + (e.g. file transfer protocol, terminal, vtam). + + + The location of access can be used to constrain the + domain of a user's selectable attributes based + on a user's location or port of access. This + capability is of particular use in environments where + dial-up facilities or network facilities are available. + + + The time of access can be used to constrain the domain + of a user's selectable attributes. For example, + ranges may be based upon time-of-day, day-of-week, or + calendar dates. This constraint provides some + operational protection against user actions that could + occur at a time where proper monitoring or where proper + procedural measures may not be in place. + + + + + + + + , provides the requirement for a TOE + to limit the scope of the session security attributes + during session establishment. + + + management of the scope of the session security attributes + by an administrator. + + + All failed attempts at selecting a session security + attributes; + + + All attempts at selecting a session security attributes; + + + Capture of the values of each session security attributes. + + + The TSF shall restrict the scope of the session security + attributes + + + session security attributes + + + + the PP/ST author should specify the set of session + security attributes that are to be + constrained. Examples of these session security + attributes are user clearance level, integrity level + and roles. + + , based on + + + attributes + + + + the PP/ST author should specify the set of attributes + that can be use to determine the scope of the session + security attributes. Examples of such attributes are + user identity, originating location, time of access, + and method of access. + + . + + + + + + + + This family defines requirements to place limits on the + number of concurrent sessions that belong to the same user. + + + + This family defines how many sessions a user may have at the + same time (concurrent sessions). This number of concurrent + sessions can either be set for a group of users or for each + individual user. + + + + + + + + + This component allows the system to limit the number of + sessions in order to effectively use the resources of the + TOE. + + + + , provides limitations that apply to + all users of the TSF. + + + management of the maximum allowed number of concurrent user + sessions by an administrator. + + + Rejection of a new session based on the limitation of + multiple concurrent sessions. + + + Capture of the number of currently concurrent user sessions + and the user security attribute(s). + + + The TSF shall restrict the maximum number of concurrent + sessions that belong to the same user. + + + The TSF shall enforce, by default, a limit of + + + default number + + + + the PP/ST author should specify the default number of + maximum concurrent sessions to be used. + + + sessions per user. + + + + + + + + + + + This component provides additional capabilities over those + of , by allowing further constraints + to be placed on the number of concurrent sessions that + users are able to invoke. These constraints are in terms + of a user's security attributes, such as a + user's identity, or membership of a role. + + + + extends by + requiring the ability to specify limitations on the number + of concurrent sessions based on the related security + attributes. + + + management of the rules that govern the maximum allowed + number of concurrent user sessions by an administrator. + + + + + The TSF shall restrict the maximum number of concurrent + sessions that belong to the same user according to the rules + + + rules for the number of maximum concurrent sessions + + + + the PP/ST author should specify the rules that + determine the maximum number of concurrent + sessions. An example of a rule is ``maximum + number of concurrent sessions is one if the user has a + classification level of ``secret'' + and five otherwise''. + + . + + + The TSF shall enforce, by default, a limit of + + + default number + + + + the PP/ST author should specify the default number of + maximum concurrent sessions to be used. + + + sessions per user. + + + + + + + + This family defines requirements for the TSF to provide the + capability for TSF-initiated and user-initiated locking, + unlocking, and termination of interactive sessions. + + + This family defines requirements for the TSF to provide the + capability for TSF-initiated and user-initiated locking, + unlocking, and termination of interactive sessions. + When a user is directly interacting with subjects in the TOE + (interactive session), the user's terminal is vulnerable if + left unattended. This family provides requirements for the TSF + to disable (lock) the terminal or terminate the session after + a specified period of inactivity, and for the user to initiate + the disabling (locking) of the terminal or terminate the + session. To reactivate the terminal, an event specified by the + PP/ST author, such as the user re-authentication must + occur. + A user is considered inactive, if he/she has not provided any + stimulus to the TOE for a specified period of time. + A PP/ST author should consider whether + should be included. In that case, the function ``session + locking'' should be included in the operation in . + + + + + + + + , provides the capability for the + TSF to lock an active user session after a specified + period of time. Locking a terminal would prevent any + further interaction with an existing active session + through the use of the locked terminal. + + If display devices are overwritten, the replacement + contents need not be static (i.e. ``screen + savers'' are permitted). + + This component allows the PP/ST author to specify what + events will unlock the session. These events may be + related to the terminal (e.g. fixed set of keystrokes to + unlock the session), the user (e.g. reauthentication), or + time. + + + + includes system initiated locking + of an interactive session after a specified period of user + inactivity. + + + specification of the time of user inactivity after which + lock-out occurs for an individual user; + + + specification of the default time of user inactivity after + which lock-out occurs; + + + management of the events that should occur prior to + unlocking the session. + + + Locking of an interactive session by the session locking + mechanism. + + + Successful unlocking of an interactive session. + + + Any attempts at unlocking an interactive session. + + + The TSF shall lock an interactive session after + + + time interval of user inactivity + + + + the PP/ST author should specify the interval of user + inactivity that will trigger the locking of an + interactive session. If so desired the PP/ST author + could, through the assignment, specify that the time + interval is left to the authorised administrator or + the user. The management functions in the FMT class + can specify the capability to modify this time + interval, making it the default value. + + + by: + + + clearing or overwriting display devices, making the + current contents unreadable; + + + disabling any activity of the user's data + access/display devices other than unlocking the session. + + + + + The TSF shall require the following events to occur prior to + unlocking the session: + + + events to occur + + + + the PP/ST author should specify the event(s) that + should occur before the session is unlocked. Examples + of such an event are: ``user + re-authentication'' or ``user + enters unlock key-sequence''. + + . + + + + + + + + + , provides the capability for + an authorised user to lock and unlock his/her own interactive + session. This would provide authorised users with the ability to + effectively block further use of their active sessions without + having to terminate the active session. + + If devices are overwritten, the replacement contents need + not be static (i.e. ``screen savers'' + are permitted). + + + + , provides capabilities for the user + to lock and unlock the user's own interactive + sessions. + + + management of the events that should occur prior to + unlocking the session. + + + + + The TSF shall allow user-initiated locking of the + user's own interactive session, by: + + + clearing or overwriting display devices, making the + current contents unreadable; + + + disabling any activity of the user's data + access/display devices other than unlocking the session. + + + + + The TSF shall require the following events to occur prior to + unlocking the session: + + + events to occur + + + + the PP/ST author should specify the event(s) that + should occur before the session is unlocked. Examples + of such an event are: ``user + re-authentication'', or ``user + enters unlock key-sequence''. + + . + + + + + + + , requires that the TSF terminate an + interactive user session after a period of inactivity. + + The PP/ST author should be aware that a session may + continue after the user terminated his/her activity, for + example, background processing. This requirement would + terminate this background subject after a period of + inactivity of the user without regard to the status of the + subject. + + + , provides requirements for + the TSF to terminate the session after a specified period of + user inactivity. + + + specification of the time of user inactivity after which + termination of the interactive session occurs for an + individual user; + + + specification of the default time of user inactivity after + which termination of the interactive session occurs. + + + Termination of an interactive session by the session locking + mechanism. + + + The TSF shall terminate an interactive session after a + + + time interval of user inactivity + + + + the PP/ST author should specify the interval of user + inactivity that will trigger the termination of an + interactive session. If so desired, the PP/ST author + could, through the assignment, specify that the + interval is left to the authorised administrator or + the user. The management functions in the FMT class + can specify the capability to modify this time + interval, making it the default value. + + . + + , provides the capability for an + authorised user to terminate his/her interactive + session.. + The PP/ST author should be aware that a session may continue + after the user terminated his/her activity, for example, + background processing. This requirement would allow the user + to terminate this background subject without regard to the + status of the subject., provides capabilities for the user + to terminate the user's own interactive sessions. + Termination of an interactive session by the user. + + The TSF shall allow user-initiated termination of the user's own + interactive session. + + + + + + + This family defines requirements to display a configurable + advisory warning message to users regarding the appropriate + use of the TOE. + + + + Prior to identification and authentication, TOE access + requirements provide the ability for the TOE to display an + advisory warning message to potential users pertaining to + appropriate use of the TOE. + + + + + + This component requires that there is an advisory warning + regarding the unauthorised use of the TOE. A PP/ST author + could refine the requirement to include a default banner. + + + + , provides the requirement for a TOE + Access Banner. This banner is displayed prior to the + establishment dialogue for a session. + + + maintenance of the banner by the authorised administrator. + + + Before establishing a user session, the TSF shall display an + advisory warning message regarding unauthorised use of the + TOE. + + + + + + + + This family defines requirements for the TSF to display to a + user, upon successful session establishment, a history of + successful and unsuccessful attempts to access the + user's account. + + + + This family defines requirements for the TSF to display to + users, upon successful session establishment to the TOE, a + history of unsuccessful attempts to access the account. This + history may include the date, time, means of access, and + port of the last successful access to the TOE, as well as + the number of unsuccessful attempts to access the TOE since + the last successful access by the identified user. + + + + + + + This family can provide authorised users with information + that may indicate the possible misuse of their user + account. + + This component request that the user is presented with the + information. The user should be able to review the + information, but is not forced to do so. If a user so + desires he might, for example, create scripts that ignore + this information and start other processes. + + + + , provides the requirement for a TOE + to display information related to previous attempts to + establish a session. + + + Upon successful session establishment, the TSF shall display + the + + + date + + + time + + + method + + + location + + + + the PP/ST author should select the security attributes + of the last successful session establishment that will + be shown at the user interface. The items are: date, + time, method of access (such as ftp), and/or location + (e.g. terminal 50). + + + of the last successful session establishment to the user. + + + Upon successful session establishment, the TSF shall display + the + + + date + + + time + + + method + + + location + + + + the PP/ST author should select the security attributes + of the last unsuccessful session establishment that + will be shown at the user interface. The items are: + date, time, method of access (such as ftp), and/or + location (e.g. terminal 50). + + + of the last unsuccessful attempt to session establishment + and the number of unsuccessful attempts since the last + successful session establishment. + + + The TSF shall not erase the access history information from + the user interface without giving the user an opportunity to + review the information. + + + + + + + This family defines requirements to deny a user permission + to establish a session with the TOE. + + + + This family defines requirements to deny an user permission + to establish a session with the TOE based on attributes such + as the location or port of access, the user's security + attribute (e.g. identity, clearance level, integrity level, + membership in a role), ranges of time (e.g. time-of-day, + day-of-week, calendar dates) or combinations of parameters. + + This family provides the capability for the PP/ST author to + specify requirements for the TOE to place constraints on the + ability of an authorised user to establish a session with + the TOE. The identification of relevant constraints can be + achieved through the use of the selection + operation. Examples of attributes that could be used to + specify the session establishment constraints are: + + + The location of access can be used to constrain the + ability of a user to establish an active session with + the TOE, based on the user's location or port + of access. This capability is of particular use in + environments where dial-up facilities or network + facilities are available. + + + The user's security attributes can be used to + place constraints on the ability of a user to establish + an active session with the TOE. For example, these + attributes would provide the capability to deny session + establishment based on any of the following: + + + a user's identity; + + + a user's clearance level; + + + a user's integrity level; and + + + a user's membership in a role. + + + + + + This capability is particularly relevant in situations where + authorisation or login may take place at a different + location from where TOE access checks are performed. + + + The time of access can be used to constrain the ability + of a user to establish an active session with the TOE + based on ranges of time. For example, ranges may be + based upon time-of-day, day-of-week, or calendar + dates. This constraint provides some operational + protection against actions that could occur at a time + where proper monitoring or where proper procedural + measures may not be in place. + + + + + + + + , provides requirements for denying + users access to the TOE based on attributes. + + + management of the session establishment conditions by the + authorised administrator. + + + Denial of a session establishment due to the session + establishment mechanism. + + + All attempts at establishment of a user session. + + + Capture of the value of the selected access parameters + (e.g. location of access, time of access). + + + The TSF shall be able to deny session establishment based on + + + attributes + + + + the PP/ST author should specify the attributes that + can be used to restrict the session + establishment. Example of possible attributes are user + identity, originating location (e.g. no remote + terminals), time of access (e.g. outside hours), or + method of access (e.g. X-windows). + + . + + + + + + + + Families in this class provide requirements for a trusted + communication path between users and the TSF, and for a + trusted communication channel between the TSF and other + trusted IT products. Trusted paths and channels have the + following general characteristics: + + + The communications path is constructed using internal and + external communications channels (as appropriate for the + component) that isolate an identified subset of TSF data + and commands from the remainder of the TSF and user data. + + + Use of the communications path may be initiated by the + user and/or the TSF (as appropriate for the component). + + + The communications path is capable of providing assurance + that the user is communicating with the correct TSF, and + that the TSF is communicating with the correct user (as + appropriate for the component). + + + + In this paradigm, a trusted channel is a communication channel + that may be initiated by either side of the channel, and + provides non-repudiation characteristics with respect to the + identity of the sides of the channel. + + A trusted path provides a means for users to perform functions + through an assured direct interaction with the TSF. Trusted + path is usually desired for user actions such as initial + identification and/or authentication, but may also be desired + at other times during a user's session. Trusted + path exchanges may be initiated by a user or the TSF. User + responses via the trusted path are guaranteed to be protected + from modification by or disclosure to untrusted applications. + + + + Users often need to perform functions through direct + interaction with the TSF. A trusted path provides confidence + that a user is communicating directly with the TSF whenever it + is invoked. A user's response via the trusted path + guarantees that untrusted applications cannot intercept or + modify the user's response. Similarly, trusted + channels are one approach for secure communication between the + TSF and another trusted IT product. + + Absence of a trusted path may allow breaches of accountability + or access control in environments where untrusted applications + are used. These applications can intercept user-private + information, such as passwords, and use it to impersonate + other users. As a consequence, responsibility for any system + actions cannot be reliably assigned to an accountable + entity. Also, these applications could output erroneous + information on an unsuspecting user's display, + resulting in subsequent user actions that may be erroneous and + may lead to a security breach. + + + + + + This family defines requirements for the creation of a + trusted channel between the TSF and other trusted IT + products for the performance of security critical + operations. This family should be included whenever there + are requirements for the secure communication of user or TSF + data between the TOE and other trusted IT products. + + + + This family defines the rules for the creation of a trusted + channel connection that goes between the TSF and another + trusted IT product for the performance of security critical + operations between the products. An example of such a + security critical operation is the updating of the TSF + authentication database by the transfer of data from a + trusted product whose function is the collection of audit + data. + + + + + + This component should be used when a trusted communication + channel between the TSF and another trusted IT product is + required. + + + + , requires that the TSF provide a + trusted communication channel between itself and another + trusted IT product. + + + Configuring the actions that require trusted channel, if + supported. + + + Failure of the trusted channel functions. + + + Identification of the initiator and target of failed trusted + channel functions. + + + All attempted uses of the trusted channel functions. + + + Identification of the initiator and target of all trusted + channel functions. + + + 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. + + + The TSF shall permit + + the TSF + + another trusted IT product + + the PP/ST author must specify whether the local TSF, + another trusted IT product, or both shall have the + capability to initiate the trusted channel. + to initiate communication via the trusted channel. + + + The TSF shall initiate communication via the trusted channel + for + + + list of functions for which a trusted channel is + required + + + + the PP/ST author should specify the functions for + which a trusted channel is required. Examples of these + functions may include transfer of user, subject, + and/or object security attributes and ensuring + consistency of TSF data. + + . + + + + + + + + This family defines the requirements to establish and + maintain trusted communication to or from users and the + TSF. A trusted path may be required for any + security-relevant interaction. Trusted path exchanges may be + initiated by a user during an interaction with the TSF, or + the TSF may establish communication with the user via a + trusted path. + + + + This family defines the requirements to establish and + maintain trusted communication to or from users and the + TSF. A trusted path may be required for any + security-relevant interaction. Trusted path exchanges may be + initiated by a user during an interaction with the TSF, or + the TSF may establish communication with the user via a + trusted path. + + + + + + This component should be used when trusted communication + between a user and the TSF is required, either for initial + authentication purposes only or for additional specified + user operations. + + + + , requires that a trusted path + between the TSF and a user be provided for a set of events + defined by a PP/ST author. The user and/or the TSF may + have the ability to initiate the trusted path. + + + Configuring the actions that require trusted path, if + supported. + + + Failures of the trusted path functions. + + + Identification of the user associated with all trusted path + failures, if available. + + + All attempted uses of the trusted path functions. + + + Identification of the user associated with all trusted path + invocations, if available. + + + The TSF shall provide a communication path between itself and + + remote + + local + + the PP/ST author should specify whether the trusted path + must be extended to remote and/or local users. + users that is logically distinct from other communication + paths and provides assured identification of its end points + and protection of the communicated data from + + modification + + disclosure + + other types of integrity or confidentiality violation + + if selected, the PP/ST author should identify any + additional types of integrity or confidentiality + violation against which the trusted path shall protect + the data. + the PP/ST author should specify whether the trusted path + shall protect the data from modification, disclosure, + and/or other types of integrity or confidentiality + violation.. + + + The TSF shall permit + + + the TSF + + + local users + + + remote users + + + + the PP/ST author should specify whether the TSF, local + users, and/or remote users should be able to initiate + the trusted path. + + + to initiate communication via the trusted path. + + + The TSF shall require the use of the trusted path for + + + initial user authentication + + + + + other services for which trusted path is required + + + + if selected, the PP/ST author should identify + other services for which trusted path is required, + if any. + + + + + + the PP/ST author should specify whether the trusted + path is to be used for initial user authentication + and/or for other specified services. + + . + + + + + + + + The class encompasses five + families. These families specify assurance requirements that + are designed to provide confidence that a composed TOE will + operate securely when relying upon security functionality + provided by previously evaluated software, firmware or + hardware components. + + Composition involves taking two or more IT entities + successfully evaluated against CC security assurance + requirements packages (base components and dependent + components, see ) and + combining them for use, with no further development of either + IT entity. The development of additional IT entities is not + included (entities that have not previously been the subject + of a component evaluation). The composed TOE forms a new + product that can be installed and integrated into any specific + environment instance that meets the objectives for the + environment. + + This approach does not provide an alternative approach for the + evaluation of components. Composition under provides a composed TOE integrator a method, which + can be used as an alternative to other assurance levels + specified in the CC, to gain confidence in a TOE that is the + combination of two or more successfully evaluated components + without having to re-evaluate the composite TSF. (The composed + TOE integrator is referred to as ``developer'' throughout the + class, with any references to the + developer of the base or dependent components clarified as + such.) + + Composed Assurance Packages, as defined in Clauses and , is an + assurance scale for composed TOEs. This assurance scale is + required in addition to EALs because to combine components + evaluated against EALs and gain a resulting EAL assurance, all + SARs in the EAL have to be applied to the composed + TOE. Although reuse can be made of the component TOE + evaluation results, there are often additional aspects of the + components that have to be considered in the composed TOE, as + described in Annex . Due to the different parties involved in a + composed TOE evaluation activity it is generally not possible + to gain all necessary evidence about these additional aspects + of the components to apply the appropriate EAL. Hence, CAPs + have been defined to address the issue of combining evaluated + components and gaining a meaningful result. This is discussed + further in . + +
+ + + In a composed TOE it is generally the case that one component + relies on the services provided by another component. The + component requiring services is termed the dependent component + and the component providing the services is termed the base + component. This interaction and distinct is discussed further + in Annex B. It is assumed to be the case that the developer of + the dependent component is supporting the composed TOE + evaluation in some manner (as developer, sponsor, or just + cooperating and providing the necessary evaluation evidence + from the dependent component evaluation) The components included in the CAP assurance packages + should not be used as augmentations for component TOE + evaluations, as this would provide no meaningful assurance for + the component. + + The families within the class + interact in a similar manner to the , and classes in a component TOE evaluation and hence + leverage from the specification of requirements from those + classes where applicable. There are however a few items + specific to composed TOE evaluations. To determine how the + components interact and identify any deviations from the + evaluations of the components, the dependencies that the + dependent component has upon the underlying base component are + identified (). This reliance on + the base component is specified in terms of the interfaces + through which the dependent component makes calls for services + in support of the dependent component SFRs. The interfaces, + and at higher levels the supporting behaviour, provided by the + base component in response to those service requests are + analysed in . The family is based on the family, as at the simplest level the + TSF of each component can be viewed as a subsystem of the + composed TOE, with additional portions of each component seen + as additional subsystems. Therefore, the interfaces between + the components are seen as interactions between subsystems in + a component TOE evaluation. + + It is possible that the interfaces and supporting behaviour + descriptions provided for are + incomplete. This is determined during the conduct of . The + family takes the outputs of and + and determines whether the + components are being used in their evaluated configuration and + identifies where any specifications are incomplete, which are + then identified as inputs into testing () and vulnerability analysis () activities of the composed TOE. + + Testing of the composed TOE is performed to determine that the + composed TOE exhibits the expected behaviour as determined by + the composed TOE SFRs, and at higher levels demonstrates the + compatibility of the interfaces between the components of the + composed TOE. + + The vulnerability analysis of the composed TOE leverages from + the outputs of the vulnerability analysis of the component + evaluations. The composed TOE vulnerability analysis considers + any residual vulnerabilities from the component evaluations to + determine that the residual vulnerabilities are not applicable + to the composed TOE. A search of publicly available + information relating to the components is also performed to + identify any issues reported in the components since the + completion of the respective evaluations. + + The interaction between the + families is depicted in Figure below. This shows by solid arrowed lines where + the evidence and understanding gained in one family feeds into + the next activity and the dashed arrows identify where an + activity explicitly traces back to the composed TOE SFRs, as + described above. + +
+ + + Further discussion of the definition and interactions within + composed TOEs is provided in . + + + + Assurance class defines + requirements of the information necessary to ensure that two + or more components, which have themselves been the subject of + a CC evaluation, can be integrated in a secure manner. + + The assurance requirements will + be applied to the composed TOE to: + + + determine that the required assurance is provided by the + base component; + + determine that the base component and dependent component + are compatible; and + + search for any vulnerabilities introduced through + composing the base and dependent components into a single + composed TOE entity. + + + + The goal of this activity is to determine whether the + components can be integrated in a secure manner, as defined in + the ST for the composed TOE. This is achieved through + examination and testing of the interfaces between the + components, supported by examination of the design of the + components and the conduct of vulnerability analysis. + + + + The family identifies where + the dependent component is reliant upon IT in its operational + environment (satisfied by a base component in the composed TOE + evaluation) in order to provide its own security + services. This reliance is identified in terms of the + interfaces expected by the dependent component to be provided + by the base component. then + determines which interfaces of the base component were + considered (as TSFI) during the component evaluation of the + base component. + + It should be noted that does + not cover other evidence that may be needed to address the + technical integration problem of composing components + (e.g. descriptions of non-TSF interfaces of the operating + system, rules for integration, etc.). This is outside the + security assessment of the composition and is a functional + composition issue. + + As part of the evaluator will + perform testing of the composed TOE SFRs at the composed TOE + interfaces and of the interfaces of the base component relied + upon by the dependent component to confirm they operate as + specified. The subset selected will consider the possible + effects of changes to the configuration/use of the base + component as used in the composed TOE. These changes are + identified from the configuration of the base component + determined during the base component evaluation. The developer + will provide test evidence for each of the base component + interfaces (the requirements for coverage are consistent with + those applied to the evaluation of the base component). + + requires the evaluator to + determine whether the appropriate assurance measures have been + applied to the base component, and whether the base component + is being used in its evaluated configuration. This includes + determination of whether all security functionality required + by the dependent component was within the TSF of the base + component. The requirement + may be met through the production of evidence that each of + these is demonstrated to be upheld. This evidence may be in + the form of the security target and a public report of the + component evaluation (e.g. certification report). + + If, on the other hand, one of the above have not been upheld, + then it may be possible that an argument can be made as to why + the assurance gained during an original evaluation is + unaffected. If this is not possible then additional evaluation + evidence for those aspects of the base component not covered + may have to be provided. This material is then assessed in + . + + For example, it may be the case as described in the + Interactions between entities (see Annex in CC Part 3) that the + dependent component requires the base component to provide + more security functionality in the composed TOE than included + in the base component evaluation. This would be determined + during the application of the + and families. In this case + the composition rationale evidence provided for would demonstrate that the + assurance gained from the base component evaluation is + unaffected. This may be achieved by means including: + + + Performing a re-evaluation of the base component focusing + on the evidence relating to the extended part of the + TSF; + + Demonstrating that the extended part of the TSF cannot + affect other portions of the TSF, and providing evidence + that the extended part of the TSF provides the necessary + security functionality. + + + + + This family addresses the requirement to demonstrate that + the base component can provide an appropriate level of + assurance for use in composition. + + + + The family is used to + determine whether or not the appropriate assurance measures + have been applied to the base component for successful + integration in the composed TOE. That is, the SARs claimed + by the base component are consistent with the SARs in the + assurance package for the composed TOE. (e.g. if the + assurance package for the composed TOE included , a base component that was + evaluated against would + not have had the appropriate assurance measures applied, as + insufficient design evidence would have been + examined.) + + The family calls for + evidence that the appropriate assurance is provided, without + being specific about how this is achieved. If the + appropriate evidence is not available, then it may be + necessary to report an assessment of the residual risk to + assist consumers of the composed TOE + (e.g. accreditors). This report would need to identify the + change to the base component that may have an effect on the + assurance gained during the original evaluation, along with + any known effects. + + + + + There is only a single component in this family. + + + + + + + + The evaluation evidence for this sub-activity is: + + + the composed ST; + + the composition rationale; + + the reliance information; + + the development information; + + unique identifier. + + + + + The developer shall provide composition rationale for the + base component. + + + The composition rationale shall demonstrate that a level of + assurance at least as high as that of the dependent + component has been obtained for the support functionality of + the base component, when the base component is configured as + required to support the TSF of the dependent component. + + + The evaluator shall confirm that the information meets all + requirements for content and presentation of evidence. + + + + The evaluator shall examine the correspondence analysis + with the development information and the reliance + information to identify the interfaces that are relied + upon by the dependent component which are not detailed + in the development information. + + The evaluator's goal in this work unit is two fold: + + + to determine which interfaces relied upon by the + dependent component have had the appropriate + assurance measures applied. + + to determine that the assurance package applied to + the base component during the base component + evaluation contained either the same assurance + requirements as those in the package applied to the + dependent component during its' evaluation, or + hierarchically higher assurance requirements. + + + The evaluator may use the correspondence tracing in the + development information developed during the activities (e.g. , , ) to + help identify the interfaces identified in the reliance + information that are not considered in the development + information. + + The evaluator will record the SFR-enforcing interfaces + described in the reliance information that are not + included in the development information. These will + provide input to + work unit, helping to identify the portions of the base + component in which further assurance is required. + + If the both the base and dependent components were + evaluated against the same assurance package, then the + determination of whether the level of assurance in the + portions within the base component evaluation is at + least as high as that of the dependent component is + trivial. If however, the assurance packages applied to + the components during the component evaluations differ, + the evaluator needs to determine that the assurance + requirements applied to the base component are all + hierarchically higher to the assurance requirements + applied to the dependent component. + + + + + The evaluator shall examine the composition rationale to + determine, for those included base component interfaces + on which the dependent TSF relies, whether the interface + was considered during the evaluation of the base + component. + + The ST, component public evaluation report (e.g. certification + report) and guidance documents for the base component all + provide information on the scope and boundary of the base + component. The ST provides details of the logical scope and + boundary of the composed TOE, allowing the evaluator to + determine whether an interface relates to a portion of the + product that was within the scope of the evaluation. The + guidance documentation provides details of use of all interfaces + for the composed TOE. Although the guidance documentation may + include details of interfaces in the product that are not within + the scope of the evaluation, any such interfaces should be + identifiable, either from the scoping information in the ST or + through a portion of the guidance that deals with the evaluated + configuration. The public evaluation report may provide any + additional constraints on the use of the composed TOE that are + necessary. + + Therefore, the combination of these inputs allows the + evaluator to determine whether an interface described in + the composition rationale has the necessary assurance + associated with it, or whether further assurance is + required. The evaluator will record those interfaces of + the base component for which additional assurance is + required, for consideration during . + + + + + The evaluator shall examine the composition rationale to + determine that the necessary assurance measures have + been applied to the base component. + + The evaluation verdicts, and resultant assurance, for + the base component can be reused provided the same + portions of the base component are used in the composed + TOE and they are used in a consistent manner. + + In order to determine whether the necessary assurance + measures have already been applied to the component, and + the portions of the component for which assurance + measures still need to be applied, the evaluator should + use the output of the .*.2E action and the work units and : + + + + For those interfaces identified in the reliance + information (), but + not discussed in development information (), additional information + is required. (Identified in .) + + For those interfaces used inconsistently in the + composed TOE from the base component (difference + between the information provided in and the impact of the differences in use + need to be considered. (Identified in .*.2E.) + + For those interfaces identified in composition + rationale for which no assurance has previously been + gained, additional information is + required. (Identified in .) + + For those interfaces consistently described in the + reliance information, composition rationale and the + development information, no further action is + required as the results from the base component + evaluation can be re-used. + + The interfaces of the base component reported to be + required by the reliance information but not included in + the development information indicate the portions of the + base component where further assurance is required. The + interfaces identify the entry points into the base + component. + + For those interfaces included in both the development + information and reliance information, the evaluator is + to determine whether the interfaces are being used in + the composed TOE in a manner that is consistent with the + base component evaluation. The method of use of the + interface will be considered during the activities to determine that + the use of the interface is consistent in both the base + component and the composed TOE. The remaining + consideration is the determination of whether the + configurations of the base component and the composed + TOE are consistent. To determine this, the evaluator + will consider the guidance documentation of each to + ensure they are consistent (see further guidance below + regarding consistent guidance documentation). Any + deviation in the documentation will be further analysed + by the evaluation to determine the possible + effects. + + For those interfaces that are consistently described in + the reliance information and development information, + and for which the guidance is consistent for the base + component and the composed TOE, the required level of + assurance has been provided. + + The following subsubclauses provide guidance on how to + determine consistency between assurance gained in the + base component, the evidence provided for the composed + TOE, and the analysis performed by the evaluator in the + instances where inconsistencies are identified. + + + The reliance information identifies the interfaces in + the dependent component that are to be matched by the + base component. If an interface identified in the + reliance information is not identified in the + development information, then the composition + rationale is to provide a justification of how the + base component provides the required + interfaces. + + If an interface identified in the reliance information + is identified in the development information, but + there are inconsistencies between the descriptions, + further analysis is required. The evaluator identifies + the differences in use of the base component as + considered in the base component evaluation and the + composed TOE evaluation. The evaluator will devise + testing to be performed (during the conduct of ) to test the + interface. + + The patch status of the base and dependent components + as used in the composed TOE should be compared to the + patch status of the components during the component + evaluations. If any patches have been applied to the + components, the composition rationale is to include + details of the patches, including any potential impact + to the SFRs of the evaluated component. The evaluator + should consider the details of the changes provided + and verify the accuracy of the potential impact of the + change on the component SFRs. The evaluator should + then consider whether the changes made by the patch + should be verified through testing, and will identify + the necessary testing approach. The testing may take + the form of repeating the applicable + evaluator/developer testing performed for the + component evaluation of the component or it may be + necessary for the evaluator to devise new tests to + confirm the modified component. + + If any of the individual components have been the + subject of assurance continuity activities since the + completion of the component evaluation, the evaluator + will consider the changes assessed in the assurance + continuity activities during the independent + vulnerability analysis activity for the composed TOE + (in ). + + + + The guidance for the composed TOE is likely to make + substantial reference out to the guidance for the + individual components. The minimal guidance expected + to be necessary is the identification of any ordering + dependencies in the application of guidance for the + dependent and base components, particularly during the + preparation (installation) of the composed TOE. + + In addition to the application of the and families to the guidance for the + composed TOE, it is necessary to analyse the + consistency between the guidance for the components + and the composed TOE, to identify any + deviations. + + If the composed TOE guidance refers out to the base + component and dependent component guidance, then the + consideration for consistency is limited to + consistency between the guidance documentation + provided for each of the components (i.e. consistency + between the base component guidance and the dependent + component guidance). However, if additional guidance + is provided for the composed TOE, to that provided for + the components, greater analysis is required, as + consistency is also required between the guidance + documentation for the components and guidance + documentation for the composed TOE. + + Consistent in this instance is + understood to mean that either the guidance is the + same or it places additional constraints on the + operation of the individual components when combined, + in a similar manner to refinement of + functional/assurance components. + + With the information available (that used as input for + or the development + aspects discussed above) the evaluator may be able to + determine all possible impacts of the deviation from + the configuration of the base component specified in + the component evaluation. However, for high EALs + (where evaluation of the base component included requirements) it is + possible that, unless detailed design abstractions for + the base component are delivered as part of the + development information for the composed TOE, the + possible impacts of the modification to the guidance + cannot be fully determined as the internals are + unknown. In this case the evaluator will report the + residual risk of the analysis. + + These residual risks are to be included in any public + evaluation report for the composed TOE. + + The evaluator will note these variances in the + guidance for input into evaluator independent testing + activities (). + + The guidance for the composed TOE may add to the + guidance for the components, particularly in terms of + installation and the ordering of installation steps + for the base component in relation to the installation + steps for the dependent component. The ordering of + the steps for the installation of the individual + components should not change, however they may need to + be interleaved. The evaluator will examine this + guidance to ensure that it still meets the requirement + of the activity + performed during the evaluations of the + components. + + It may be the case that the reliance information + identifies that interfaces of the base component, in + addition to those identified as TSFIs of the base + component, are relied upon by the dependent component + are identified in the reliance information. It may be + necessary for guidance to be provided for the use of + any such additional interfaces in the base + component. Provided the consumer of the composed TOE + is to receive the guidance documentation for the base + component, then the results of the and + verdicts for the base component can be reused for + those interfaces considered in the evaluation of the + base component. However, for the additional interfaces + relied upon by the dependent component, the evaluator + will need to determine that the guidance documentation + for the base component meets the requirements of and , as applied in the base component + evaluations. + + For those interfaces considered during the base + component evaluation, and therefore, for which + assurance has already been gained, the evaluator will + ensure that the guidance for the use of each interface + for the composed TOE is consistent with that provided + for the base component. To determine the guidance for + the composed TOE is consistent with that for the base + component, the evaluator should perform a mapping for + each interface to the guidance provided for both the + composed TOE and the base component. The evaluator + then compares the guidance to determine + consistency. + + Examples of additional constraints provided in + composed TOE guidance that would be considered to be + consistent with component guidance are (guidance for a + component is given followed by an example of guidance + for a composed TOE that would be considered to provide + additional constraints): + + + Component: The password length must be set to a + minimum of 8 characters length, including + alphabetic and numeric characters. + + Composed TOE: The password length must be set to a + minimum of 10 characters in length, including + alphabetic and numeric characters and at + least one of the following special characters: ( ) + { } ^ < > - _ + + NOTE: It would only be acceptable to increase the + password length to [integer > + 8] characters while removing the mandate + for the inclusion of both alphabetic and numeric + characters for the composed TOE, if the same or a + higher metric was achieved for the strength rating + (taking into account the likelihood of the + password being guessed). + + Component: The following services are to be + disabled in the registry settings: WWW Publishing + Service and ICDBReporter service. + + Composed TOE: The following services are to be + disabled in the registry settings: + Publishing Service, ICDBReporter service, + Remote Procedure Call (RPC) Locator and Procedure + Call (RPC) Service. + + Component: Select the following attributes to be + included in the accounting log files: date, time, + type of event, subject identity and + success/failure. + + Composed TOE: Select the following attributes to + be included in the accounting log files: date, + time, type of event, subject identity, + success/failure, event message and process + thread. + + If the guidance for the composed TOE deviates (is not + a refinement) from that provided for the base + component, the evaluator will assess the potential + risks of the modification to the guidance. The + evaluator will use the information available + (including that provided in the public domain, the + architectural description of the base component in the + public evaluation report (e.g. certification report), + the context of the guidance from the remainder of the + guidance documentation) to identify likely impact of + the modification to the guidance on the SFRs of the + composed TOE. + + If during the dependent component evaluation the trial + installation used the base component to satisfy the + environment requirements of the dependent component + this work unit for the composed TOE is considered to + be satisfied. If the base component was not used in + satisfaction of the work unit during the dependent component + evaluation, the evaluator will apply the user + procedures provided for the composed TOE to prepare + the composed TOE, in accordance with the guidance + specified in . This will allow the evaluator to + determine that the preparative guidance provided for + the composed TOE is sufficient to prepare the composed + TOE and its operational environment securely. + + + + + If there is a different delivery mechanism used for + the delivery of the composed TOE (i.e. the + components are not delivered to the consumer in + accordance with the secure delivery procedures + defined and assessed during the evaluation of the + components), the delivery procedures for the + composed TOE will require evaluation against the + requirements + applied during the components evaluations. + + The composed TOE may be delivered as an integrated + product or may require the components to be + delivered separately. + + If the components are delivered separately, the + results of the delivery of the base component and + dependent component are reused. The delivery of the + base component is checked during the evaluator trial + installation of the dependent component, using the + specified guidance and checking the aspects of + delivery that are the responsibility of the user, as + described in the guidance documentation for the base + component. + + If the composed TOE is delivered as a new entity, + then the method of delivery of that entity must be + considered in the composed TOE evaluation + activities. + + The assessment of the delivery procedures for + composed TOE items is to be performed in accordance + with the methodology for as for any other [component] TOE, + ensuring any additional items (e.g. additional + guidance documents for the composed TOE) are + considered in the delivery procedures. + + + + The unique identification of the composed TOE is + considered during the application of and the items from + which that composed TOE is comprised are considered + during the application of . + + Although additional guidance may be produced for the + composed TOE, the unique identification of this + guidance (considered as part of the unique + identification of the composed TOE during ) is considered + sufficient control of the guidance. + + The verdicts of the remaining (not considered above) + activities can be + reused from the base component evaluation, as no + further development is performed during integration + of the composed TOE. + + There are no additional considerations for + development security as the integration is assumed + to take place at either the consumer's site or, in + the instance that the composed TOE is delivered as + an integrated product, at the site of the dependent + component developer. Control at the consumer's site + is outside the consideration of the CC. No + additional requirements or guidance are necessary if + integration is at the same site as that for the + dependent component, as all components are + considered to be configuration items for the + composed TOE, and should therefore be considered + under the dependent component developer's security + procedures anyway. + + Tools and techniques adopted during integration will + be considered in the evidence provided by the + dependent component developer. Any tools/techniques + relevant to the base component will have been + considered during the evaluation of the base + component. For example, if the base component is + delivered as source code and requires compilation by + the consumer (e.g. dependent component developer who + is performing integration) the compiler would have + been specified and assessed, along with the + appropriate arguments, during evaluation of the base + component. + + There is no life-cycle definition applicable to the + composed TOE, as no further development of items is + taking place. + + The results of flaw remediation for a component are + not applicable to the composed TOE. If flaw + remediation is included in the assurance package for + the composed TOE, then the requirements are to be applied during + the composed TOE evaluation (as for any + augmentation). + + + + + The composed TOE will have been tested during the + conduct of the activities + for evaluation of the dependent component, as the + configurations used for testing of the dependent + component should have included the base component to + satisfy the requirements for IT in the operational + environment. If the base component was not used in the + testing of the dependent component for the dependent + component evaluation, or the configuration of either + component varied from their evaluated configurations, + then the developer testing performed for evaluation of + the dependent component to satisfy the requirements is to be repeated + on the composed TOE. + + + + + + + + + This family sets out requirements for a specification of the + base component in increasing levels of detail. Such + information is required to gain confidence that the + appropriate security functionality is provided to support + the requirements of the dependent component (as identified + in the reliance information). + + + + provides details of the + base component interfaces and internals in increasing levels + of detail, mirroring the level of detail provided by . The application of these two + families will provide the specifications of security + services from each perspective of the TSF making the call + and the TSF servicing the call. + + Having the two descriptions then allows a determination to + be made, as part of the + activities (.*.2E actions), + that these two descriptions are consistent. + + + + The components are levelled on the basis of increasing + amounts of detail about the interfaces provided, and how + they are implemented. + + + + The TSF of the base component is often defined without + knowledge of the dependencies of the possible applications + with which it may by composed. The TSF of this base + component is defined to include all parts of the base + component that have to be relied upon for enforcement of the + base component SFRs. This will include all parts of the base + component required to implement the base component + SFRs. + + The functional specification of the base component will + describe the TSFI in terms of the interfaces the base + component provides to allow an external entity to invoke + operations of the TSF. This includes interfaces to the + human user to permit interaction with the operation of the + TSF invoking SFRs and also interfaces allowing an external + IT entity to make calls into the TSF. + + The functional specification only provides a description of + what the TSF provides at its interface and the means by + which that TSF functionality are invoked. Therefore, the + functional specification does not necessarily provide a + complete interface specification of all possible interfaces + available between an external entity and the base + component. It does not include what the TSF expects/requires + from the operational environment. The description of what a + dependent component TSF relies upon of a base component is + considered in and the + development information evidence provides a response to the + interfaces specified. + + The development information evidence includes a + specification of the base component. This may be the + evidence used during evaluation of the base component to + satisfy the requirements, or may + be another form of evidence produced by either the base + component developer or the composed TOE developer. This + specification of the base component is used during to gain confidence that the + appropriate security functionality is provided to support + the requirements of the dependent component. The level of + detail required of this evidence increases to reflect the + level of required assurance in the composed TOE. This is + expected to broadly reflect the increasing confidence gained + from the application of the assurance packages to the + components. The evaluator determines that this description + of the base component is consistent with the reliance + information provided for the dependent component. + + + + + + A description of the interfaces in the base component, on + which the dependent component relies, is required. This is + examined to determine whether or not it is consistent with + the description of interfaces on which the dependent + component relies, as provided in the reliance + information. + + + + The objective of this sub-activity is to determine that + the appropriate security functionality is provided by the + base component to support the dependent component. This is + achieved through examination of the interfaces of the base + component to determine that they are consistent with the + interfaces specified in the reliance information; those + required by the dependent component. + + The description of the interfaces into the base component + is to be provided at a level of detail consistent with + although not all of the + aspects necessary for satisfaction of are required for , as once the interface has been identified + and the purpose described the remaining detail of the + interface specification can be reused from evaluation of + the base component. + + + + The evaluation evidence for this sub-activity is: + + + the composed ST; + + + the development information; + + + the reliance information. + + + + + The developer shall provide development information for the + base component. + + + The development information shall describe the purpose of + each interface of the base component used in the composed + TOE. + + + The development information shall show correspondence + between the interfaces, used in the composed TOE, of the + base component and the dependent component to support the + TSF of the dependent component. + + + The evaluator shall confirm that the information meets all + requirements for content and presentation of evidence. + + + + The evaluator shall examine the development information + to determine that it describes the purpose of each + interface. + + The base component provides interfaces to support + interaction with the dependent component in the + provision of the dependent TSF. The purpose of each + interface is to be described at the same level as the + description of the interfaces to the dependent component + TSF functionality, as would be provided between + subsystems in the TOE design (). This description is to provide the + reader with an understanding of how the base component + provides the services required by the dependent + component TSF. + + This work unit may be satisfied by the provision of the + functional specification for the base component for + those interfaces that are TSFIs of the base + component. + + + + + The evaluator shall examine the development information + to determine the correspondence, between the interfaces + of the base component and the interfaces on which the + dependent component relies, is accurate. + + The correspondence between the interfaces of the base + component and the interfaces on which the dependent + component relies may take the form of a matrix or + table. The interfaces that are relied upon by the + dependent component are identified in the reliance + information (as examined during activity). + + There is, during this activity, no requirement to + determine completeness of the coverage of interfaces + that are relied upon by the dependent component, only + that the correspondence is correct and ensuring that + interfaces of the base component are mapped to + interfaces required by the dependent component wherever + possible. The completeness of the coverage is considered + in activities. + + + + The evaluator shall determine that the interface description + provided is consistent with the reliance information + provided for the dependent component. + + + The evaluator shall examine the development information + and the reliance information to determine that the + interfaces are described consistently. + + The evaluator's goal in this work unit is to determine + that the interfaces described in the development + information for the base component and the reliance + information for the dependent component are represented + consistently. + + + + + + + + + A description of the interfaces in the base component, on + which the dependent component relies, is required. This is + examined to determine whether or not it is consistent with + the description of interfaces on which the dependent + component relies, as provided in the reliance + information. + + In addition, the security behaviour of the base component + that supports the dependent component TSF is + described. + + + + The objective of this sub-activity is to determine that + the appropriate security functionality is provided by the + base component to support the dependent component. This is + achieved through examination of the interfaces and + associated security behaviour of the base component to + determine that they are consistent with the interfaces + specified in the reliance information; those required by + the dependent component. + + + + The evaluation evidence for this sub-activity is: + + + the composed ST; + + + the development information; + + + reliance information. + + + + + The developer shall provide development information for the + base component. + + + The development information shall describe the purpose and + method of use of each interface of the base component used + in the composed TOE. + + + The development information shall provide a high-level + description of the behaviour of the base component, which + supports the enforcement of the dependent component SFRs. + + + The development information shall show correspondence + between the interfaces, used in the composed TOE, of the + base component and the dependent component to support the + TSF of the dependent component. + + + The evaluator shall confirm that the information meets all + requirements for content and presentation of evidence. + + + + The evaluator shall examine the development information + to determine that it describes the purpose of each + interface. + + The base component provides interfaces to support + interaction with the dependent component in the + provision of the dependent TSF. The purpose of each + interface is to be described at the same level as the + description of the interfaces to the dependent component + TSF functionality, as would be provided between + subsystems in the TOE design (). This description is to provide the + reader with an understanding of how the base component + provides the services required by the dependent + component TSF. + + This work unit may be satisfied by the provision of the + functional specification for the base component for + those interfaces that are TSFIs of the base + component. + + + + + The evaluator shall examine the development information + to determine that it describes the method of use for + each interface. + + The method of use for an interface summarises how the + interface is manipulated in order to invoke the + operations and obtain results associated with the + interface. The evaluator should be able to determine + from reading this material in the development + information how to use each interface. This does not + necessarily mean that there needs to be a separate + method of use for each interface, as it may be possible + to describe in general how APIs are invoked, for + instance, and then identify each interface using that + general style. + + This work unit may be satisfied by the provision of the + functional specification for the base component for + those interfaces that are TSFIs of the base + component. + + + + The evaluator shall examine the development information + to determine that it describes the behaviour of the base + component that supports the enforcement of the dependent + component SFRs. + + The dependent component invokes interfaces of the base + component for the provision of services by the base + component. For the interfaces of the base component that + are invoked, the development information shall provide a + high-level description of the associated security + behaviour of the base component. The description of the + base component security behaviour will outline how the + base component provides the necessary service when the + call to the interface is made. This description is to be + at a level similar to that provided for . Therefore, the provision + of the TOE design evidence from the base component + evaluation would satisfy this work unit, where the + interfaces invoked by the dependent component are TSFI + of the base component. If the interfaces invoked by the + dependent component are not TSFIs of the base component + it is the associated security behaviour will not + necessarily be described in the base component TOE + design evidence. + + + + + The evaluator shall examine the development information + to determine the correspondence, between the interfaces + of the base component and the interfaces on which the + dependent component relies, is accurate. + + The correspondence between the interfaces of the base + component and the interfaces on which the dependent + component relies may take the form of a matrix or + table. The interfaces that are relied upon by the + dependent component are identified in the reliance + information (as examined during ). + + There is, during this activity, no requirement to + determine completeness of the coverage of interfaces + that are relied upon by the dependent component, only + that the correspondence is correct and ensuring that + interfaces of the base component are mapped to + interfaces required by the dependent component wherever + possible. The completeness of the coverage is considered + in activities. + + + + The evaluator shall determine that the interface description + provided is consistent with the reliance information + provided for the dependent component. + + + The evaluator shall examine the development information + and the reliance information to determine that the + interfaces are described consistently. + + The evaluator's goal in this work unit is to determine + that the interfaces described in the development + information for the base component and the reliance + information for the dependent component are represented + consistently. + + + + + + + + A description of the interfaces in the base component, on + which the dependent component relies, is required. This is + examined to determine whether or not it is consistent with + the description of interfaces on which the dependent + component relies, as provided in the reliance + information. + + The interface description of the architecture of the base + component is provided to enable the evaluator to determine + whether or not that interface formed part of the TSF of + the base component. + + + + The objective of this sub-activity is to determine that + the appropriate security functionality is provided by the + base component to support the dependent component. This is + achieved through examination of the interfaces and + associated security behaviour of the base component to + determine that they are consistent with the interfaces + specified in the reliance information; those required by + the dependent component. + + In addition to the interface description, the subsystems + of the base component that provide the security + functionality required by the dependent component will be + described to enable the evaluator to determine whether or + not that interface formed part of the TSF of the base + component. + + + + The evaluation evidence for this sub-activity is: + + + the composed ST; + + + the development information; + + + reliance information. + + + + + The developer shall provide development information for the + base component. + + + The development information shall describe the purpose and + method of use of each interface of the base component used + in the composed TOE. + + + The development information shall identify the subsystems of + the base component that provide interfaces of the base + component used in the composed TOE. + + + The development information shall provide a high-level + description of the behaviour of the base component + subsystems, which support the enforcement of the dependent + component SFRs. + + + The development information shall provide a mapping from the + interfaces to the subsystems of the base component. + + + The development information shall show correspondence + between the interfaces, used in the composed TOE, of the + base component and the dependent component to support the + TSF of the dependent component. + + + The evaluator shall confirm that the information meets all + requirements for content and presentation of evidence. + + + + The evaluator shall examine the development information + to determine that it describes the purpose of each + interface. + + The base component provides interfaces to support + interaction with the dependent component in the + provision of the dependent TSF. The purpose of each + interface is to be described at the same level as the + description of the interfaces to the dependent component + TSF functionality, as would be provided between + subsystems in the TOE design (). This description is to provide the + reader with an understanding of how the base component + provides the services required by the dependent + component TSF. + + This work unit may be satisfied by the provision of the + functional specification for the base component for + those interfaces that are TSFIs of the base + component. + + + + + The evaluator shall examine the development information + to determine that it describes the method of use for + each interface. + + The method of use for an interface summarises how the + interface is manipulated in order to invoke the + operations and obtain results associated with the + interface. The evaluator should be able to determine + from reading this material in the development + information how to use each interface. This does not + necessarily mean that there needs to be a separate + method of use for each interface, as it may be possible + to describe in general how APIs are invoked, for + instance, and then identify each interface using that + general style. + + This work unit may be satisfied by the provision of the + functional specification for the base component for + those interfaces that are TSFIs of the base + component. + + + + The evaluator shall examine the development information + to determine that all subsystems of the base component + that provide interfaces to the dependent component are + identified. + + For those interfaces that are considered to form part of + the TSFI of the base component, the subsystems + associated with the interface will be subsystems + considered in the + activity during the base component evaluation. The + interfaces on which the dependent component relies that + did not form part of the TSFI of the base component will + map to subsystems outside of the base component + TSF. + + + + The evaluator shall examine the development information + to determine that it describes the behaviour of the base + component subsystems that support the enforcement of the + dependent component SFRs. + + The dependent component invokes interfaces of the base + component for the provision of services by the base + component. For the interfaces of the base component that + are invoked, the development information shall provide a + high-level description of the associated security + behaviour of the base component. The description of the + base component security behaviour will outline how the + base component provides the necessary service when the + call to the interface is made. This description is to be + at a level similar to that provided for . Therefore, the provision + of the TOE design evidence from the base component + evaluation would satisfy this work unit, where the + interfaces invoked by the dependent component are TSFI + of the base component. If the interfaces invoked by the + dependent component are not TSFIs of the base component + it is the associated security behaviour will not + necessarily be described in the base component TOE + design evidence. + + + + + The evaluator shall examine the development information + to determine that the correspondence between the + interfaces and subsystems of the base component is + accurate. + + If the TOE design and functional specification evidence + from the base component evaluation is available, this + can be used to verify the accuracy of the correspondence + between the interfaces and subsystems of the base + component as used in the composed TOE. Those interfaces + of the base component, which formed part of the base + component TSFI will be described in the base component + functional specification, and the associated subsystems + will be described in the base component TOE design + evidence. The tracing between the two will be provided + in the base component TOE design evidence. + + If, however, the base component interface did not form + part of the TSFI of the base component, the description + of the subsystem behaviour provided in the development + information will be used to verify the accuracy of the + correspondence. + + + + The evaluator shall examine the development information + to determine the correspondence, between the interfaces + of the base component and the interfaces on which the + dependent component relies, is accurate. + + The correspondence between the interfaces of the base + component and the interfaces on which the dependent + component relies may take the form of a matrix or + table. The interfaces that are relied upon by the + dependent component are identified in the reliance + information (as examined during ). + + There is, during this activity, no requirement to + determine completeness of the coverage of interfaces + that are relied upon by the dependent component, only + that the correspondence is correct and ensuring that + interfaces of the base component are mapped to + interfaces required by the dependent component wherever + possible. The completeness of the coverage is considered + in activities. + + + + The evaluator shall determine that the interface description + provided is consistent with the reliance information + provided for the dependent component. + + + The evaluator shall examine the development information + and the reliance information to determine that the + interfaces are described consistently. + + The evaluator's goal in this work unit is to determine + that the interfaces described in the development + information for the base component and the reliance + information for the dependent component are represented + consistently. + + + + + + + The purpose of this family is to provide evidence that + describes the reliance that a dependent component has upon + the base component. This information is useful to persons + responsible for integrating the component with other + evaluated IT components to form the composed TOE, and for + providing insight into the security properties of the + resulting composition. + + This provides a description of the interface between the + dependent and base components of the composed TOE that may + not have been analysed during evaluation of the individual + components, as the interfaces were not TSFIs of the + individual component TOEs. + + + + The family considers the + interactions between the components where the dependent + component relies upon a service from the base component to + support the operation of security functionality of the + dependent component. The interfaces into these services of + the base component may not have been considered during + evaluation of the base component because the service in the + base component was not considered security-relevant during + evaluation of the component, either because of the inherent + purpose of the service (e.g., adjust type font) or because + associated CC SFRs are not being claimed in the base + component's ST (e.g. the login interface when no SFRs are claimed). These interfaces + into the base component are often viewed as functional + interfaces when evaluating the base component, and are in + addition to the security interfaces (TSFIs) considered in + the functional specification. + + + + The components in this family are levelled according to the + amount of detail provided in the description of the reliance + by the dependent component upon the base component. + + + + The family considers the + interactions between the components where the dependent + component relies upon a service from the base component to + support the operation of security functionality of the + dependent component. The interfaces into these services of + the base component may not have been considered during + evaluation of the base component because the service in the + base component was not considered security-relevant in the + component evaluation, either because of the inherent purpose + of the service (e.g., adjust type font) or because + associated CC SFRs are not being claimed in the base + component's ST (e.g. the login interface when no SFRs are claimed). These interfaces + into the base component are often viewed as functional + interfaces in the evaluation of the base component, and are + in addition to the security interfaces (TSFI) considered in + the functional specification. + + In summary, the TSFIs described in the functional + specification only include the calls made into a TSF by + external entities and responses to those calls. Calls made + by a TSF, which were not explicitly considered during + evaluation of the components, are described by the reliance + information provided to satisfy . + + + + + The objectives of this sub-activity are to determine + whether the developer's reliance evidence provides + sufficient information to determine that the necessary + functionality is available in the base component, and the + means by which that functionality is invoked. These are + provided in terms of a high-level description. + + + + + A dependent component whose TSF interacts with the base + component requires functionality provided by that base + component (e.g., remote authentication, remote audit data + storage). In these cases, those invoked services need to + be described for those charged with configuring the + composed TOE for end users. The rationale for requiring + this documentation is to aid integrators of the composed + TOE to determine what services in the base component might + have adverse effects on the dependent component, and to + provide information against which to determine the + compatibility of the components when applying the family. + + + + The evaluation evidence for this sub-activity is: + + + the composed ST; + + + the dependent component functional specification; + + + the dependent component design; + + + the dependent component architectural design; + + + the reliance information. + + + + + The developer shall provide reliance information of the + dependent component. + + + The reliance information shall describe the functionality of + the base component hardware, firmware and/or software that + is relied upon by the dependent component TSF. + + + The reliance information shall describe all interactions + through which the dependent component TSF requests services + from the base component. + + + The reliance information shall describe how the dependent + TSF protects itself from interference and tampering by the + base component. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check the reliance information to + determine that it describes the functionality of the + base dependent hardware, firmware and/or software that + is relied upon by the dependent component TSF. + + The evaluator assesses the description of the security + functionality that the dependent component TSF requires + to be provided by the base component's hardware, + firmware and software. The emphasis of this work unit is + on the level of detail of this description, rather than + on an assessment of the information's accuracy. (The + assessment of the accuracy of the information is the + focus of the next work unit.) + + This description of the base component's functionality + need not be any more detailed than the level of the + description of a component of the TSF, as would be + provided in the TOE Design () + + + + + The evaluator shall examine the reliance information to + determine that it accurately reflects the objectives + specified for the operational environment of the + dependent component. + + The reliance information contains the description of the + base component's security functionality relied upon by + the dependent component. To ensure that the reliance + information is consistent with the expectations of the + operational environment of the dependent component, the + evaluator compares the reliance information with the + statement of objectives for the environment in the ST + for the dependent component. + + For example, if the reliance information claims that the + dependent component TSF relies upon the base component + to store and protect audit data, yet other evaluation + evidence (e.g. the dependent component design) makes it + clear that the dependent component TSF itself is storing + and protecting the audit data, this would indicate an + inaccuracy. + + It should be noted that the objectives for the + operational environment may include objectives that can + be met by non-IT measures. While the services that the + base component environment is expected to provide may be + described in the description of IT objectives for the + operational environment in the dependent component ST, + it is not required that all such expectations on the + environment be described in the reliance + information. + + + + + The evaluator shall examine the reliance information to + determine that it describes all interactions between the + dependent component and the base component, through + which the dependent component TSF requests services from + the base component. + + The dependent component TSF may request services of the + base component that were not within the TSF of the base + component (see in CC Part + 3). + + The interfaces to the base component's functionality are + described at the same level as the description of the + interfaces to the dependent component TSF functionality, + as would be provided between subsystems in the TOE + design (). + + The purpose of describing the interactions between the + dependent component and the base component is to provide + an understanding of how the dependent component TSF + relies upon the base component for the provision of + services to support the operation of security + functionality of the dependent component. These + interactions do not need to be characterised at the + implementation level (e.g. parameters passed from one + routine in a component to a routine in another + component), but the data elements identified for a + particular component that are going to be used by + another component should be covered in this + description. The statement should help the reader + understand in general why the interaction is + necessary. + + Accuracy and completeness of the interfaces is based on + the security functionality that the TSF requires to be + provided by the base component, as assessed in work + units and . It should be possible to + map all of the functionality described in the earlier + work units to the interfaces identified in this work + unit, and vice versa. An interface that does not + correspond to described functionality would also + indicate an inadequacy. + + + + The evaluator shall examine the reliance information to + determine that it describes how the dependent TSF protects + itself from interference and tampering by the base + component. + + The description of how the dependent component protects + itself from interference and tampering by the base + component is to be provided at the same level of detail + as necessary for . + + + + + + + The objectives of this sub-activity are to determine + whether the developer's reliance evidence provides + sufficient information to determine that the necessary + functionality is available in the base component, and the + means by which that functionality is invoked. This is + provided in terms of the interfaces between the + dependent and base component and the return values from + those interfaces called by the dependent component. + + + + + A dependent component whose TSF interacts with the base + component requires functionality provided by that base + component (e.g., remote authentication, remote audit data + storage). In these cases, those invoked services need to + be described for those charged with configuring the + composed TOE for end users. The rationale for requiring + this documentation is to aid integrators of the composed + TOE to determine what services in the base component might + have adverse effects on the dependent component, and to + provide information against which to determine the + compatibility of the components when applying the family. + + + + The evaluation evidence for this sub-activity is: + + + the composed ST; + + + the dependent component functional specification; + + + the dependent component design; + + + the dependent component implementation representation; + + + the dependent component architectural design; + + + the reliance information. + + + + + The developer shall provide reliance information of the + dependent component. + + + The reliance information shall describe the functionality of + the base component hardware, firmware and/or software that + is relied upon by the dependent component TSF. + + + The reliance information shall describe all interactions + through which the dependent component TSF requests services + from the base component. + + + The reliance information shall describe each interaction in + terms of the interface used and the return values from those + interfaces. + + + The reliance information shall describe how the dependent + TSF protects itself from interference and tampering by the + base component. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check the reliance information to + determine that it describes the functionality of the + base dependent hardware, firmware and/or software that + is relied upon by the dependent component TSF. + + The evaluator assesses the description of the security + functionality that the dependent component TSF requires + to be provided by the base component's hardware, + firmware and software. The emphasis of this work unit is + on the level of detail of this description, rather than + on an assessment of the information's accuracy. (The + assessment of the accuracy of the information is the + focus of the next work unit.) + + This description of the base component's functionality + need not be any more detailed than the level of the + description of a component of the TSF, as would be + provided in the TOE Design () + + + + + The evaluator shall examine the reliance information to + determine that it accurately reflects the objectives + specified for the operational environment of the + dependent component. + + The reliance information contains the description of the + base component's security functionality relied upon by + the dependent component. To ensure that the reliance + information is consistent with the expectations of the + operational environment of the dependent component, the + evaluator compares the reliance information with the + statement of objectives for the environment in the ST + for the dependent component. + + For example, if the reliance information claims that the + dependent component TSF relies upon the base component + to store and protect audit data, yet other evaluation + evidence (e.g. the dependent component design) makes it + clear that the dependent component TSF itself is storing + and protecting the audit data, this would indicate an + inaccuracy. + + It should be noted that the objectives for the + operational environment may include objectives that can + be met by non-IT measures. While the services that the + base component environment is expected to provide may be + described in the description of IT objectives for the + operational environment in the dependent component ST, + it is not required that all such expectations on the + environment be described in the reliance + information. + + + + + The evaluator shall examine the reliance information to + determine that it describes all interactions between the + dependent component and the base component, through + which the dependent component TSF requests services from + the base component. + + The dependent component TSF may request services of the + base component that were not within the TSF of the base + component (see Annex in CC Part + 3). + + The interfaces to the base component's functionality are + described at the same level as the description of the + interfaces to the dependent component TSF functionality, + as would be provided between subsystems in the TOE + design (). + + The purpose of describing the interactions between the + dependent component and the base component is to provide + an understanding of how the dependent component TSF + relies upon the base component for the provision of + services to support the operation of security + functionality of the dependent component. These + interactions do not need to be characterised at the + implementation level (e.g. parameters passed from one + routine in a component to a routine in another + component), but the data elements identified for a + particular component that are going to be used by + another component should be covered in this + description. The statement should help the reader + understand in general why the interaction is + necessary. + + Accuracy and completeness of the interfaces is based on + the security functionality that the TSF requires to be + provided by the base component, as assessed in work + units and . It should be possible to + map all of the functionality described in the earlier + work units to the interfaces identified in this work + unit, and vice versa. An interface that does not + correspond to described functionality would also + indicate an inadequacy. + + + + The reliance information shall describe each interaction + in terms of the interface used and the return values + from those interfaces. + + The identification of the interfaces used by the + dependent component TSF when making services requests of + the base component allows an integrator to determine + whether the base component provides all the necessary + corresponding interfaces. This understanding is further + gained through the specification of the return values + expected by the dependent component. The evaluator + ensures that interfaces are described for each + interaction specified (as analysed in ). + + + + The evaluator shall examine the reliance information to + determine that it describes how the dependent TSF protects + itself from interference and tampering by the base + component. + + The description of how the dependent component protects + itself from interference and tampering by the base + component is to be provided at the same level of detail + as necessary for . + + + + + + + This family requires that testing of composed TOE and + testing of the base component, as used in the composed TOE, + is performed. + + + + The family details + requirements for testing to demonstrate that the composed + TOE operates as specified in the composed TOE SFRs and the + base component interfaces match the design descriptions as + provided in the development information (). Testing evidence is to be provided of all + SFRs specified in the composed TOE ST and to exercise all + base component interfaces used by the dependent component, + as identified in . + + + + The components in this family are levelled on the basis of + increasing rigour of interface testing and increasing rigour + of the analysis of the sufficiency of the tests to + demonstrate that the composed TSF operates in accordance + with the reliance information and the composed TOE + SFRs. + + + + There are two distinct aspects of testing associated with + this family: + + + testing of the interfaces between the base component and + the dependent component, which the dependent component + rely upon for enforcement of security functionality, to + demonstrate their compatibility; + + + testing of the composed TOE to demonstrate that the TOE + behaves in accordance with the SFRs for the composed + TOE. + + + + If the test configurations used during evaluation of the + dependent component included use of the base component as a + ``platform'' and the test analysis sufficiently demonstrates + that the TSF behaves in accordance with the SFRs, the + developer need perform no further testing of the composed + TOE functionality. However, if the base component was not + used in the testing of the dependent component, or the + configuration of either component varied, then the developer + is to perform testing of the composed TOE. This may take + the form of repeating the dependent component developer + testing of the dependent component, provided this adequately + demonstrates the composed TOE TSF behaves in accordance with + the SFRs. + + The developer is to provide evidence of testing the base + component interfaces used in the composition. The operation + of base component TSFIs would have been tested as part of + the activities during + evaluation of the base component. Therefore, provided the + appropriate interfaces were included within the test sample + of the base component evaluation and it was determined in + that the base component is + operating in accordance with the base component evaluated + configuration, with all security functionality required by + the dependent component included in the TSF, the evaluator + action may be met + through reuse of the base component verdicts. + + If this is not the case, the base component interfaces used + relevant to the composition that are affected by any + variations to the evaluated configuration and any additional + security functionally will be tested to ensure they + demonstrate the expected behaviour. The expected behaviour + to be tested is that described in the reliance information + ( evidence). + + + + + + + The objective of this component is to ensure that each + interface of the base component, on which the dependent + component relies, is tested. + + + + The objective of this sub-activity is to determine whether + the developer correctly performed and documented tests for + each of the base component interfaces on which the + dependent component relies. As part of this determination + the evaluator repeats a sample of the tests performed by + the developer and performs any additional tests required + to ensure the expected behaviour of all composed TOE SFRs + and interfaces of the base component relied upon by the + dependent component is demonstrated. + + + + The evaluation evidence for this sub-activity is: + + + the composed TOE suitable for testing; + + + the composed TOE testing evidence; + + + the reliance information; + + + the development information. + + + + + The developer shall provide composed TOE test documentation. + + + The developer shall provide base component interface test + documentation. + + + The developer shall provide the composed TOE for testing. + + + The developer shall provide an equivalent set of resources + to those that were used in the base component developer's + functional testing of the base component. + + + The composed TOE and base component interface test + documentation shall consist of test plans, expected test + results and actual test results. + + + The test documentation from the developer execution of the + composed TOE tests shall demonstrate that the TSF behaves as + specified. + + + The test documentation from the developer execution of the + base component interface tests shall demonstrate that the + base component interface relied upon by the dependent + component behaves as specified. + + + The base component shall be suitable for testing. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the composed TOE test + documentation to determine that it consists of test + plans, expected test results and actual test + results. + + This work unit may be satisfied by provision of the test + evidence from the evaluation of the dependent component + if the base component was used to satisfy the + requirements for IT in the operational environment of + the dependent component. + + All work units necessary for the satisfaction of will be applied to + determine: + + + that the test documentation consist of test plans + expected test results and actual test + results; + + that the test documentation contains the information + necessary to ensure the tests are repeatable; + + the level of developer effort that was applied to + testing of the base component. + + + + + The evaluator shall examine the base component interface + test documentation to determine that it consists of test + plans, expected test results and actual test + results. + + This work unit may be satisfied by provision of the test + evidence from the evaluation of the base component for + those interfaces relied upon in the composed TOE by the + dependent component are TSFIs of the successfully + evaluated base component. The determination of whether + the interfaces of the base component relied upon by the + dependent component were in fact TSFIs of the evaluated + base component is made during the activity. + + All work units necessary for the satisfaction of will be applied to + determine: + + + that the test documentation consist of test plans + expected test results and actual test + results; + + that the test documentation contains the information + necessary to ensure the tests are repeatable; + + the level of developer effort that was applied to + testing of the base component. + + + + + The evaluator shall examine the test documentation to + determine that the developer execution of the composed + TOE tests shall demonstrate that the TSF behaves as + specified. + + The evaluator should construct a mapping between the + tests described in the test plan and the SFRs specified + for the composed TOE to identify which SFRs have been + tested by the developer. + + Guidance on this work unit can be found in: + + + Clause . + + Clause . + + + The outputs from the successful execution of the tests + (as assessed for can + be compared with the mapping to determine that the SFRs + of the composed TOE, as tested by the developer, behave + as expected. + + + + + The evaluator shall examine the test documentation to + determine that the developer execution of the base + component interface tests shall demonstrate that the + base component interfaces relied upon by the dependent + component behave as specified. + + The evaluator should construct a mapping between the + tests described in the test plan and the interfaces of + the base component relied upon by the dependent + component (as specified in the reliance information, + examined under ) to + identify which base component interfaces have been + tested by the developer. + + Guidance on this work unit can be found in: + + + Clause . + + Clause . + + + The outputs from the successful execution of the tests + (as assessed for can + be compared with the mapping to determine that the + interfaces of the base component, as tested by the + developer, behave as expected. + + + + + The evaluator shall examine the composed TOE to + determine that it has been installed properly and is in + a known state. + + To determine that the composed TOE has been installed + properly and is in a known state the and work units will be + applied to the TOE provided by the developer for + testing. + + + + + The evaluator shall examine the set of resources + provided by the developer to determine that they are + equivalent to the set of resources used by the base + component developer to functionally test the base + component. + + To determine that the set of resources provided are + equivalent to those used to functionally test the base + component as used in the composed TOE, the work unit will be + applied. + + + + The evaluator shall execute a sample of test in the test + documentation to verify the developer test results. + + + The evaluator shall perform testing in accordance with , for a subset of the SFRs + specified in the composed security target, to verify the + developer test results. + + The evaluator will apply all work units necessary for + the satisfaction of , reporting in the ETR for the composed TOE + all analysis, results and verdicts as dictated by the + associated work units. + + + + The evaluator shall test a subset of the TSF interfaces of + the composed TOE to confirm that the composed TSF operates + as specified. + + + The evaluator shall perform testing in accordance with , for a subset of the SFRs + specified in the composed security target, to confirm that the + TSF operates as specified. + + The evaluator will apply all work units necessary for + the satisfaction of , reporting in the ETR for the composed TOE + all analysis, results and verdicts as dictated by the + work units. + + When selecting interfaces of the TSF of the composed TOE + to test, the evaluator should take into account any + modifications to the components from the evaluated + version or configuration. Modifications to the component + from that evaluated may include patches introduced, a + different configuration as a result of modified guidance + documentation, reliance an additional portion of the + component that was not within the TSF of the + component. These modifications will have been identified + during the + activity. + + + + + + + + + + The objective of this component is to ensure that each + interface of the base component, on which the dependent + component relies, is tested. + + + + The objective of this sub-activity is to determine whether + the developer correctly performed and documented tests for + each of the base component interfaces on which the + dependent component relies. As part of this determination + the evaluator repeats a sample of the tests performed by + the developer and performs any additional tests required + to fully demonstrate the expected behaviour of the + composed TOE and the interfaces of the base component + relied upon by the dependent component. + + + + The evaluation evidence for this sub-activity is: + + + the composed TOE suitable for testing; + + + the composed TOE testing evidence; + + + the reliance information; + + + the development information. + + + + + The developer shall provide composed TOE test documentation. + + + The developer shall provide base component interface test + documentation. + + + The developer shall provide the composed TOE for testing. + + + The developer shall provide an equivalent set of resources + to those that were used in the base component developer's + functional testing of the base component. + + + The composed TOE and base component interface test + documentation shall consist of test plans, expected test + results and actual test results. + + + The test documentation from the developer execution of the + composed TOE tests shall demonstrate that the TSF behaves as + specified and is complete. + + + The test documentation from the developer execution of the + base component interface tests shall demonstrate that the + base component interface relied upon by the dependent + component behaves as specified and is complete. + + + The base component shall be suitable for testing. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the composed TOE test + documentation to determine that it consists of test + plans, expected test results and actual test + results. + + This work unit may be satisfied by provision of the test + evidence from the evaluation of the dependent component + if the base component was used to satisfy the + requirements for IT in the operational environment of + the dependent component. + + All work units necessary for the satisfaction of will be applied to + determine: + + + that the test documentation consist of test plans + expected test results and actual test + results; + + that the test documentation contains the information + necessary to ensure the tests are repeatable; + + the level of developer effort that was applied to + testing of the base component. + + + + + The evaluator shall examine the base component interface + test documentation to determine that it consists of test + plans, expected test results and actual test + results. + + This work unit may be satisfied by provision of the test + evidence from the evaluation of the base component for + those interfaces relied upon in the composed TOE by the + dependent component are TSFIs of the successfully + evaluated base component. The determination of whether + the interfaces of the base component relied upon by the + dependent component were in fact TSFIs of the evaluated + base component is made during the activity. + + All work units necessary for the satisfaction of will be applied to + determine: + + + that the test documentation consist of test plans + expected test results and actual test + results; + + that the test documentation contains the information + necessary to ensure the tests are repeatable; + + the level of developer effort that was applied to + testing of the base component. + + + + + + + The evaluator shall examine the test documentation to + determine that it provides accurate correspondence + between the tests in the test documentation relating to + the testing of the composed TOE and the composed TOE + SFRs in the composed TOE security target. + + A simple cross-table may be sufficient to show test + correspondence. The identification of correspondence + between the tests and SFRs presented in the test + documentation has to be unambiguous. + + + + + The evaluator shall examine the test documentation to + determine that the developer execution of the composed + TOE tests shall demonstrate that the TSF behaves as + specified. + + Guidance on this work unit can be found in: + + + Clause . + + Clause . + + + + The outputs from the successful execution of the tests + (as assessed for can + be compared with the mapping to determine that the SFRs + of the composed TOE, as tested by the developer, behave + as expected. + + + + + The evaluator shall examine the test documentation to + determine that it provides accurate correspondence + between the tests in the test documentation relating to + the testing of the base component interfaces relied upon + by the dependent component and the interfaces specified + in the reliance information. + + A simple cross-table may be sufficient to show test + correspondence. The identification of correspondence + between the tests and interfaces presented in the test + documentation has to be unambiguous. + + + + + The evaluator shall examine the test documentation to + determine that the developer execution of the base + component interface tests shall demonstrate that the + base component interfaces relied upon by the dependent + component behave as specified. + + Guidance on this work unit can be found in: + + + Clause . + + Clause . + + + The outputs from the successful execution of the tests + (as assessed for can + be compared with the mapping to determine that the + interfaces of the base component, as tested by the + developer, behave as expected. + + + + + The evaluator shall examine the composed TOE to + determine that it has been installed properly and is in + a known state. + + To determine that the composed TOE has been installed + properly and is in a known state the and work units will be + applied to the TOE provided by the developer for + testing. + + + + + The evaluator shall examine the set of resources + provided by the developer to determine that they are + equivalent to the set of resources used by the base + component developer to functionally test the base + component. + + To determine that the set of resources provided are + equivalent to those used to functionally test the base + component as used in the composed TOE, the work unit will be + applied. + + + + The evaluator shall execute a sample of test in the test + documentation to verify the developer test results. + + + The tests are to be selected and executed in accordance + with , to + demonstrate the correct behaviour of the SFRs specified + in the composed TOE security target. + + The evaluator will apply all work units necessary for + the satisfaction of , reporting in the ETR for the composed TOE + all analysis, results and verdicts as dictated by the + associated work units. + + + + The evaluator shall test a subset of the TSF interfaces of + the composed TOE to confirm that the composed TSF operates + as specified. + + + The evaluator shall perform testing in accordance with , for a subset of the SFRs + specified in the composed security target, to confirm that the + TSF operates as specified. + + The evaluator will apply all work units necessary for + the satisfaction of , reporting in the ETR for the composed TOE + all analysis, results and verdicts as dictated by the + work units. + + When selecting interfaces of the TSF of the composed TOE + to test, the evaluator should take into account any + modifications to the components from the evaluated + version or configuration. Modifications to the component + from that evaluated may include patches introduced, a + different configuration as a result of modified guidance + documentation, reliance an additional portion of the + component that was not within the TSF of the + component. These modifications will have been identified + during the + activity. + + + + The evaluator shall perform testing, in accordance with + , for a subset of the + interfaces to the base component to confirm they operate + as specified. + + The evaluator will apply all work units necessary for + the satisfaction of , reporting in the ETR for the composed TOE + all analysis, results and verdicts as dictated by the + work units. + + When selecting interfaces of the base component to test, + the evaluator should take into account any modifications + to the base component from the evaluated version or + configuration. In particular, the evaluator should + consider the development of tests to demonstrate the + correct behaviour of interfaces of the base component + that were not considered during the evaluation of the + base component. These additional interfaces and other + modifications to the base component will have been + identified during the + activity. + + + + + + + + This family calls for an analysis of vulnerability + information available in the public domain and of + vulnerabilities that may be introduced as a result of the + composition. + + + + The vulnerability analysis in includes determination of two different + aspects of resistance by the composed TOE, namely: + + + Residual vulnerabilities in the base and dependent + components remain unexploitable in the operational + environment of the composed TOE; + + The composed TOE is resistant to attackers with a given + level of attack potential. + + + + The components in this family are levelled on the basis of + increasing scrutiny of vulnerability information from the + public domain and independent vulnerability analysis. + + + + The developer will provide details of any residual + vulnerabilities reported during evaluation of the + components. These may be gained from the component + developers or evaluation reports for the components. These + will be used as inputs into the evaluator's vulnerability + analysis of the composed TOE in the operational + environment. + + + The operational environment of the composed TOE is examined + to ensure that the assumptions and objectives for the + component operational environment (specified in each + component ST) are satisfied in the composed TOE. An initial + analysis of the consistency of assumptions and objectives + between the components and the composed TOE STs will have + been performed during the conduct of the activities for the composed TOE. However, this + analysis is revisited with the knowledge acquired during the + , and the + activities to ensure that, for example, assumptions of the + dependent component that were addressed by the environment + in the dependent component ST are not reintroduced as a + result of composition (i.e. that the base component + adequately addresses the assumptions of the dependent + component ST in the composed TOE). + + A search by the evaluator for issues in each component will + identify potential vulnerabilities reported in the public + domain since completion of the evaluation of the components. + Any potential vulnerabilities will then be subject to + testing. + + If the base component used in the composed TOE has been the + subject of assurance continuity activities since + certification, the evaluator will consider during the + composed TOE vulnerability analysis activities the changes + made in base component. + + + + + + The objective of this sub-activity is to determine whether + the composed TOE, in its operational environment, has + easily exploitable vulnerabilities. + + The developer provides details of any residual + vulnerabilities reported from evaluation of the + components. The evaluator performs an analysis of the + disposition the residual vulnerabilities reported and also + performs a search of the public domain, to identify any + new potential vulnerabilities in the components + (i.e. those issues that have been reported in the public + domain since evaluation of the base component). The + evaluator then performs penetration testing to demonstrate + that the potential vulnerabilities cannot be exploited in + the TOE, in its operational environment, by an attacker + with basic attack potential. + + + + See the application notes for . + + + + The evaluation evidence for this sub-activity is: + + + the composed TOE suitable for testing; + + + the composed ST; + + + the composition rationale; + + + the guidance documentation; + + + information publicly available to support the + identification of possible security vulnerabilities; + + + residual vulnerabilities reported during evaluation of + each component. + + + + + The developer shall provide the composed TOE for testing. + + + The composed TOE shall be suitable for testing. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + The evaluator shall examine the composed TOE to + determine that it has been installed properly and is in + a known state. + + To determine that the composed TOE has been installed + properly and is in a known state the and work units will be + applied to the composed TOE. + + If the assurance package includes a component from the + family, then the + evaluator may refer to the result of the work unit *-1 to demonstrate this has been + satisfied. + + + + The evaluator shall examine the composed TOE + configuration to determine that any assumptions and + objectives in the STs the components relating to IT + entities for are fulfilled by the other + components. + + The STs for the component may include assumptions about + other components that may use the component to which the + ST relates, e.g. the ST for an operating system used as + a base component may include an assumption that any + applications loaded on the operating system do not run + in privileged mode. These assumptions and objectives are + to be fulfilled by other components in the composed + TOE. + + + + The evaluator shall perform an analysis to determine that + any residual vulnerabilities identified for the base and + dependent components are not exploitable in the composed TOE + in its operational environment. + + + The evaluator shall examine the residual vulnerabilities + from the base component evaluation to determine that + they are not exploitable in the composed TOE in its + operational environment. + + The list of vulnerabilities identified in the product + during the evaluation of the base component, which were + demonstrated to be non-exploitable in the base + component, is to be used as an input into this + activity. The evaluator will determine that the + premise(s) on which a vulnerability was deemed to be + non-exploitable is upheld in the composed TOE, or + whether the combination has re-introduced the potential + vulnerability. For example, if during evaluation of the + base component it was assumed that a particular + operating system service was disabled, which is enabled + in the composed TOE evaluation, any potential + vulnerabilities relating to that service previously + scoped out should now be considered. + + Also, this list of known, non-exploitable + vulnerabilities resulting from the evaluation of the + base component should be considered in the light of any + known, non-exploitable vulnerabilities for the other + components (e.g. dependent component) within the + composed TOE. This is to consider the case where a + potential vulnerability that is non-exploitable in + isolation is exploitable when integrated with an IT + entity containing another potential + vulnerability. + + + + The evaluator shall examine the residual vulnerabilities + from the dependent component evaluation to determine + that they are not exploitable in the composed TOE in its + operational environment. + + The list of vulnerabilities identified in the product + during the evaluation of the dependent component, which + were demonstrated to be non-exploitable in the dependent + component, is to be used as an input into this + activity. The evaluator will determine that the + premise(s) on which a vulnerability was deemed to be + non-exploitable is upheld in the composed TOE, or + whether the combination has re-introduced the potential + vulnerability. For example, if during evaluation of the + dependent component it was assumed that IT meeting the + operational environment requirements would not return a + certain value in response to a service request, which is + provided by the base component in the composed TOE + evaluation, any potential vulnerabilities relating to + that return value previously scoped out should now be + considered. + + Also, this list of known, non-exploitable + vulnerabilities resulting from the evaluation of the + dependent component should be considered in the light of + any known, non-exploitable vulnerabilities for the other + components (e.g. base component) within the composed + TOE. This is to consider the case where a potential + vulnerability that is non-exploitable in isolation is + exploitable when integrated with an IT entity containing + another potential vulnerability. + + + + The evaluator shall perform a search of public domain + sources to identify possible vulnerabilities arising from + use of the base and dependent components in the composed TOE + operational environment. + + + The evaluator shall examine the sources of information + publicly available to support the identification of + possible security vulnerabilities in the base component + that have become known since the completion of + evaluation of the base component. + + The evaluator will use the information in the public + domain as described in to search for vulnerabilities in the base + component. + + Those potential vulnerabilities that were publicly + available prior to the evaluation of the base component + do not have to be further investigated unless it is + apparent to the evaluator that the attack potential + required by an attacker to exploit the potential + vulnerability has been significantly reduced. This may + be through the introduction of some new technology since + the base component evaluation that means the + exploitation of the potential vulnerability has been + simplified. + + + + The evaluator shall examine the sources of information + publicly available to support the identification of + possible security vulnerabilities in the dependent + component that have become known since the completion of + the dependent component evaluation. + + The evaluator will use the information in the public + domain as described in to search for vulnerabilities in the + dependent component. + + Those potential vulnerabilities that were publicly + available prior to the evaluation of the dependent + component do not have to be further investigated unless + it is apparent to the evaluator that the attack + potential required by an attacker to exploit the + potential vulnerability has been significantly + reduced. This may be through the introduction of some + new technology since evaluation of the dependent + component that means the exploitation of the potential + vulnerability has been simplified. + + + + The evaluator shall record in the ETR the identified + potential security vulnerabilities that are candidates + for testing and applicable to the composed TOE in its + operational environment. + + The ST, guidance documentation and functional + specification are used to determine whether the + vulnerabilities are relevant to the composed TOE in its + operational environment. + + The evaluator records any reasons for exclusion of + vulnerabilities from further consideration if the + evaluator determines that the vulnerability is not + applicable in the operational environment. Otherwise the + evaluator records the potential vulnerability for + further consideration. + + A list of potential vulnerabilities applicable to the + composed TOE in its operational environment, which can + be used as an input into penetration testing activities + (i.e. ), shall be + reported in the ETR by the evaluators. + + + + The evaluator shall conduct penetration testing, based on + the identified vulnerabilities, to demonstrate that the + composed TOE is resistant to attacks by an attacker with + basic attack potential. + + + The evaluator shall conduct penetration testing as + detailed for . + + The evaluator will apply all work units necessary for + the satisfaction of evaluator action , reporting in the ETR + for the composed TOE all analysis and verdicts as + dictated by the work units. + + The evaluator will also apply the work units for the + evaluator action + to determine that the composed TOE provided by the + developer is suitable for testing. + + + + + + + + + The objective of this sub-activity is to determine whether + the composed TOE, in its operational environment, has + vulnerabilities exploitable by attackers possessing basic + attack potential. + + The developer provides an analysis of the disposition of + any residual vulnerabilities reported for the components + and of any vulnerabilities introduced through the + combination of the base and dependent components. The + evaluator performs a search of the public domain to + identify any new potential vulnerabilities in the + components (i.e. those issues that have been reported in + the public domain since the completion of the evaluation + of the components). The evaluator will also perform an + independent vulnerability analysis of the composed TOE and + penetration testing. + + + + See the application notes for . + + + + The evaluation evidence for this sub-activity is: + + + the composed TOE suitable for testing; + + + the composed ST; + + + the composition rationale; + + the reliance information; + + + the guidance documentation; + + + information publicly available to support the + identification of possible security vulnerabilities. + + + residual vulnerabilities reported during evaluation of + each component. + + + + + The developer shall provide the composed TOE for testing. + + + The composed TOE shall be suitable for testing. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + The evaluator shall examine the composed TOE to + determine that it has been installed properly and is in + a known state. + + To determine that the composed TOE has been installed + properly and is in a known state the and work units will be + applied to the composed TOE. + + If the assurance package includes family, then the evaluator may refer to the + result of the work unit *-1 to demonstrate this has been + satisfied. + + + + The evaluator shall examine the composed TOE + configuration to determine that any assumptions and + objectives in the STs the components relating to IT + entities for are fulfilled by the other + components. + + The STs for the component may include assumptions about + other components that may use the component to which the + ST relates, e.g. the ST for an operating system used as + a base component may include an assumption that any + applications loaded on the operating system do not run + in privileged mode. These assumptions and objectives are + to be fulfilled by other components in the composed + TOE. + + + + The evaluator shall perform an analysis to determine that + any residual vulnerabilities identified for the base and + dependent components are not exploitable in the composed TOE + in its operational environment. + + + The evaluator shall examine the residual vulnerabilities + from the base component evaluation to determine that + they are not exploitable in the composed TOE in its + operational environment. + + The list of vulnerabilities identified in the product + during the evaluation of the base component, which were + demonstrated to be non-exploitable in the base + component, is to be used as an input into this + activity. The evaluator will determine that the + premise(s) on which a vulnerability was deemed to be + non-exploitable is upheld in the composed TOE, or + whether the combination has re-introduced the potential + vulnerability. For example, if during evaluation of the + base component it was assumed that a particular + operating system service was disabled, which is enabled + in the composed TOE evaluation, any potential + vulnerabilities relating to that service previously + scoped out should now be considered. + + Also, this list of known, non-exploitable + vulnerabilities resulting from the evaluation of the + base component should be considered in the light of any + known, non-exploitable vulnerabilities for the other + components (e.g. dependent component) within the + composed TOE. This is to consider the case where a + potential vulnerability that is non-exploitable in + isolation is exploitable when integrated with an IT + entity containing another potential + vulnerability. + + + + The evaluator shall examine the residual vulnerabilities + from the dependent component evaluation to determine + that they are not exploitable in the composed TOE in its + operational environment. + + The list of vulnerabilities identified in the product + during the evaluation of the dependent component, which + were demonstrated to be non-exploitable in the dependent + component, is to be used as an input into this + activity. The evaluator will determine that the + premise(s) on which a vulnerability was deemed to be + non-exploitable is upheld in the composed TOE, or + whether the combination has re-introduced the potential + vulnerability. For example, if during evaluation of the + dependent component it was assumed that IT meeting the + operational environment requirements would not return a + certain value in response to a service request, which is + provided by the base component in the composed TOE + evaluation, any potential vulnerabilities relating to + that return value previously scoped out should now be + considered. + + Also, this list of known, non-exploitable + vulnerabilities resulting from the evaluation of the + dependent component should be considered in the light of + any known, non-exploitable vulnerabilities for the other + components (e.g. base component) within the composed + TOE. This is to consider the case where a potential + vulnerability that is non-exploitable in isolation is + exploitable when integrated with an IT entity containing + another potential vulnerability. + + + + The evaluator shall perform a search of public domain + sources to identify possible vulnerabilities arising from + use of the base and dependent components in the composed TOE + operational environment. + + + The evaluator shall examine the sources of information publicly + available to support the identification of possible security + vulnerabilities in the base component that have become known + since the completion of the base component evaluation. + + The evaluator will use the information in the public + domain as described in to search for vulnerabilities in the base + component. + + Those potential vulnerabilities that were publicly + available prior to the evaluation of the base component + do not have to be further investigated unless it is + apparent to the evaluator that the attack potential + required by an attacker to exploit the potential + vulnerability has been significantly reduced. This may + be through the introduction of some new technology since + the base component evaluation that means the + exploitation of the potential vulnerability has been + simplified. + + + + The evaluator shall examine the sources of information + publicly available to support the identification of + possible security vulnerabilities in the dependent + component that have become known since the completion of + the dependent component evaluation. + + The evaluator will use the information in the public domain as + described in to search for + vulnerabilities in the dependent component. + + Those potential vulnerabilities that were publicly + available prior to the evaluation of the dependent + component do not have to be further investigated unless + it is apparent to the evaluator that the attack + potential required by an attacker to exploit the + potential vulnerability has been significantly + reduced. This may be through the introduction of some + new technology since evaluation of the dependent + component that means the exploitation of the potential + vulnerability has been simplified. + + + + The evaluator shall record in the ETR the identified + potential security vulnerabilities that are candidates + for testing and applicable to the composed TOE in its + operational environment. + + The ST, guidance documentation and functional + specification are used to determine whether the + vulnerabilities are relevant to the composed TOE in its + operational environment. + + The evaluator records any reasons for exclusion of + vulnerabilities from further consideration if the + evaluator determines that the vulnerability is not + applicable in the operational environment. Otherwise the + evaluator records the potential vulnerability for + further consideration. + + A list of potential vulnerabilities applicable to the + composed TOE in its operational environment, which can + be used as an input into penetration testing activities + (), shall be + reported in the ETR by the evaluators. + + + + The evaluator shall perform an independent vulnerability + analysis of the composed TOE, using the guidance + documentation, reliance information and composition + rationale to identify potential vulnerabilities in the + composed TOE. + + + The evaluator shall conduct a search of the composed TOE + ST, guidance documentation, reliance information and + composition rationale to identify possible security + vulnerabilities in the composed TOE. + + The consideration of the components of the composed TOE + in the independent evaluator vulnerability analysis will + take a slightly different form to that documented in + for a component + evaluation, as it will not necessarily consider all + layers of design abstraction relevant to the assurance + package. These will have already been considered during + the evaluation of the components, but the evidence may + not be available for the composed TOE + evaluation. However, the general approach described in + the work units associated with is applicable and should form the basis of + the evaluator's search for potential vulnerabilities in + the composed TOE. + + A vulnerability analysis of the individual components + used in the composed TOE will have already been + performed during evaluation of the individual + components. The focus of the vulnerability analysis + during the composed TOE evaluation is to identify any + vulnerabilities introduced as a result of the + integration of the components or due to any changes in + the use of the components between the evaluated + component configuration to the composed TOE + configuration. + + The evaluator will use the understanding of the + component's construction as detailed in the reliance + information for the dependent component, and the + development information and composition rationale for + the base component, together with the dependent + component design information. This information will + allow the evaluator to gain an understanding of how the + base component and dependent component interact and + identify potential vulnerabilities that may be + introduced as a result of this interaction. + + The evaluator will consider any new guidance provided + for the installation, start-up and operation of the + composed TOE to identify any potential vulnerabilities + introduced through this revised guidance. + + If any of the individual components have been through + assurance continuity activities since the completion of + the component evaluation, the evaluator will consider + the patch(es) in the independent vulnerability + analysis. Information related to the change provided in + a public report of the assurance continuity activities + (e.g. Maintenance Report) will be the main source of + input material of the change. This will be supplemented + by any updates to the guidance documentation resulting + from the change and any information regarding the change + available in the public domain, e.g. vendor + website. + + Any risks identified due to the lack of evidence to + establish the full impact of any patches or deviations + in the configuration of a component from the evaluated + configuration are to be documented in the evaluator's + vulnerability analysis. + + + + The evaluator shall conduct penetration testing, based on + the identified vulnerabilities, to demonstrate that the + composed TOE is resistant to attacks by an attacker with + basic attack potential. + + + The evaluator shall conduct penetration testing as + detailed for . + + The evaluator will apply all work units necessary for + the satisfaction of evaluator action , reporting in the ETR + for the composed TOE all analysis and verdicts as + dictated by the work units. + + The evaluator will also apply the work units for the + evaluator action + to determine that the composed TOE provided by the + developer is suitable for testing. + + + + + + + + + The objective of this sub-activity is to determine whether the + composed TOE, in its operational environment, has + vulnerabilities exploitable by attackers possessing + Enhanced-Basic attack potential. + + The developer provides an analysis of the disposition of + any residual vulnerabilities reported for the components + and of any vulnerabilities introduced through the + combination of the base and dependent components. The + evaluator performs a search of the public domain to + identify any new potential vulnerabilities in the + components (i.e. those issues that have been reported in + the public domain since the completion of the component + evaluations). The evaluator will also perform an + independent vulnerability analysis of the composed TOE and + penetration testing. + + + + See the application notes for . + + + + The evaluation evidence for this sub-activity is: + + + the composed TOE suitable for testing; + + + the composed ST; + + + the composition rationale; + + + the reliance information; + + + the guidance documentation; + + + information publicly available to support the + identification of possible security vulnerabilities. + + + residual vulnerabilities reported during evaluation of + each component. + + + + + The developer shall provide the composed TOE for testing. + + + The composed TOE shall be suitable for testing. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + The evaluator shall examine the composed TOE to + determine that it has been installed properly and is in + a known state. + + To determine that the composed TOE has been installed + properly and is in a known state the and work units will be + applied to the composed TOE. + + If the assurance package includes family, then the evaluator may refer to the + result of the work unit *-1 to demonstrate this has been + satisfied. + + + + The evaluator shall examine the composed TOE + configuration to determine that any assumptions and + objectives in the STs the components relating to IT + entities for are fulfilled by the other + components. + + The STs for the component may include assumptions about + other components that may use the component to which the + ST relates, e.g. the ST for an operating system used as + a base component may include an assumption that any + applications loaded on the operating system do not run + in privileged mode. These assumptions and objectives are + to be fulfilled by other components in the composed + TOE. + + + + The evaluator shall perform an analysis to determine that + any residual vulnerabilities identified for the base and + dependent components are not exploitable in the composed TOE + in its operational environment. + + + The evaluator shall examine the residual vulnerabilities + from the base component evaluation to determine that + they are not exploitable in the composed TOE in its + operational environment. + + The list of vulnerabilities identified in the product + during the evaluation of the base component, which were + demonstrated to be non-exploitable in the base + component, is to be used as an input into this + activity. The evaluator will determine that the + premise(s) on which a vulnerability was deemed to be + non-exploitable is upheld in the composed TOE, or + whether the combination has re-introduced the potential + vulnerability. For example, if during evaluation of the + base component it was assumed that a particular + operating system service was disabled, which is enabled + in the composed TOE evaluation, any potential + vulnerabilities relating to that service previously + scoped out should now be considered. + + Also, this list of known, non-exploitable + vulnerabilities resulting from the evaluation of the + base component should be considered in the light of any + known, non-exploitable vulnerabilities for the other + components (e.g. dependent component) within the + composed TOE. This is to consider the case where a + potential vulnerability that is non-exploitable in + isolation is exploitable when integrated with an IT + entity containing another potential + vulnerability. + + + + The evaluator shall examine the residual vulnerabilities + from the dependent component evaluation to determine + that they are not exploitable in the composed TOE in its + operational environment. + + The list of vulnerabilities identified in the product + during the evaluation of the dependent component, which + were demonstrated to be non-exploitable in the dependent + component, is to be used as an input into this + activity. The evaluator will determine that the + premise(s) on which a vulnerability was deemed to be + non-exploitable is upheld in the composed TOE, or + whether the combination has re-introduced the potential + vulnerability. For example, if during evaluation of the + dependent component it was assumed that IT meeting the + operational environment requirements would not return a + certain value in response to a service request, which is + provided by the base component in the composed TOE + evaluation, any potential vulnerabilities relating to + that return value previously scoped out should now be + considered. + + Also, this list of known, non-exploitable + vulnerabilities resulting from the evaluation of the + dependent component should be considered in the light of + any known, non-exploitable vulnerabilities for the other + components (e.g. base component) within the composed + TOE. This is to consider the case where a potential + vulnerability that is non-exploitable in isolation is + exploitable when integrated with an IT entity containing + another potential vulnerability. + + + + The evaluator shall perform a search of public domain + sources to identify possible vulnerabilities arising from + use of the base and dependent components in the composed TOE + operational environment. + + + The evaluator shall examine the sources of information publicly + available to support the identification of possible security + vulnerabilities in the base component that have become known + since the completion of the base component evaluation. + + The evaluator will use the information in the public + domain as described in to search for vulnerabilities in the base + component. + + Those potential vulnerabilities that were publicly + available prior to the evaluation of the base component + do not have to be further investigated unless it is + apparent to the evaluator that the attack potential + required by an attacker to exploit the potential + vulnerability has been significantly reduced. This may + be through the introduction of some new technology since + the base component evaluation that means the + exploitation of the potential vulnerability has been + simplified. + + + + The evaluator shall examine the sources of information + publicly available to support the identification of + possible security vulnerabilities in the dependent + component that have become known since completion of the + dependent component evaluation. + + The evaluator will use the information in the public domain as + described in to search for + vulnerabilities in the dependent component. + + Those potential vulnerabilities that were publicly + available prior to the evaluation of the dependent + component do not have to be further investigated unless + it is apparent to the evaluator that the attack + potential required by an attacker to exploit the + potential vulnerability has been significantly + reduced. This may be through the introduction of some + new technology since evaluation of the dependent + component that means the exploitation of the potential + vulnerability has been simplified. + + + + The evaluator shall record in the ETR the identified + potential security vulnerabilities that are candidates + for testing and applicable to the composed TOE in its + operational environment. + + The ST, guidance documentation and functional + specification are used to determine whether the + vulnerabilities are relevant to the composed TOE in its + operational environment. + + The evaluator records any reasons for exclusion of + vulnerabilities from further consideration if the + evaluator determines that the vulnerability is not + applicable in the operational environment. Otherwise the + evaluator records the potential vulnerability for + further consideration. + + A list of potential vulnerabilities applicable to the + composed TOE in its operational environment, which can + be used as an input into penetration testing activities + (), shall be + reported in the ETR by the evaluators. + + + + The evaluator shall perform an independent vulnerability + analysis of the composed TOE, using the guidance + documentation, reliance information and composition + rationale to identify potential vulnerabilities in the + composed TOE. + + + The evaluator shall conduct a search of the composed TOE + ST, guidance documentation, reliance information and + composition rationale to identify possible security + vulnerabilities in the composed TOE. + + The consideration of the components in the independent + evaluator vulnerability analysis will take a slightly + different form to that documented in for a component + evaluation, as it will not necessarily consider all + layers of design abstraction relevant to the assurance + package. These will have already been considered during + the evaluation of the base component, but the evidence + may not be available for the composed TOE + evaluation. However, the general approach described in + the work units associated with is applicable and should form the basis of + the evaluator's search for potential vulnerabilities in + the composed TOE. + + A vulnerability analysis of the individual components + used in the composed TOE will have already been + performed during evaluation of the components. The focus + of the vulnerability analysis during the composed TOE + evaluation is to identify any vulnerabilities introduced + as a result of the integration of the components or due + to any changes in the use of the components between the + configuration of the component determined during the + component evaluation and the composed TOE + configuration. + + The evaluator will use the understanding of the + component's construction as detailed in the reliance + information for the dependent component, and the + composition rationale and development information for + the base component, together with the dependent + component design information. This information will + allow the evaluator to gain an understanding of how the + base component and dependent component interact. + + The evaluator will consider any new guidance provided + for the installation, start-up and operation of the + composed TOE to identify any potential vulnerabilities + introduced through this revised guidance. + + If any of the individual components have been through + assurance continuity activities since the completion of + the component evaluation, the evaluator will consider + the patch in the independent vulnerability + analysis. Information related to the change provided in + a public report of the assurance continuity activities + (e.g. Maintenance Report). This will be supplemented by + any updates to the guidance documentation resulting from + the change and any information regarding the change + available in the public domain, e.g. vendor + website. + + Any risks identified due to the lack of evidence to + establish the full impact of any patches or deviations + in the configuration of a component from the evaluated + configuration are to be documented in the evaluator's + vulnerability analysis. + + + + The evaluator shall conduct penetration testing, based on the + identified vulnerabilities, to demonstrate that the composed TOE + is resistant to attacks by an attacker with Enhanced-Basic + attack potential. + + The evaluator shall conduct penetration testing as detailed + for . + The evaluator will apply all work units necessary for the + satisfaction of evaluator action , reporting in the ETR for the composed TOE all + analysis and verdicts as dictated by the work units. + The evaluator will also apply the work units for the + evaluator action to + determine that the composed TOE provided by the developer is + suitable for testing. + + + + + + + The requirements of the Development class provide information + about the TOE. The knowledge obtained by this information is + used as the basis for conducting vulnerability analysis and + testing upon the TOE, as described in the and classes. + + The Development class encompasses six families of requirements + for structuring and representing the TSF at various levels and + varying forms of abstraction. These families include: + + requirements for the description (at the various + levels of abstraction) of the design and implementation of + the SFRs (, , ) + requirements for the description of the + architecture-oriented features of domain separation, TSF + self-protection and non-bypassability of the security + functionality () + requirements for a security policy model and for correspondence + mappings between security policy model and the functional + specification () + requirements on the internal structure of the TSF, + which covers aspects such as modularity, layering, and + minimisation of complexity () + + When documenting the security functionality of a TOE, there + are two properties that need to be demonstrated. The first + property is that the security functionality works correctly; + that is, it performs as specified. The second property, and + one that is arguably harder to demonstrate, is that the TOE + cannot be used in a way such that the security functionality + can be corrupted or bypassed. These two properties require + somewhat different approaches in analysis, and so the families + in are structured to support these + different approaches. The families , , , and deal with the first property: the specification + of the security functionality. The families and deal with + the second property: the specification of the design of the + TOE demonstrating the security functionality cannot be + corrupted or bypassed. It should be noted that both properties + need to be realised: the more confidence one has that the + properties are satisfied, the more trustworthy the TOE is. The + components in the families are designed so that more assurance + can be gained as the components hierarchically + increase. + + The paradigm for the families targeted at the first property + is one of design decomposition. At the highest level, there is + a functional specification of the TSF in terms of its + interfaces (describing what the TSF does in + terms of requests to the TSF for services and resulting + responses), decomposing the TSF into smaller units (dependent + on the assurance desired and the complexity of the TOE) and + describing how the TSF accomplishes its + functions (to a level of detail commensurate with the + assurance level), and showing the implementation of the TSF. A + formal model of the security behaviour also may be given. All + levels of decomposition are used in determining the + completeness and accuracy of all other levels, ensuring that + the levels are mutually supportive. The requirements for the + various TSF representations are separated into different + families, to allow the PP/ST author to specify which TSF + representations are required. The level chosen will dictate + the assurance desired/gained. + + Figure indicates the + relationships among the various TSF representations of the + class, as well as their + relationships with other classes. As the figure indicates, the + and + classes define the requirements for the correspondence between + the SFRs and the security objectives for the TOE. Class also defines requirements for the + correspondence between both the security objectives and SFRs, + and for the TOE summary specification which explains how the + TOE meets its SFRs. The activities of include the verification that the TSF that is + tested under the and classes is in fact the one described by all of the + decomposition levels. +
+ + The requirements for all other correspondence shown in Figure + are defined in the + class. The family defines the requirements for formally + modelling selected SFRs, and providing correspondence between + the functional specification and the formal model. Each + assurance family specific to a TSF representation (i.e., , + and ) defines requirements + relating that TSF representation to the SFRs. All + decompositions must accurately reflect all other + decompositions (i.e., be mutually supportive); the developer + supplies the tracings in the last .C elements of the + components. Assurance relating to this factor is obtained + during the analysis for each of the levels of decomposition by + referring to other levels of decomposition (in a recursive + fashion) while the analysis of a particular level of + decomposition is being performed; the evaluator verifies the + correspondence as part of the second E element. The + understanding gained from these levels of decomposition form + the basis of the functional and penetration testing + efforts. + + The family is not represented + in this figure, as it is related to the internal structure of + the TSF, and is only indirectly related to the process of + refinement of the TSF representations. Similarly, the family is not represented in the + figure because it relates to the architectural soundness, + rather than representation, of the TSF. Both and + relate to the analysis of the property that the TOE cannot be + made to circumvent or corrupt its security + functionality. + + The TOE security functionality (TSF) consists of all parts of + the TOE that have to be relied upon for enforcement of the + SFRs. The TSF includes both functionality that directly + enforces the SFRs, as well as functionality that, while not + directly enforcing the SFRs, contributes to their enforcement + in a more indirect manner, including functionality with the + capability to cause the SFRs to be violated. This includes + portions of the TOE that are invoked on start-up that are + responsible for putting the TSF into its initial secure + state. + + Several important concepts were used in the development of the + components of the families. These + concepts, while introduced briefly here, are explained more + fully in the application notes for the families. + + One over-riding notion is that, as more information becomes + available, greater assurance can be obtained that the security + functionality 1) is correctly implemented; 2) cannot be + corrupted; and 3) cannot be bypassed. This is done through the + verification that the documentation is correct and consistent + with other documentation, and by providing information that + can be used to ensure that the testing activities (both + functional and penetration testing) are comprehensive. This is + reflected in the levelling of the components of the + families. In general, components are levelled based on the + amount of information that is to be provided (and subsequently + analysed). + + While not true for all TOEs, it is generally the case that the + TSF is sufficiently complex that there are portions of the TSF + that deserve more intense examination than other portions of + the TSF. Determining those portions is unfortunately somewhat + subjective, thus terminology and components have been defined + such that as the level of assurance increases, the + responsibility for determining what portions of the TSF need + to be examined in detail shifts from the developer to the + evaluator. To aid in expressing this concept, the following + terminology is introduced. It should be noted that in the + families of the class, this terminology is used when + expressing SFR-related portions of the TOE (that is, elements + and work units embodied in the , , and families). While the general + concept (that some portions of the TOE are more + interesting than others) applies to other + families, the criteria are expressed differently in order to + obtain the assurance required. + + All portions of the TSF are security + relevant, meaning that they must preserve the + security of the TOE as expressed by the SFRs and + requirements for domain separation and + non-bypassability. One aspect of security relevance is the + degree to which a portion of the TSF enforces a security + requirement. Since different portions of the TOE play + different roles (or no apparent role at all) in enforcing + security requirements, this creates a continuum of SFR + relevance: at one end of this continuum are portions of the + TOE that are termed SFR-enforcing. Such + portions play a direct role in implementing any SFR on the + TOE. Such SFRs refer to any functionality provided by one of + the SFRs contained in the ST. It should be noted that the + definition of plays a role in for + SFR-enforcing functionality is impossible to express + quantitatively. For example, in the implementation of a + Discretionary Access Control (DAC) mechanism, a very narrow + view of SFR-enforcing might be the several + lines of code that actually perform the check of a subject's + attributes against the object's attributes. A broader view + would include the software entity (e.g., C function) that + contained the several lines of code. A broader view still + would include callers of the C function, since they would be + responsible for enforcing the decision returned by the + attribute check. A still broader view would include any code + in the call tree (or programming equivalent for the + implementation language used) for that C function (e.g., a + sort function that sorted access control list entries in a + first-match algorithm implementation). At some point, the + component is not so much enforcing the + security policy but rather plays a + supporting role; such components are termed + SFR supporting. + + One of the characteristics of SFR-supporting functionality is + that it is trusted to preserve the correctness of the SFR + implementation by operating without error. Such functionality + may be depended on by SFR-enforcing functionality, but the + dependence is generally at a functional level; for example, + memory management, buffer management, etc. Further down on the + security relevance continuum is functionality termed + SFR non-interfering. Such functionality has + no role in implementing the SFRs, and is likely part of the + TSF because of its environment; for example, any code running + in a privileged hardware mode on an operating system. It needs + to be considered part of the TSF because, if compromised (or + replaced by malicious code), it could compromise the correct + operation of an SFR by virtue of its operating in the + privileged hardware mode. An example of SFR non-interfering + functionality might be a set of mathematical floating point + operations implemented in kernel mode for speed + considerations. + + The architecture family () + provides for requirements and analysis of the TOE based on + properties of domain separation, self-protection, and + non-bypassability. These properties relate to the SFRs in + that, if these properties are not present, it will likely lead + to the failure of mechanisms implementing SFRs. Functionality + and design relating to these properties is + not considered a part of the continuum described + above, but instead is treated separately due to its + fundamentally different nature and analysis + requirements. + + The difference in analysis of the implementation of SFRs + (SFR-enforcing and SFR-supporting functionality) and the + implementation of somewhat fundamental security properties of + the TOE, which include the initialisation, self-protection, + and non-bypassability concerns, is that the SFR-related + functionality is more or less directly visible and relatively + easy to test, while the above-mentioned properties require + varying degrees of analysis on a much broader set of + functionality. Further, the depth of analysis for such + properties will vary depending on the design of the TOE. The + families are constructed to address + this by a separate family () + devoted to analysis of the initialisation, self-protection, + and non-bypassability requirements, while the other families + are concerned with analysis of the functionality supporting + SFRs. + + Even in cases where different descriptions are necessary for + the multiple levels of abstraction, it is not absolutely + necessary for each and every TSF representation to be in a + separate document. Indeed, it may be the case that a single + document meets the documentation requirements for more than + one TSF representation, since it is the information about each + of these TSF representations that is required, rather than the + resulting document structure. In cases where multiple TSF + representations are combined within a single document, the + developer should indicate which portions of the documents meet + which requirements. + + Three types of specification style are mandated by this class: + informal, semiformal and formal. The functional specification + and TOE design documentation are always written in either + informal or semiformal style. A semiformal style reduces the + ambiguity in these documents over an informal presentation. A + formal specification may also be required in addition + to the semi-formal presentation; the value is that a + description of the TSF in more than one way will add increased + assurance that the TSF has been completely and accurately + specified. + + An informal specification is written as prose in natural + language. Natural language is used here as meaning + communication in any commonly spoken tongue (e.g. Spanish, + German, French, English, Dutch). An informal specification is + not subject to any notational or special restrictions other + than those required as ordinary conventions for that language + (e.g. grammar and syntax). While no notational restrictions + apply, the informal specification is also required to provide + defined meanings for terms that are used in a context other + than that accepted by normal usage. + + The difference between semiformal and informal documents is + only a matter of formatting or presentation: a semiformal + notation includes such things as an explicit glossary of + terms, a standardised presentation format, etc. A semiformal + specification is written to a standard presentation + template. The presentation should use terms consistently if + written in a natural language. The presentation may also use + more structured languages/diagrams (e.g. data-flow diagrams, + state transition diagrams, entity-relationship diagrams, data + structure diagrams, and process or program structure + diagrams). Whether based on diagrams or natural language, a + set of conventions must be used in the presentation. The + glossary explicitly identifies the words that are being used + in a precise and constant manner; similarly, the standardised + format implies that extreme care has been taken in + methodically preparing the document in a manner that maximises + clarity. It should be noted that fundamentally different + portions of the TSF may have different semiformal notation + conventions and presentation styles (as long as the number of + different ``semiformal notations'' is small); this still + conforms to the concept of a semiformal + presentation. + + A formal specification is written in a notation based upon + well-established mathematical concepts, and is typically + accompanied by supporting explanatory (informal) prose. These + mathematical concepts are used to define the syntax and + semantics of the notation and the proof rules that support + logical reasoning. The syntactic and semantic rules supporting + a formal notation should define how to recognise constructs + unambiguously and determine their meaning. There needs to be + evidence that it is impossible to derive contradictions, and + all rules supporting the notation need to be defined or + referenced. + + + + The purpose of the Development class is to provide evidence + about the TOE. Without the knowledge about the TOE that is + gained from this information, there could be no useful + vulnerability analysis or testing conducted upon the TOE (as + described in the and classes). + + + The purpose of the development activity is to assess the + design documentation in terms of its adequacy to understand + how the TSF meets the SFRs and how the implementation of these + SFRs cannot be tampered with or bypassed. This understanding + is achieved through examination of increasingly refined + descriptions of the TSF design documentation. Design + documentation consists of a functional specification (which + describes the interfaces of the TSF), a TOE design description + (which describes the architecture of the TSF in terms of how + it works in order to perform the functions related to the SFRs + being claimed), and an implementation description (a source + code level description). In addition, there is a security + architecture description (which describes the architectural + properties of the TSF to explain how its security enforcement + cannot be compromised or bypassed), an internals description + (which describes how the TSF was constructed in a manner that + encourages understandability), and a security policy model + (which formally describes the security policies enforced by + the TSF). + + + + The CC requirements for design documentation are levelled by + the amount, and detail of information provided, and the degree + of formality of the presentation of the information. At lower + levels, the most security-critical portions of the TSF are + described with the most detail, while less security-critical + portions of the TSF are merely summarised; added assurance is + gained by increasing the amount of information about the most + security-critical portions of the TSF, and increasing the + details about the less security-critical portions. The most + assurance is achieved when thorough details and information of + all portions are provided. + + The CC considers a document's degree of formality (that is, + whether it is informal or semiformal) to be hierarchical. An + informal document is one that is expressed in a natural + language. The methodology does not dictate the specific + language that must be used; that issue is left for the + scheme. The following paragraphs differentiate the contents of + the different informal documents. + + A functional specification provides a description of the + purpose and method-of-use of interfaces to the TSF. For + example, if an operating system presents the user with a means + of self-identification, of creating files, of modifying or + deleting files, of setting permissions defining what other + users may access files, and of communicating with remote + machines, its functional specification would contain + descriptions of each of these and how they are realised + through interactions with the externally-visible interfaces to + the TSF. If there is also audit functionality that detects and + record the occurrences of such events, descriptions of this + audit functionality would also be expected to be part of the + functional specification; while this functionality is + technically not directly invoked by the user at the external + interface, it certainly is affected by what occurs at the + user's external interface. + + A design description is expressed in terms of logical + divisions (subsystems or modules) that each provide a + comprehensible service or function. For example, a firewall + might be composed of subsystems that deal with packet + filtering, with remote administration, with auditing, and with + connection-level filtering. The design description of the + firewall would describe the actions that are taken, in terms + of what actions each subsystem takes when an incoming packet + arrives at the firewall. + + + + + The objective of this family is for the developer to provide + a description of the security architecture of the TSF. This + will allow analysis of the information that, when coupled + with the other evidence presented for the TSF, will confirm + the TSF achieves the desired properties. The security + architecture descriptions supports the implicit claim that + security analysis of the TOE can be achieved by examining + the TSF; without a sound architecture, the entire TOE + functionality would have to be examined. + + + + The information presented for the security architecture of + the TOE is related to the information contained in other + decomposition documentation (functional specification and + TOE design documentation) provided for the TSF, but presents + the design in a manner that supports architectural arguments + (e.g., the TSF cannot be compromised; the TSF provides + security domains consistent with its SFRs; the TSF cannot be + bypassed). + + + + This family contains only one component. + + + + The properties of self-protection, domain separation, and + non-bypassability are distinct from security functionality + expressed by Part 2 SFRs because self-protection and + non-bypassability largely have no directly observable + interface at the TSF. Rather, they are properties of the TSF + that are achieved through the design of the TOE and TSF, and + enforced by the correct implementation of that + design. + + The approach used in this family is for the developer to + design and provide a TSF that exhibits the above-mentioned + properties, and to provide evidence (in the form of + documentation) that explains these properties of the + TSF. This explanation is provided at the same level of + detail as the description of the SFR-enforcing elements of + the TOE in the TOE design document. The evaluator has the + responsibility for looking at the evidence and, coupled with + other evidence delivered for the TOE and TSF, determining + that the properties are achieved. + + Specification of security functionality implementing the + SFRs (in the and ) will not necessarily describe + mechanisms employed in implementing self-protection and + non-bypassability (e.g. memory management + mechanisms). Therefore, the material needed to provide the + assurance that these requirements are being achieved is + better suited to a presentation separate from the design + decomposition of the TSF as embodied in and . This is not + to imply that the security architecture description called + for by this component cannot reference or make use of the + design decomposition material; but it is likely that much of + the detail present in the decomposition documentation will + not be relevant to the argument being provided for the + security architecture description document. + + The description of architectural soundness can be thought of + as a developer's vulnerability analysis, in that it provides + the justification for why the TSF is sound and enforces all + of its SFRs. Where the soundness is achieved through + specific security mechanisms, these will be tested as part + of the requirements; where + the soundness is achieved solely through the architecture, + the behaviour will be tested as part of the requirements. + + This family consists of requirements for a security + architecture description that describes the self-protection, + domain separation, non-bypassability principles, including a + description of how these principles are supported by the + parts of the TOE that are used for TSF + initialisation. + Additional information on the security architecture + properties of self-protection, domain separation, and + non-bypassability can be found in Annex . + + + + + + + The objective of this sub-activity is to determine whether + the TSF is structured such that it cannot be tampered with + or bypassed, and whether TSFs that provide security + domains isolate those domains from each other. + + + + The notions of self-protection, domain separation, and + non-bypassability are distinct from security functionality + expressed in Part 2 SFRs because self-protection and + non-bypassability largely have no directly observable + interface at the TSF. Rather, they are properties of the + TSF that are achieved through the design of the TOE, and + enforced by the correct implementation of that + design. Also, the evaluation of these properties is less + straight-forward than the evaluation of mechanisms; it is + more difficult to check for the absence of functionality + than for its presence. However, the determination that + these properties are being satisfied is just as critical + as the determination that the mechanisms are properly + implemented. + + The overall approach used is that the developer provides a + TSF that meets the above-mentioned properties, and + provides evidence (in the form of documentation) that can + be analysed to show that the properties are indeed + met. The evaluator has the responsibility for looking at + the evidence and, coupled with other evidence delivered + for the TOE, determining that the properties are + achieved. The work units can be characterised as those + detailing with what information has to be provided, and + those dealing with the actual analysis the evaluator + performs. + + The security architecture description describes how + domains are defined and how the TSF keeps them + separate. It describes what prevents untrusted processes + from getting to the TSF and modifying it. It describes + what ensures that all resources under the TSF's control + are adequately protected and that all actions related to + the SFRs are mediated by the TSF. It explains any role the + environment plays in any of these (e.g. presuming it gets + correctly invoked by its underlying environment, how is + its security functionality invoked?). In short, it + explains how the TOE is considered to be providing any + kind of security service. + + The analyses the evaluator performs must be done in the + context of all of the development evidence provided for + the TOE, at the level of detail the evidence is + provided. At lower assurance levels there should not be + the expectation that, for example, TSF self-protection is + completely analysed, because only high-level design + representations will be available. The evaluator also + needs to be sure to use information gleaned from other + portions of their analysis (e.g., analysis of the TOE + design) in making their assessments for the properties + being examined in the following work units. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the functional specification; + + + the TOE design; + + + the security architecture description; + + + the implementation representation (if available); + + + the operational user guidance; + + + + + The developer shall design and implement the TOE so that the + security features of the TSF cannot be bypassed. + + + The developer shall design and implement the TSF so that it + is able to protect itself from tampering by untrusted active + entities. + + + The developer shall provide a security architecture + description of the TSF. + + + The security architecture description shall be at a level of + detail commensurate with the description of the + SFR-enforcing abstractions described in the TOE design + document. + + + The security architecture description shall describe the + security domains maintained by the TSF consistently with the + SFRs. + + + The security architecture description shall describe how the + TSF initialisation process is secure. + + + The security architecture description shall demonstrate that + the TSF protects itself from tampering. + + + The security architecture description shall demonstrate that + the TSF prevents bypass of the SFR-enforcing functionality. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the security architecture + description to determine that the information provided + in the evidence is presented at a level of detail + commensurate with the descriptions of the SFR-enforcing + abstractions contained in the functional specification + and TOE design document. + + With respect to the functional specification, the + evaluator should ensure that the self-protection + functionality described cover those effects that are + evident at the TSFI. Such a description might include + protection placed upon the executable images of the TSF, + and protection placed on objects (e.g., files used by + the TSF). The evaluator ensures that the functionality + that might be invoked through the TSFI is + described. + + If or is included, the evaluator + ensures the security architecture description contains + information on how any subsystems that contribute to TSF + domain separation work. + + If or higher is + available, the evaluator ensures that the security + architecture description also contains + implementation-dependent information. For example, such + a description might contain information pertaining to + coding conventions for parameter checking that would + prevent TSF compromises (e.g. buffer overflows), and + information on stack management for call and return + operations. The evaluator checks the descriptions of the + mechanisms to ensure that the level of detail is such + that there is little ambiguity between the description + in the security architecture description and the + implementation representation. + + The evaluator action related to this work unit is assigned a fail verdict + if the security architecture description mentions any module, subsystem, or interface + that is not described in the functional specification or TOE design document. + + + + The evaluator shall examine the security architecture + description to determine that it describes the security + domains maintained by the TSF. + + Security domains refer to environments supplied by the + TSF for use by potentially-harmful entities; for + example, a typical secure operating system supplies a + set of resources (address space, per-process environment + variables) for use by processes with limited access + rights and security properties. The evaluator determines + that the developer's description of the security domains + takes into account all of the SFRs claimed by the + TOE. + + For some TOEs such domains do not exist because all of + the interactions available to users are severely + constrained by the TSF. A packet-filter firewall is an + example of such a TOE. Users on the LAN or WAN do not + interact with the TOE, so there need be no security + domains; there are only data structures maintained by + the TSF to keep the users' packets separated. The + evaluator ensures that any claim that there are no + domains is supported by the evidence and that no such + domains are, in fact, available. + + + + + The evaluator shall examine the security architecture + description to determine that the initialisation process + preserves security. + + The information provided in the security architecture + description relating to TSF initialisation is directed + at the TOE components that are involved in bringing the + TSF into an initial secure state (i.e. when all parts of + the TSF are operational) when power-on or a reset is + applied. This discussion in the security architecture + description should list the system initialisation + components and the processing that occurs in + transitioning from the ``down'' state to the initial + secure state. + + It is often the case that the components that perform + this initialisation function are not accessible after + the secure state is achieved; if this is the case then + the security architecture description identifies the components and + explains how they are not reachable by untrusted + entities after the TSF has been established. In this + respect, the property that needs to be preserved is that + these components either 1) cannot be accessed by + untrusted entities after the secure state is achieved, + or 2) if they provide interfaces to untrusted entities, + these TSFI cannot be used to tamper with the TSF. + + The TOE components related to TSF initialisation, then, + are treated themselves as part of the TSF, and analysed + from that perspective. It should be noted that even + though these are treated as part of the TSF, it is + likely that a justification (as allowed by ) can be made that they do not + have to meet the internal structuring requirements of + . + + + + + The evaluator shall examine the security architecture + description to determine that it contains information + sufficient to support a determination that the TSF is + able to protect itself from tampering by untrusted + active entities. + + ''Self-protection'' refers to the ability of the TSF to + protect itself from manipulation from external entities + that may result in changes to the TSF. For TOEs that + have dependencies on other IT entities, it is often the + case that the TOE uses services supplied by the other IT + entities in order to perform its functions. In such + cases, the TSF alone does not protect itself because it + depends on the other IT entities to provide some of the + protection. For the purposes of the security + architecture description, the notion of + self-protection applies only to the + services provided by the TSF through its TSFI, and not + to services provided by underlying IT entities that it + uses. + + Self-protection is typically achieved by a variety of + means, ranging from physical and logical restrictions on + access to the TOE; to hardware-based means (e.g. + ``execution rings'' and memory management + functionality); to software-based means (e.g. boundary + checking of inputs on a trusted server). The evaluator + determines that all such mechanisms are + described. + + The evaluator determines that the design description + covers how user input is handled by the TSF in such a + way that the TSF does not subject itself to being + corrupted by that user input. For example, the TSF might + implement the notion of privilege and protect itself by + using privileged-mode routines to handle user input. The + TSF might make use of processor-based separation + mechanisms such as privilege levels or rings. The TSF + might implement software protection constructs or coding + conventions that contribute to implementing separation of + software domains, perhaps by delineating user address + space from system address space. And the TSF might have + reliance its environment to provide some support to the + protection of the TSF. + + All of the mechanisms contributing to the domain + separation functions are described. The evaluator should + use knowledge gained from other evidence (functional + specification, TOE design, TSF internals description, + other parts of the security architecture description, or + implementation representation, as included in the + assurance package for the TOE) in determining if any + functionality contributing to self-protection was + described that is not present in the security + architecture description. + + Accuracy of the description of the self-protection mechanisms is the property that the + description faithfully describes what is implemented. The evaluator should use other + evidence (functional specification, TOE design, TSF Internals documentation, other parts + of the security architecture description, implementation representation, as included in + the ST for the TOE) in determining whether there are discrepancies in any descriptions + of the self-protection mechanisms. If + + is included in the assurance package for the TOE, the evaluator will choose a sample of + the implementation representation; the evaluator should also ensure that the descriptions + are accurate for the sample chosen. If an evaluator cannot understand how a certain + self-protection mechanism works or could work in the system architecture, it may be the + case that the description is not accurate. + + + + + The evaluator shall examine the security architecture + description to determine that it presents an analysis + that adequately describes how the SFR-enforcing + mechanisms cannot be bypassed. + + Non-bypassability is a property that the security + functionality of the TSF (as specified by the SFRs) is + always invoked. For example, if access control to files + is specified as a capability of the TSF via an SFR, + there must be no interfaces through which files can be + accessed without invoking the TSF's access control + mechanism (such as an interface through which a raw disk + access takes place). + + Describing how the TSF mechanisms cannot be bypassed + generally requires a systematic argument based on the + TSF and the TSFIs. The description of how the TSF works + (contained in the design decomposition evidence, such as + the functional specification, TOE design documentation) + - along with the information in the TSS - provides the + background necessary for the evaluator to understand + what resources are being protected and what security + functions are being provided. The functional + specification provides descriptions of the TSFIs through + which the resources/functions are accessed. + + The evaluator assesses the description provided (and other + information provided by the developer, such as the functional + specification) to ensure that no available interface can be used + to bypass the TSF. This means that every available interface + must be either unrelated to the SFRs that are claimed in the ST + (and does not interact with anything that is used to satisfy + SFRs) or else uses the security functionality that is described + in other development evidence in the manner described. For + example, a game would likely be unrelated to the SFRs, so there + must be an explanation of how it cannot affect security. Access + to user data, however, is likely to be related to access control + SFRs, so the explanation would describe how the security + functionality works when invoked through the data-access + interfaces. Such a description is needed for every available + interface. + + An example of a description follows. Suppose the TSF + provides file protection. Further suppose that although + the ``traditional'' system call TSFIs for open, read, + and write invoke the file protection mechanism described + in the TOE design, there exists a TSFI that allows + access to a batch job facility (creating batch jobs, + deleting jobs, modifying unprocessed jobs). The + evaluator should be able to determine from the + vendor-provided description that this TSFI invokes the + same protection mechanisms as do the ``traditional'' + interfaces. This could be done, for example, by + referencing the appropriate subclauses of the TOE design + that discuss how the batch job facility + TSFI achieves its security objectives. + + Using this same example, suppose there is a TSFI whose + sole purpose is to display the time of day. The + evaluator should determine that the description + adequately argues that this TSFI is not capable of + manipulating any protected resources and should not + invoke any security functionality. + + Another example of bypass is when the TSF is supposed to + maintain confidentiality of a cryptographic key (one is + allowed to use it for cryptographic operations, but is + not allowed to read/write it). If an attacker has direct + physical access to the device, he might be able to + examine side-channels such as the power usage of the + device, the exact timing of the device, or even any + electromagnetic emanations of the device and, from this, + infer the key. + + If such side-channels may be present, the demonstration + should address the mechanisms that prevent these + side-channels from occurring, such as random internal + clocks, dual-line technology etc. Verification of these + mechanisms would be verified by a combination of purely + design-based arguments and testing. + + For a final example using security functionality rather + than a protected resource, consider an ST that contains + , which requires that + the TSF provides evidence of origination for information + types specified in the ST. Suppose that the + ``information types'' included all information that is + sent by the TOE via e-mail. In this case the evaluator + should examine the description to ensure that all TSFI + that can be invoked to send e-mail perform the + ``evidence of origination generation'' function are + detailed. The description might point to user guidance + to show all places where e-mail can originate (e.g., + e-mail program, notification from scripts/batch jobs) + and then how each of these places invokes the evidence + generation function. + + The evaluator should also ensure that the description is comprehensive, in that each + interface is analysed with respect to the entire set of claimed SFRs. This may require the + evaluator to examine supporting information (functional specification, TOE design, other + parts of the security architecture description, operational user guidance, and perhaps even + the implementation representation, as provided for the TOE) to determine that the description + has correctly capture all aspects of an interface. The evaluator should consider what SFRs each + TSFI might affect (from the description of the TSFI and its implementation in the supporting + documentation), and then examine the description to determine whether it covers those aspects. + + + + + + + + This family levies requirements upon the functional specification, + which describes the TSF interfaces (TSFIs). + The TSFI consists of all means by which external entities (or + subjects in the TOE but outside of the TSF) supply data to the TSF, + receive data from the TSF and invoke services from the TSF. + It does not describe how the TSF processes those service + requests, nor does it describe the communication when the TSF invokes services + from its operational environment; this information is addressed by the + and + families, respectively. + + This family provides assurance directly by allowing the + evaluator to understand how the TSF meets the claimed SFRs. It + also provides assurance indirectly, as input to other assurance + families and classes: + , where the description of + the TSFIs may be used to gain better understanding of how the + TSF is protected against corruption (i.e. subversion of + self-protection or domain separation) and/or bypass; + , where the description of the + TSFIs is an important input for both developer and evaluator + testing; + , where the description of the + TSFIs is used to search for vulnerabilities. + + + + + The information presented in the functional specification + describes the interfaces through which the TSF services are + invoked. At the lower levels of assurance, there is an + effort to reduce the amount of information that must be + supplied by requiring only the most security-critical + information. + + + + The components in this family are levelled on the degree of + detail required of the description of the TSFIs, and the degree + of formalism required of the description of the TSFIs. + + + + Once the TSFIs are determined (see for guidance and + examples of determining TSFI), they are described. At + lower-level components, developers focus their documentation + (and evaluators focus their analysis) on the more + security-relevant aspects of the TOE. Three categories of + TSFIs are defined, based upon the relevance the services + available through them have to the SFRs being claimed: + If a service available through an interface can be + traced to one of the SFRs levied on the TSF, then that + interface is termed SFR-enforcing. + Note that it is possible that an interface may have + various services and results, some of which may be + SFR-enforcing and some of which may not. + interfaces to (or services available through an + interface relating to) services that SFR-enforcing + functionality depends upon, but need only to function + correctly in order for the security policies of the TOE + to be preserved, are termed + SFR-supporting. + Interfaces to services on which SFR-enforcing + functionality has no dependence are termed SFR + non-interfering. + + It should be noted that in order for an interface to be + SFR-supporting or SFR non-interfering it must have + no SFR-enforcing services or results. In + contrast, an SFR-enforcing interface may have SFR-supporting + services (for example, the ability to set the system clock + may be an SFR-enforcing service of an interface, but if that + same interface is used to display the system date that + service may be only SFR-supporting). An example of a purely + SFR-supporting interface is a system call interface that is + used both by users and by a portion of the TSF that is + running on behalf of users. + + As more information about the TSFIs becomes available, the + greater the assurance that can be gained that the interfaces are + correctly categorised/analysed. The requirements are structured + such that, at the lowest level, the information required for SFR + non-interfering interfaces is the minimum necessary in order for + the evaluator to make this determination in an effective + manner. At higher levels, more information becomes available so + that the evaluator has greater confidence in the + designation. + + The purpose in defining these labels (SFR-enforcing, + SFR-supporting, and SFR-non-interfering) and for levying + different requirements upon each (at the lower assurance + components) is to provide a first approximation of where to + focus the analysis and the evidence upon which that analysis + is performed. If the developer's documentation of the TSF + interfaces describes all of the interfaces to the degree + specified in the requirements for the SFR-enforcing + interfaces (that is, if the documentation exceeds the + requirements), there is no need for the developer to create + new evidence to match the requirements. Similarly, because + the labels are merely a means of differentiating the + interface types within the requirements, there is no need + for the developer to update the evidence solely to label the + interfaces as SFR-enforcing, SFR-supporting, and + SFR-non-interfering. The primary purpose of this labelling + is to allow developers with less mature development + methodologies (and associated artifacts, such as detailed + interface and design documentation) to provide only the + necessary evidence without undue cost. + + The last C element of each component within this family provides + a direct correspondence between the SFRs and the functional + specification; that is, an indication of which interfaces are + used to invoke each of the claimed SFRs. In the cases where the + ST contains such functional requirements as , whose functionality may not manifest itself at + the TSFIs, the functional specification and/or the tracing is + expected to identify these SFRs; including them in the functional + specification helps to ensure that they are not lost at lower + levels of decomposition, where they will be relevant. + + + The requirements define collections of details about TSFI + to be provided. For the purposes of the requirements, + interfaces are specified (in varying degrees of detail) in + terms of their purpose, method of use, parameters, + parameter descriptions, and error messages. + + The purpose of an interface is a + high-level description of the general goal of the + interface (e.g. process GUI commands, receive network + packets, provide printer output, etc.) + + The interface's method of use describes + how the interface is supposed to be used. This description + should be built around the various interactions available + at that interface. For instance, if the interface were a Unix + command shell, ls, mv + and cp would be interactions for that + interface. For each interaction the method of use + describes what the interaction does, both for behaviour + seen at the interface (e.g. the programmer calling the + API, the Windows users changing a setting in the registry, + etc.) as well as behaviour at other interfaces + (e.g. generating an audit record). + + Parameters are explicit inputs to and + outputs from an interface that control the behaviour of + that interface. For example, parameters are the arguments + supplied to an API; the various fields in a packet for a + given network protocol; the individual key values in the + Windows Registry; the signals across a set of pins on a + chip; the flags that can be set for the + ls, etc. The parameters are + ``identified'' with a simple list of what they are. + + A parameter description tells what the + parameter is in some meaningful way. For instance, an + acceptable parameter description for interface + foo(i) would be ``parameter i is an + integer that indicates the number of users currently + logged in to the system''. A description such as + ``parameter i is an integer'' is not an acceptable. + + The description of an interface's actions + describes what the interface does. This is more detailed + than the purpose in that, while the ``purpose'' reveals + why one might want to use it, the ``actions'' reveals + everything that it does. These actions might be related to + the SFRs or not. In cases where the interface's action is + not related to SFRs, its description is said to be + summarised, meaning the description + merely makes clear that it is indeed not SFR-related. + + The error message description identifies + the condition that generated it, what the message is, and + the meaning of any error codes. An error message is + generated by the TSF to signify that a problem or + irregularity of some degree has been encountered. The + requirements in this family refer to different kinds of + error messages: + a ``direct'' error message is a + security-relevant response through a specific TSFI + invocation. + an ``indirect'' error cannot be tied to a + specific TSFI invocation because it results from + system-wide conditions (e.g. resource exhaustion, + connectivity interruptions, etc.). Error messages that + are not security-relevant are also considered + ``indirect''. + ``remaining'' errors are any other errors, such as those + that might be referenced within the code. For example, the use of + condition-checking code that checks for conditions that would not + logically occur (e.g. a final ``else'' after a list of ``case'' + statements), would provide for generating a catch-all error + message; in an operational TOE, these error messages should never + be seen. + + An example functional specification is provided in . + + + + Increasing assurance through increased completeness and + accuracy in the interface specification is reflected in + the documentation required from the developer as detailed + in the various hierarchical components of this + family. + + At , the only + documentation required is a characterisation of all TSFIs + and a high level description of SFR-enforcing and + SFR-supporting TSFIs. To provide some assurance that the + ``important'' aspects of the TSF have been correctly + characterised at the TSFIs, the developer is required to + provide the purpose and method of use, parameters for the + SFR-enforcing and SFR-supporting TSFIs. + + At , the developer is + required to provide the purpose, method of use, + parameters, and parameter descriptions for all + TSFIs. Additionally, for the SFR-enforcing TSFIs the + developer has to describe the SFR-enforcing actions and + direct error messages. + + At , the developer must now, + in addition to the information required at , provide enough information about the SFR-supporting + and SFR-non-interfering actions to show that they are not + SFR-enforcing. Further, the developer must now document all of + the direct error messages resulting from the invocation of + SFR-enforcing TSFIs. + + At , all TSFIs - whether + SFR-enforcing, SFR-supporting, SFR-non-interfering - must + be described to the same degree, including all of the + direct error messages. + + At , the TSFIs descriptions + also include error messages that do not result from an + invocation of a TSFI. + + At , in addition to the + information required by , all + remaining error messages are included. The developer must also + provide a formal description of the TSFI. This provides an + alternative view of the TSFI that may expose inconsistencies or + incomplete specification. + + + + + + The objective of this sub-activity is to determine whether the + developer has provided a high-level description of at least the + SFR-enforcing and SFR-supporting TSFIs, in terms of descriptions + of their parameters. There is no other required evidence that + can be expected to be available to measure the accuracy of these + descriptions; the evaluator merely ensures the descriptions seem + plausible. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the functional specification; + + + the operational user guidance; + + + + + The developer shall provide a functional specification. + + + The developer shall provide a tracing from the functional + specification to the SFRs. + + + The functional specification shall describe the purpose and + method of use for each SFR-enforcing and SFR-supporting + TSFI. + + + The functional specification shall identify all parameters + associated with each SFR-enforcing and SFR-supporting TSFI. + + + The functional specification shall provide rationale for the + implicit categorisation of interfaces as + SFR-non-interfering. + + + The tracing shall demonstrate that the SFRs trace to TSFIs + in the functional specification. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the functional specification + to determine that it states the purpose of each + SFR-supporting and SFR-enforcing TSFI. + + The purpose of a TSFI is a general statement summarising + the functionality provided by the interface. It is not + intended to be a complete statement of the actions and + results related to the interface, but rather a statement + to help the reader understand in general what the + interface is intended to be used for. The evaluator + should not only determine that the purpose exists, but + also that it accurately reflects the TSFI by taking into + account other information about the interface, such as + the description of the parameters; this can be done in + association with other work units for this + component. + + If an action available through an interface plays a role in + enforcing any security policy on the TOE (that is, if one of the + actions of the interface can be traced to one of the SFRs levied + on the TSF), then that interface is + SFR-enforcing. Such policies are not limited to + the access control policies, but also refer to any functionality + specified by one of the SFRs contained in the ST. Note that it + is possible that an interface may have various actions and + results, some of which may be SFR-enforcing and some of which + may not. + + Interfaces to (or actions available through an interface + relating to) actions that SFR-enforcing functionality + depends on, but need only to function correctly in order + for the security policies of the TOE to be preserved, + are termed SFR supporting. Interfaces + to actions on which SFR-enforcing functionality has no + dependence are termed SFR + non-interfering. + + It should be noted that in order for an interface to be + SFR supporting or SFR non-interfering it must have + no SFR-enforcing actions or results. In + contrast, an SFR-enforcing interface may have + SFR-supporting actions (for example, the ability to set + the system clock may be an SFR-enforcing action of an + interface, but if that same interface is used to display + the system date that action may only be SFR + supporting). An example of a purely SFR-supporting + interface is a system call interface that is used both + by untrusted users and by a portion of the TSF that is + running in user mode. + + At this level, it is unlikely that a developer will have + expended effort to label interfaces as SFR-enforcing and + SFR-supporting. In the case that this has been done, + the evaluator should verify to the extent that + supporting documentation (e.g., operational user + guidance) allows that this identification is correct. + Note that this identification activity is necessary for + several work units for this component. + + In the more likely case that the developer has not + labelled the interfaces, the evaluator must perform + their own identification of the interfaces first, and + then determine whether the required information (for + this work unit, the purpose) is present. Again, because + of the lack of supporting evidence this identification + will be difficult and have low assurance that all + appropriate interfaces have been correctly identified, + but nonetheless the evaluator examines other evidence + available for the TOE to ensure as complete coverage as + is possible. + + + + + The evaluator shall examine the functional specification + to determine that the method of use for each + SFR-supporting and SFR-enforcing TSFI is given. + + See work unit for a + discussion on the identification of SFR-supporting and + SFR-enforcing TSFI. + + The method of use for a TSFI summarises how the + interface is manipulated in order to invoke the actions + and obtain the results associated with the TSFI. The + evaluator should be able to determine, from reading this + material in the functional specification, how to use + each interface. This does not necessarily mean that + there needs to be a separate method of use for each + TSFI, as it may be possible to describe in general how + kernel calls are invoked, for instance, and then + identify each interface using that general + style. Different types of interfaces will require + different method of use specifications. APIs, network + protocol interfaces, system configuration parameters, + and hardware bus interfaces all have very different + methods of use, and this should be taken into account by + the developer when developing the functional + specification, as well as by the evaluator evaluating + the functional specification. + + For administrative interfaces whose functionality is documented + as being inaccessible to untrusted users, the evaluator ensures + that the method of making the functions inaccessible is + described in the functional specification. It should be noted + that this inaccessibility needs to be tested by the developer in + their test suite. + + + + + The evaluator shall examine the presentation of the TSFI + to determine that it identifies all parameters + associated with each SFR-enforcing and SFR-supporting + TSFI. + + See work unit for a + discussion on the identification of SFR-supporting and + SFR-enforcing TSFI. + + The evaluator examines the functional specification to + ensure that all of the parameters are described for + identified TSFI. Parameters are explicit inputs or + outputs to an interface that control the behaviour of + that interface. For examples, parameters are the + arguments supplied to an API; the various fields in + packet for a given network protocol; the individual key + values in the Windows Registry; the signals across a set + of pins on a chip; etc. + + While difficult to obtain much assurance that all + parameters for the applicable TSFI have been identified, + the evaluator should also check other evidence provided + for the evaluation (e.g., operational user guidance) to + see if behaviour or additional parameters are described + there but not in the functional specification. + + + + + The evaluator shall examine the rationale provided by + the developer for the implicit categorisation of + interfaces as SFR-non-interfering to determine that it + is accurate. + + In the case where the developer has provided adequate + documentation to perform the analysis called for by the + rest of the work units for this component without + explicitly identifying SFR-enforcing and SFR-supporting + interfaces, this work unit should be considered + satisfied. + + This work unit is intended to apply to cases where the developer + has not described a portion of the TSFI, claiming that it is + SFR-non-interfering and therefore not subject to other + requirements of this component. In such a case, the developer + provides a rationale for this characterisation in sufficient + detail such that the evaluator understands the rationale, the + characteristics of the interfaces affected (e.g., their + high-level function with respect to the TOE, such as ``colour + palette manipulation''), and that the claim that these are + SFR-non-interfering is supported. Given the level of assurance + the evaluator should not expect more detail than is provided for + the SFR-enforcing or SFR-supporting interfaces, and in fact the + detail should be much less. In most cases, individual + interfaces should not need to be addressed in the + developer-provided rationale subclause. + + + + The evaluator shall check that the tracing links the + SFRs to the corresponding TSFIs. + + The tracing is provided by the developer to serve as a + guide to which SFRs are related to which TSFIs. This + tracing can be as simple as a table; it is used as input + to the evaluator for use in the following work units, in + which the evaluator verifies its completeness and + accuracy. + + + + The evaluator shall determine that the functional + specification is an accurate and complete instantiation of + the SFRs. + + + The evaluator shall examine the functional specification + to determine that it is a complete instantiation of the + SFRs. + + To ensure that all SFRs are covered by the functional + specification, as well as the test coverage analysis, the + evaluator may build upon the developer's tracing (see a map between the TOE security + functional requirements and the TSFI). Note that this map may + have to be at a level of detail below the component or even + element level of the requirements, because of operations + (assignments, refinements, selections) performed on the + functional requirement by the ST author. + + For example, the + component contains an element with assignments. If the + ST contained, for instance, ten rules in the assignment, and these ten + rules were covered by three different TSFI, it would be + inadequate for the evaluator to map to TSFI A, B, and C and claim they had + completed the work unit. Instead, the evaluator would + map (rule 1) to TSFI A; + (rule 2) to TSFI B; + etc. It might also be the case that the interface is a + wrapper interface (e.g., IOCTL), in which case the + mapping would need to be specific to certain set of + parameters for a given interface. + + The evaluator must recognise that for requirements that have + little or no manifestation at the TSF boundary (e.g., ) it is not expected that they + completely map those requirements to the TSFI. The analysis for + those requirements will be performed in the analysis for the TOE + design () when included in the + ST. It is also important to note that since the parameters + associated with TSFIs must be fully specified, the evaluator + should be able to determine if all aspects of an SFR appear to + be implemented at the interface level. + + + + The evaluator shall examine the functional specification + to determine that it is an accurate instantiation of the + SFRs. + + For each functional requirement in the ST that results + in effects visible at the TSF boundary, the information + in the associated TSFI for that requirement specifies + the required functionality described by the + requirement. For example, if the ST contains a + requirement for access control lists, and the only TSFI + that map to that requirement specify functionality for + Unix-style protection bits, then the functional + specification is not accurate with respect to the + requirements. + + The evaluator must recognise that for requirements that + have little or no manifestation at the TSF boundary + (e.g., ) it is not + expected that the evaluator completely map those + requirements to the TSFI. The analysis for those + requirements will be performed in the analysis for the + TOE design () when + included in the ST. + + + + + + + + + The objective of this sub-activity is to determine whether + the developer has provided a description of the TSFIs in + terms of their purpose, method of use, and parameters. In + addition, the SFR-enforcing actions, results and error + messages of each TSFI that is SFR-enforcing are also + described. + + + + The evaluation evidence for this sub-activity that is + required by the work-units is: + + + the ST; + + + the functional specification; + + + the TOE design. + + + + The evaluation evidence for this sub-activity that is used + if included in the ST for the TOE is: + + + the security architecture description; + + + the operational user guidance; + + + + + The developer shall provide a functional specification. + + + The developer shall provide a tracing from the functional + specification to the SFRs. + + + The functional specification shall completely represent the + TSF. + + + The functional specification shall describe the purpose and + method of use for all TSFI. + + + The functional specification shall identify and describe all + parameters associated with each TSFI. + + + For each SFR-enforcing TSFI, the functional specification shall + describe the SFR-enforcing actions associated with the TSFI. + + + For each SFR-enforcing TSFI, the functional specification shall + describe direct error messages resulting from processing + associated with the SFR-enforcing actions. + + + The tracing shall demonstrate that the SFRs trace to TSFIs + in the functional specification. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the functional specification + to determine that the TSF is fully represented. + + The identification of the TSFI is a necessary + prerequisite to all other activities in this + sub-activity. The TSF must be identified (done as part + of the work units) in + order to identify the TSFI. This activity can be done at + a high level to ensure that no large groups of + interfaces have been missed (network protocols, hardware + interfaces, configuration files), or at a low level as + the evaluation of the functional specification + proceeds. + + In making an assessment for this work unit, the + evaluator determines that all portions of the TSF are + addressed in terms of the interfaces listed in the + functional specification. All portions of the TSF should + have a corresponding interface description, or if there + are no corresponding interfaces for a portion of the + TSF, the evaluator determines that that is + acceptable. + + + + + The evaluator shall examine the functional specification + to determine that it states the purpose of each + TSFI. + + The purpose of a TSFI is a general statement summarising + the functionality provided by the interface. It is not + intended to be a complete statement of the actions and + results related to the interface, but rather a statement + to help the reader understand in general what the + interface is intended to be used for. The evaluator + should not only determine that the purpose exists, but + also that it accurately reflects the TSFI by taking into + account other information about the interface, such as + the description of actions and error messages. + + + + + The evaluator shall examine the functional specification + to determine that the method of use for each TSFI is + given. + + The method of use for a TSFI summarises how the + interface is manipulated in order to invoke the actions + and obtain the results associated with the TSFI. The + evaluator should be able to determine, from reading this + material in the functional specification, how to use + each interface. This does not necessarily mean that + there needs to be a separate method of use for each + TSFI, as it may be possible to describe in general how + kernel calls are invoked, for instance, and then + identify each interface using that general + style. Different types of interfaces will require + different method of use specifications. APIs, network + protocol interfaces, system configuration parameters, + and hardware bus interfaces all have very different + methods of use, and this should be taken into account by + the developer when developing the functional + specification, as well as by the evaluator evaluating + the functional specification. + + For administrative interfaces whose functionality is documented + as being inaccessible to untrusted users, the evaluator ensures + that the method of making the functions inaccessible is + described in the functional specification. It should be noted + that this inaccessibility needs to be tested by the developer in + their test suite. + + The evaluator should not only determine that the set of + method of use descriptions exist, but also that they + accurately cover each TSFI. + + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely identifies all + parameters associated with every TSFI. + + The evaluator examines the functional specification to + ensure that all of the parameters are described for each + TSFI. Parameters are explicit inputs or outputs to an + interface that control the behaviour of that + interface. For examples, parameters are the arguments + supplied to an API; the various fields in packet for a + given network protocol; the individual key values in the + Windows Registry; the signals across a set of pins on a + chip; etc. + + In order to determine that all of the parameters are + present in the TSFI, the evaluator should examine the + rest of the interface description (actions, error + messages, etc.) to determine if the effects of the + parameter are accounted for in the description. The + evaluator should also check other evidence provided for + the evaluation (e.g., TOE design, security architecture + description, operational user guidance, implementation + representation) to see if behaviour or additional + parameters are described there but not in the functional + specification. + + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely and accurately describes + all parameters associated with every TSFI. + + Once all of the parameters have been identified, the + evaluator needs to ensure that they are accurately + described, and that the description of the parameters is + complete. A parameter description tells what the + parameter is in some meaningful way. For instance, the + interface foo(i) could be described as + having ``parameter i which is an integer"; this is not + an acceptable parameter description. A description such + as ``parameter i is an integer that indicates the number + of users currently logged in to the system'' is much + more acceptable. + + In order to determine that the description of the + parameters is complete, the evaluator should examine the + rest of the interface description (purpose, method of + use, actions, error messages, etc.) to determine if the + descriptions of the parameter(s) are accounted for in + the description. The evaluator should also check other + evidence provided (e.g., TOE design, architectural + design, operational user guidance, implementation + representation) to see if behaviour or additional + parameters are described there but not in the functional + specification. + + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely and accurately describes + the SFR-enforcing actions associated with the + SFR-enforcing TSFIs. + + If an action available through an interface can be + traced to one of the SFRs levied on the TSF, then that + interface is SFR-enforcing. Such + policies are not limited to the access control policies, + but also refer to any functionality specified by one of + the SFRs contained in the ST. Note that it is possible + that an interface may have various actions and results, + some of which may be SFR-enforcing and some of which may not. + + The developer is not required to ``label'' interfaces as + SFR-enforcing, and likewise is not required to identify + actions available through an interface as SFR-enforcing. + It is the evaluator's responsibility to examine the + evidence provided by the developer and determine that + the required information is present. In the case where + the developer has identified the SFR-enforcing TSFI and + SFR-enforcing actions available through those TSFI, the + evaluator must judge completeness and accuracy based on + other information supplied for the evaluation (e.g., TOE + design, security architecture description, operational + user guidance), and on the other information presented + for the interfaces (parameters and parameter + descriptions, error messages, etc.). + + In this case (where the developer has provided only the + SFR-enforcing information for SFR-enforcing TSFI) the + evaluator also ensures that no interfaces have been + mis-categorised. This is done by examining other + information supplied for the evaluation (e.g., TOE + design, security architecture description, operational + user guidance), and the other information presented for + the interfaces (parameters and parameter descriptions, + for example) not labelled as SFR-enforcing. + + In the case where the developer has provided the same + level of information on all interfaces, the evaluator + performs the same type of analysis mentioned in the + previous paragraphs. The evaluator should determine + which interfaces are SFR-enforcing and which are not, + and subsequently ensure that the SFR-enforcing aspects + of the SFR-enforcing actions are appropriately + described. + The SFR-enforcing actions are those that are + visible at any external interface and that provide for + the enforcement of the SFRs being claimed. For example, + if audit requirements are included in the ST, then + audit-related actions would be SFR-enforcing and + therefore must be described, even if the result of that + action is generally not visible through the invoked + interface (as is often the case with audit, where a user + action at one interface would produce an audit record + visible at another interface). + + The level of description that is required is that + sufficient for the reader to understand what role the + TSFI actions play with respect to the SFR. The + evaluator should keep in mind that the description + should be detailed enough to support the generation (and + assessment) of test cases against that interface. If + the description is unclear or lacking detail such that + meaningful testing cannot be conducted against the TSFI, + it is likely that the description is inadequate. + + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely and accurately describes + error messages that may result from SFR-enforcing + actions associated with each SFR-enforcing TSFI. + + This work unit should be performed in conjunction with, + or after, work unit + in order to ensure the set of SFR-enforcing TSFI and + SFR-enforcing actions is correctly identified. The + developer may provide more information than is required + (for example, all error messages associated with each + interface), in which the case the evaluator should + restrict their assessment of completeness and accuracy + to only those that they determine to be associated with + SFR-enforcing actions of SFR-enforcing TSFI. + + Errors can take many forms, depending on the interface + being described. For an API, the interface itself may + return an error code, set a global error condition, or + set a certain parameter with an error code. For a + configuration file, an incorrectly configured parameter + may cause an error message to be written to a log + file. For a hardware PCI card, an error condition may + raise a signal on the bus, or trigger an exception + condition to the CPU. + + Errors (and the associated error messages) come about + through the invocation of an interface. The processing + that occurs in response to the interface invocation may + encounter error conditions, which trigger (through an + implementation-specific mechanism) an error message to + be generated. In some instances this may be a return + value from the interface itself; in other instances a + global value may be set and checked after the invocation + of an interface. It is likely that a TOE will have a + number of low-level error messages that may result from + fundamental resource conditions, such as ``disk full'' + or ``resource locked''. While these error messages may + map to a large number of TSFI, they could be used to + detect instances where detail from an interface + description has been omitted. For instance, a TSFI that + produces a ``disk full'' message, but has no obvious + description of why that TSFI should cause an access to + the disk in its description of actions, might cause the + evaluator to examine other evidence (, ) related + that TSFI to determine if the description is + accurate. + In order to determine that the description of the + error messages of a TSFI is accurate and complete, the + evaluator measures the interface description against the + other evidence provided for the evaluation (e.g., TOE + design, security architecture description, operational + user guidance), as well as other evidence available for + that TSFI (parameters, analysis from work unit ). + + + + The evaluator shall check that the tracing links the + SFRs to the corresponding TSFIs. + + The tracing is provided by the developer to serve as a + guide to which SFRs are related to which TSFIs. This + tracing can be as simple as a table; it is used as input + to the evaluator for use in the following work units, in + which the evaluator verifies its completeness and + accuracy. + + + + The evaluator shall determine that the functional + specification is an accurate and complete instantiation of + the SFRs. + + + The evaluator shall examine the functional specification + to determine that it is a complete instantiation of the + SFRs. + + To ensure that all SFRs are covered by the functional + specification, as well as the test coverage analysis, + the evaluator may build upon the developer's tracing + (see a map between + the TOE security functional requirements and the TSFI. + Note that this map may have to be at a level of detail + below the component or even element level of the + requirements, because of operations (assignments, + refinements, selections) performed on the functional + requirement by the ST author. + + For example, the + component contains an element with assignments. If the + ST contained, for instance, ten rules in the assignment, and these ten + rules were covered by three different TSFI, it would be + inadequate for the evaluator to map to TSFI A, B, and C and claim they had + completed the work unit. Instead, the evaluator would + map (rule 1) to TSFI A; + (rule 2) to TSFI B; + etc. It might also be the case that the interface is a + wrapper interface (e.g., IOCTL), in which case the + mapping would need to be specific to certain set of + parameters for a given interface. + + The evaluator must recognise that for requirements that + have little or no manifestation at the TSF boundary + (e.g., ) it is not + expected that they completely map those requirements to + the TSFI. The analysis for those requirements will be + performed in the analysis for the TOE design () when included in the ST. It is + also important to note that since the parameters, + actions, and error messages associated with TSFIs must + be fully specified, the evaluator should be able to + determine if all aspects of an SFR appear to be + implemented at the interface level. + + + + The evaluator shall examine the functional specification + to determine that it is an accurate instantiation of the + SFRs. + + For each functional requirement in the ST that results + in effects visible at the TSF boundary, the information + in the associated TSFI for that requirement specifies + the required functionality described by the + requirement. For example, if the ST contains a + requirement for access control lists, and the only TSFI + that map to that requirement specify functionality for + Unix-style protection bits, then the functional + specification is not accurate with respect to the + requirements. + + The evaluator must recognise that for requirements that + have little or no manifestation at the TSF boundary + (e.g., ) it is not + expected that the evaluator completely map those + requirements to the TSFI. The analysis for those + requirements will be performed in the analysis for the + TOE design () when + included in the ST. + + + + + + + + + The objective of this sub-activity is to determine whether + the developer has provided a description of the TSFIs in + terms of their purpose, method of use, and parameters. In + addition, the actions, results and error messages of each + TSFI are also described sufficiently that it can be + determined whether they are SFR-enforcing, with the + SFR-enforcing TSFI being described in more detail than + other TSFIs. + + + + The evaluation evidence for this sub-activity that is + required by the work-units is: + + + the ST; + + + the functional specification; + + + the TOE design. + + + + The evaluation evidence for this sub-activity that is used + if included in the ST for the TOE is: + + + the security architecture description; + + + the implementation representation; + + + the TSF internals description; + + + the operational user guidance; + + + + + The developer shall provide a functional specification. + + + The developer shall provide a tracing from the functional + specification to the SFRs. + + + The functional specification shall completely represent the + TSF. + + + The functional specification shall describe the purpose and + method of use for all TSFI. + + + The functional specification shall identify and describe all + parameters associated with each TSFI. + + + For each SFR-enforcing TSFI, the functional specification shall + describe the SFR-enforcing actions associated with the TSFI. + + + For each SFR-enforcing TSFI, the functional specification shall + describe direct error messages resulting from SFR-enforcing + actions and exceptions associated with invocation of the TSFI. + + + The functional specification shall summarise the SFR-supporting + and SFR-non-interfering actions associated with each TSFI. + + + The tracing shall demonstrate that the SFRs trace to TSFIs + in the functional specification. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the functional specification + to determine that the TSF is fully represented. + + The identification of the TSFI is a necessary + prerequisite to all other activities in this + sub-activity. The TSF must be identified (done as part + of the work units) in + order to identify the TSFI. This activity can be done at + a high level to ensure that no large groups of + interfaces have been missed (network protocols, hardware + interfaces, configuration files), or at a low level as + the evaluation of the functional specification + proceeds. + + In making an assessment for this work unit, the + evaluator determines that all portions of the TSF are + addressed in terms of the interfaces listed in the + functional specification. All portions of the TSF should + have a corresponding interface description, or if there + are no corresponding interfaces for a portion of the + TSF, the evaluator determines that that is + acceptable. + + + + + The evaluator shall examine the functional specification + to determine that it states the purpose of each + TSFI. + + The purpose of a TSFI is a general statement summarising + the functionality provided by the interface. It is not + intended to be a complete statement of the actions and + results related to the interface, but rather a statement + to help the reader understand in general what the + interface is intended to be used for. The evaluator + should not only determine that the purpose exists, but + also that it accurately reflects the TSFI by taking into + account other information about the interface, such as + the description of actions and error messages. + + + + + The evaluator shall examine the functional specification + to determine that the method of use for each TSFI is + given. + + The method of use for a TSFI summarises how the + interface is manipulated in order to invoke the actions + and obtain the results associated with the TSFI. The + evaluator should be able to determine, from reading this + material in the functional specification, how to use + each interface. This does not necessarily mean that + there needs to be a separate method of use for each + TSFI, as it may be possible to describe in general how + kernel calls are invoked, for instance, and then + identify each interface using that general + style. Different types of interfaces will require + different method of use specifications. APIs, network + protocol interfaces, system configuration parameters, + and hardware bus interfaces all have very different + methods of use, and this should be taken into account by + the developer when developing the functional + specification, as well as by the evaluator evaluating + the functional specification. + + For administrative interfaces whose functionality is documented + as being inaccessible to untrusted users, the evaluator ensures + that the method of making the functions inaccessible is + described in the functional specification. It should be noted + that this inaccessibility needs to be tested by the developer in + their test suite. + + The evaluator should not only determine that the set of + method of use descriptions exist, but also that they + accurately cover each TSFI. + + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely identifies all + parameters associated with every TSFI. + + The evaluator examines the functional specification to + ensure that all of the parameters are described for each + TSFI. Parameters are explicit inputs or outputs to an + interface that control the behaviour of that + interface. For examples, parameters are the arguments + supplied to an API; the various fields in packet for a + given network protocol; the individual key values in the + Windows Registry; the signals across a set of pins on a + chip; etc. + + In order to determine that all of the parameters are + present in the TSFI, the evaluator should examine the + rest of the interface description (actions, error + messages, etc.) to determine if the effects of the + parameter are accounted for in the description. The + evaluator should also check other evidence provided for + the evaluation (e.g., TOE design, security architecture + description, operational user guidance, implementation + representation) to see if behaviour or additional + parameters are described there but not in the functional + specification. + + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely and accurately describes + all parameters associated with every TSFI. + + Once all of the parameters have been identified, the + evaluator needs to ensure that they are accurately + described, and that the description of the parameters is + complete. A parameter description tells what the + parameter is in some meaningful way. For instance, the + interface foo(i) could be described as + having ``parameter i which is an integer''; this is not + an acceptable parameter description. A description such + as ``parameter i is an integer that indicates the number + of users currently logged in to the system'' is much + more acceptable. + + In order to determine that the description of the + parameters is complete, the evaluator should examine the + rest of the interface description (purpose, method of + use, actions, error messages, etc.) to determine if the + descriptions of the parameter(s) are accounted for in + the description. The evaluator should also check other + evidence provided (e.g., TOE design, architectural + design, operational user guidance, implementation + representation) to see if behaviour or additional + parameters are described there but not in the functional + specification. + + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely and accurately describes + the SFR-enforcing actions associated with the + SFR-enforcing TSFIs. + + If an action available through an interface plays a role + in enforcing any security policy on the TOE (that is, if + one of the actions of the interface can be traced to one + of the SFRs levied on the TSF), then that interface is + SFR-enforcing. Such policies are not + limited to the access control policies, but also refer + to any functionality specified by one of the SFRs + contained in the ST. Note that it is possible that an + interface may have various actions and results, some of + which may be SFR-enforcing and some of which may + not. + The developer is not required to ``label'' + interfaces as SFR-enforcing, and likewise is not + required to identify actions available through an + interface as SFR-enforcing. It is the evaluator's + responsibility to examine the evidence provided by the + developer and determine that the required information is + present. In the case where the developer has identified + the SFR-enforcing TSFI and SFR-enforcing actions + available through those TSFI, the evaluator must judge + completeness and accuracy based on other information + supplied for the evaluation (e.g., TOE design, security + architecture description, operational user guidance), + and on the other information presented for the + interfaces (parameters and parameter descriptions, error + messages, etc.). + + In this case (developer has provided only the + SFR-enforcing information for SFR-enforcing TSFI) the + evaluator also ensures that no interfaces have been + mis-categorised. This is done by examining other + information supplied for the evaluation (e.g., TOE + design, security architecture description, operational + user guidance), and the other information presented for + the interfaces (parameters and parameter descriptions, + for example) not labelled as SFR-enforcing. The analysis + done for work units + and are also used in + making this determination. + In the case where the developer has provided the + same level of information on all interfaces, the + evaluator performs the same type of analysis mentioned + in the previous paragraphs. The evaluator should + determine which interfaces are SFR-enforcing and which + are not, and subsequently ensure that the SFR-enforcing + aspects of the SFR-enforcing actions are appropriately + described. Note that in this case, the evaluator should + be able to perform the bulk of the work associated with + work unit in the + course of performing this SFR-enforcing analysis. + The SFR-enforcing actions are those that are + visible at any external interface and that provide for + the enforcement of the SFRs being claimed. For example, + if audit requirements are included in the ST, then + audit-related actions would be SFR-enforcing and + therefore must be described, even if the result of that + action is generally not visible through the invoked + interface (as is often the case with audit, where a user + action at one interface would produce an audit record + visible at another interface). + + The level of description that is required is that + sufficient for the reader to understand what role the + TSFI actions play with respect to the SFR. The + evaluator should keep in mind that the description + should be detailed enough to support the generation (and + assessment) of test cases against that interface. If + the description is unclear or lacking detail such that + meaningful testing cannot be conducted against the TSFI, + it is likely that the description is inadequate. + + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely and accurately describes + error messages that may result from an invocation of + each SFR-enforcing TSFI. + + This work unit should be performed in conjunction with, or + after, work unit in order + to ensure the set of SFR-enforcing TSFI is correctly identified. + The evaluator should note that the requirement and associated + work unit is that all direct error messages associated with an + SFR-enforcing TSFI must be described, that are associated with + SFR-enforcing actions. This is because at this level of + assurance, the ``extra'' information provided by the error + message descriptions should be used in determining whether all + of the SFR-enforcing aspects of an interface have been + appropriately described. For instance, if an error message + associated with a TSFI (e.g., ``access denied'') indicated that + an SFR-enforcing decision or action had taken place, but in the + description of the SFR-enforcing actions there was no mention of + that particular SFR-enforcing mechanism, then the description + may not be complete. + + Errors can take many forms, depending on the interface + being described. For an API, the interface itself may + return an error code, set a global error condition, or + set a certain parameter with an error code. For a + configuration file, an incorrectly configured parameter + may cause an error message to be written to a log + file. For a hardware PCI card, an error condition may + raise a signal on the bus, or trigger an exception + condition to the CPU. + + Errors (and the associated error messages) come about + through the invocation of an interface. The processing + that occurs in response to the interface invocation may + encounter error conditions, which trigger (through an + implementation-specific mechanism) an error message to + be generated. In some instances this may be a return + value from the interface itself; in other instances a + global value may be set and checked after the invocation + of an interface. It is likely that a TOE will have a + number of low-level error messages that may result from + fundamental resource conditions, such as ``disk full'' + or ``resource locked''. While these error messages may + map to a large number of TSFI, they could be used to + detect instances where detail from an interface + description has been omitted. For instance, a TSFI that + produces a ``disk full'' message, but has no obvious + description of why that TSFI should cause an access to + the disk in its description of actions, might cause the + evaluator to examine other evidence (, ) related + that TSFI to determine if the description is + accurate. + + In order to determine that the description of the error messages + of a TSFI is accurate and complete, the evaluator measures the + interface description against the other evidence provided for + the evaluation (e.g., TOE design, security architecture + description, operational user guidance), as well as for other + evidence supplied for that TSFI (description of SFR-enforcing + actions, summary of SFR-supporting and SFR-non-interfering + actions and results). + + + + + The evaluator shall examine the presentation of the TSFI to + determine that it summarises the SFR-supporting and + SFR-non-interfering actions associated with each TSFI. + + The purpose of this work unit is to supplement the details about + the SFR-enforcing actions (provided in work unit ) with a summary of the remaining + actions (i.e., those that are not SFR-enforcing). This covers + all SFR-supporting and SFR-non-interfering + actions, whether invokable through SFR-enforcing TSFI or through + SFR-supporting or SFR-non-interfering TSFI. Such a summary + about all SFR-supporting and SFR-non-interfering actions helps + to provide a more complete picture of the functions provided by + the TSF, and is to be used by the evaluator in determining + whether an action or TSFI may have been mis-categorised. + + The information to be provided is more abstract than that + required for SFR-enforcing actions. While it should still be + detailed enough so that the reader can understand what the + action does, the description does not have to be detailed enough + to support writing tests against it, for instance. For the + evaluator, the key is that the information must be sufficient to + make a positive determination that the action is SFR-supporting + or SFR-non-interfering. If that level of information is + missing, the summary is insufficient and more information must + be obtained. + + + + The evaluator shall check that the tracing links the + SFRs to the corresponding TSFIs. + + The tracing is provided by the developer to serve as a + guide to which SFRs are related to which TSFIs. This + tracing can be as simple as a table; it is used as input + to the evaluator for use in the following work units, in + which the evaluator verifies its completeness and + accuracy. + + + + The evaluator shall determine that the functional + specification is an accurate and complete instantiation of + the SFRs. + + + The evaluator shall examine the functional specification + to determine that it is a complete instantiation of the + SFRs. + + To ensure that all SFRs are covered by the functional + specification, as well as the test coverage analysis, + the evaluator may build upon the developer's tracing + (see a map between + the TOE security functional requirements and the TSFI. + Note that this map may have to be at a level of detail + below the component or even element level of the + requirements, because of operations (assignments, + refinements, selections) performed on the functional + requirement by the ST author. + + For example, the + component contains an element with assignments. If the + ST contained, for instance, ten rules in the assignment, and these ten + rules were covered by three different TSFI, it would be + inadequate for the evaluator to map to TSFI A, B, and C and claim they had + completed the work unit. Instead, the evaluator would + map (rule 1) to TSFI A; + (rule 2) to TSFI B; + etc. It might also be the case that the interface is a + wrapper interface (e.g., IOCTL), in which case the + mapping would need to be specific to certain set of + parameters for a given interface. + + The evaluator must recognise that for requirements that + have little or no manifestation at the TSF boundary + (e.g., ) it is not + expected that they completely map those requirements to + the TSFI. The analysis for those requirements will be + performed in the analysis for the TOE design () when included in the ST. It is + also important to note that since the parameters, + actions, and error messages associated with TSFIs must + be fully specified, the evaluator should be able to + determine if all aspects of an SFR appear to be + implemented at the interface level. + + + + The evaluator shall examine the functional specification + to determine that it is an accurate instantiation of the + SFRs. + + For each functional requirement in the ST that results + in effects visible at the TSF boundary, the information + in the associated TSFI for that requirement specifies + the required functionality described by the + requirement. For example, if the ST contains a + requirement for access control lists, and the only TSFI + that map to that requirement specify functionality for + Unix-style protection bits, then the functional + specification is not accurate with respect to the + requirements. + + The evaluator must recognise that for requirements that + have little or no manifestation at the TSF boundary + (e.g., ) it is not + expected that the evaluator completely map those + requirements to the TSFI. The analysis for those + requirements will be performed in the analysis for the + TOE design () when + included in the ST. + + + + + + + + + The objective of this sub-activity is to determine whether + the developer has completely described all of the TSFI in + a manner such that the evaluator is able to determine + whether the TSFI are completely and accurately described, + and appears to implement the security functional + requirements of the ST. + + + + The functional specification describes the interfaces to + the TSF (the TSFI) in a structured manner. Because of the + dependency on , the + evaluator is expected to have identified the TSF prior to + beginning work on this sub-activity. Without firm + knowledge of what comprises the TSF, it is not possible to + assess the completeness of the TSFI. + + In performing the various work units included in this family, + the evaluator is asked to make assessments of accuracy and + completeness of several factors (the TSFI itself, as well as the + individual components (parameters, actions, error messages, + etc.) of the TSFI). In doing this analysis, the evaluator is + expected to use the documentation provided for the + evaluation. This includes the ST, the TOE design, and may + include other documentation such as the operational user + guidance, security architecture description, and implementation + representation. The documentation should be examined in an + iterative fashion. The evaluator may read, for example, in the + TOE design how a certain function is implemented, but see no way + to invoke that function from the interface. This might cause the + evaluator to question the completeness of a particular TSFI + description, or whether an interface has been left out of the + functional specification altogether. Describing analysis + activities of this sort in the ETR is a key method in providing + rationale that the work units have been performed + appropriately. + + It should be recognised that there exist functional + requirements whose functionality is manifested wholly or + in part architecturally, rather than through a specific + mechanism. An example of this is the implementation of + mechanisms implementing the requirements. Such mechanisms typically are + implemented to ensure a behaviour isn't present, which is + difficult to test and typically is verified through + analysis. In the cases where such functional requirements + are included in the ST, it is expected that the evaluator + recognise that there may be SFRs of this type that have no + interfaces, and that this should not be considered a + deficiency in the functional specification. + + + + The evaluation evidence for this sub-activity that is + required by the work-units is: + + + the ST; + + + the functional specification; + + + the TOE design. + + + + The evaluation evidence for this sub-activity that is used + if included in the ST for the TOE is: + + + the security architecture description; + + + the implementation representation; + + + the TSF internals description; + + + the operational user guidance; + + + + + The developer shall provide a functional specification. + + + The developer shall provide a tracing from the functional + specification to the SFRs. + + + The functional specification shall completely represent the + TSF. + + + The functional specification shall describe the purpose and + method of use for all TSFI. + + + The functional specification shall identify and describe all + parameters associated with each TSFI. + + + The functional specification shall describe all actions + associated with each TSFI. + + + The functional specification shall describe all direct error + messages that may result from an invocation of each TSFI. + + + The tracing shall demonstrate that the SFRs trace to TSFIs + in the functional specification. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the functional specification + to determine that the TSF is fully represented. + + The identification of the TSFI is a necessary + prerequisite to all other activities in this + sub-activity. The TSF must be identified (done as part + of the work units) in + order to identify the TSFI. This activity can be done at + a high level to ensure that no large groups of + interfaces have been missed (network protocols, hardware + interfaces, configuration files), or at a low level as + the evaluation of the functional specification + proceeds. + + In making an assessment for this work unit, the + evaluator determines that all portions of the TSF are + addressed in terms of the interfaces listed in the + functional specification. All portions of the TSF should + have a corresponding interface description, or if there + are no corresponding interfaces for a portion of the + TSF, the evaluator determines that that is + acceptable. + + + + + The evaluator shall examine the functional specification + to determine that it states the purpose of each + TSFI. + + The purpose of a TSFI is a general statement summarising + the functionality provided by the interface. It is not + intended to be a complete statement of the actions and + results related to the interface, but rather a statement + to help the reader understand in general what the + interface is intended to be used for. The evaluator + should not only determine that the purpose exists, but + also that it accurately reflects the TSFI by taking into + account other information about the interface, such as + the description of actions and error messages. + + + + + The evaluator shall examine the functional specification + to determine that the method of use for each TSFI is + given. + + The method of use for a TSFI summarises how the + interface is manipulated in order to invoke the actions + and obtain the results associated with the TSFI. The + evaluator should be able to determine, from reading this + material in the functional specification, how to use + each interface. This does not necessarily mean that + there needs to be a separate method of use for each + TSFI, as it may be possible to describe in general how + kernel calls are invoked, for instance, and then + identify each interface using that general + style. Different types of interfaces will require + different method of use specifications. APIs, network + protocol interfaces, system configuration parameters, + and hardware bus interfaces all have very different + methods of use, and this should be taken into account by + the developer when developing the functional + specification, as well as by the evaluator evaluating + the functional specification. + + For administrative interfaces whose functionality is documented + as being inaccessible to untrusted users, the evaluator ensures + that the method of making the functions inaccessible is + described in the functional specification. It should be noted + that this inaccessibility needs to be tested by the developer in + their test suite. + + The evaluator should not only determine that the set of + method of use descriptions exist, but also that they + accurately cover each TSFI. + + The evaluator shall examine the functional specification to + determine the completeness of the TSFI + The evaluator shall use the design documentation to identify the possible types of + interfaces. The evaluator shall search the design documentation and the guidance + documentation for potential TSFI not contained in the developer's documentation, + thus indicating that the set of TSFI defined by the developer is incomplete. The + evaluator shall examine the arguments presented by the developer that the TSFI is + complete and check down to the lowest level of design or with the + implementation representation that no additional TSFI exist. + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely identifies all + parameters associated with every TSFI. + + The evaluator examines the functional specification to + ensure that all of the parameters are described for each + TSFI. Parameters are explicit inputs or outputs to an + interface that control the behaviour of that + interface. For examples, parameters are the arguments + supplied to an API; the various fields in packet for a + given network protocol; the individual key values in the + Windows Registry; the signals across a set of pins on a + chip; etc. + + In order to determine that all of the parameters are + present in the TSFI, the evaluator should examine the + rest of the interface description (actions, error + messages, etc.) to determine if the effects of the + parameter are accounted for in the description. The + evaluator should also check other evidence provided for + the evaluation (e.g., TOE design, security architecture + description, operational user guidance, implementation + representation) to see if behaviour or additional + parameters are described there but not in the functional + specification. + + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely and accurately describes + all parameters associated with every TSFI. + + Once all of the parameters have been identified, the + evaluator needs to ensure that they are accurately + described, and that the description of the parameters is + complete. A parameter description tells what the + parameter is in some meaningful way. For instance, the + interface foo(i) could be described as + having ``parameter i which is an integer''; this is not + an acceptable parameter description. A description such + as ``parameter i is an integer that indicates the number + of users currently logged in to the system'' is much + more acceptable. + + In order to determine that the description of the + parameters is complete, the evaluator should examine the + rest of the interface description (purpose, method of + use, actions, error messages, etc.) to determine if the + descriptions of the parameter(s) are accounted for in + the description. The evaluator should also check other + evidence provided (e.g., TOE design, architectural + design, operational user guidance, implementation + representation) to see if behaviour or additional + parameters are described there but not in the functional + specification. + + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely and accurately describes + all actions associated with every TSFI. + + The evaluator checks to ensure that all of the actions + are described. actions available through an interface + describe what the interface does (as opposed to the TOE + design, which describes how the actions are provided by + the TSF). + + Actions of an interface describe functionality that can + be invoked through the interface, and can be categorised + as regular actions, and + SFR-related actions. Regular actions + are descriptions of what the interface does. The amount + of information provided for this description is + dependant on the complexity of the interface. The + SFR-related actions are those that are visible at any + external interface (for instance, audit activity caused + by the invocation of an interface (assuming audit + requirements are included in the ST) should be + described, even though the result of that action is + generally not visible through the invoked + interface). Depending on the parameters of an interface, + there may be many different actions able to be invoked + through the interface (for instance, an API might have + the first parameter be a ``subcommand'', and the + following parameters be specific to that subcommand. The + IOCTL API in some Unix systems is an example of such an + interface). + + In order to determine that the description of the + actions of a TSFI is complete, the evaluator should + review the rest of the interface description (parameter + descriptions, error messages, etc.) to determine if the + actions described are accounted for. The evaluator + should also analyse other evidence provided for the + evaluation (e.g., TOE design, security architecture + description, operational user guidance, implementation + representation) to see if there is evidence of actions + that are described there but not in the functional + specification. + + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely and accurately describes + all errors messages resulting from an invocation of each + TSFI. + + Errors can take many forms, depending on the interface + being described. For an API, the interface itself may + return an error code; set a global error condition, or + set a certain parameter with an error code. For a + configuration file, an incorrectly configured parameter + may cause an error message to be written to a log + file. For a hardware PCI card, an error condition may + raise a signal on the bus, or trigger an exception + condition to the CPU. + + Errors (and the associated error messages) come about + through the invocation of an interface. The processing + that occurs in response to the interface invocation may + encounter error conditions, which trigger (through an + implementation-specific mechanism) an error message to + be generated. In some instances this may be a return + value from the interface itself; in other instances a + global value may be set and checked after the invocation + of an interface. It is likely that a TOE will have a + number of low-level error messages that may result from + fundamental resource conditions, such as ``disk full'' + or ``resource locked''. While these error messages may + map to a large number of TSFI, they could be used to + detect instances where detail from an interface + description has been omitted. For instance, a TSFI that + produces a ``disk full'' message, but has no obvious + description of why that TSFI should cause an access to + the disk in its description of actions, might cause the + evaluator to examine other evidence (, ) related + that TSFI to determine if the description is complete + and accurate. + + The evaluator determines that, for each TSFI, the exact + set of error messages that can be returned on invoking + that interface can be determined. The evaluator reviews + the evidence provided for the interface to determine if + the set of errors seems complete. They cross-check this + information with other evidence provided for the + evaluation (e.g., TOE design, security architecture + description, operational user guidance, implementation + representation) to ensure that there are no errors + steaming from processing mentioned that are not included + in the functional specification. + + + + + The evaluator shall examine the presentation of the TSFI to determine + that it completely and accurately describes the meaning of all + error messages resulting from an invocation of each TSFI. + + In order to determine accuracy, the evaluator must be + able to understand meaning of the error. For example, if + an interface returns a numeric code of 0, 1, or 2, the + evaluator would not be able to understand the error if + the functional specification only listed: ``possible + errors resulting from invocation of the + foo() interface are 0, 1, or + 2''. Instead the evaluator checks to ensure that the + errors are described such as: ``possible errors + resulting from invocation of the foo() + interface are 0 (processing successful), 1 (file not + found), or 2 (incorrect filename + specification)''. + + In order to determine that the description of the errors + due to invoking a TSFI is complete, the evaluator + examines the rest of the interface description + (parameter descriptions, actions, etc.) to determine if + potential error conditions that might be caused by using + such an interface are accounted for. The evaluator also + checks other evidence provided for the evaluation + (e.g. TOE design, security architecture description, + operational user guidance, implementation + representation) to see if error processing related to + the TSFI is described there but is not described in the + functional specification. + + + + The evaluator shall check that the tracing links the + SFRs to the corresponding TSFIs. + + The tracing is provided by the developer to serve as a + guide to which SFRs are related to which TSFIs. This + tracing can be as simple as a table; it is used as input + to the evaluator for use in the following work units, in + which the evaluator verifies its completeness and + accuracy. + + + + The evaluator shall determine that the functional + specification is an accurate and complete instantiation of + the SFRs. + + + The evaluator shall examine the functional specification + to determine that it is a complete instantiation of the + SFRs. + + To ensure that all SFRs are covered by the functional + specification, as well as the test coverage analysis, + the evaluator may build upon the developer's tracing + (see a map between + the TOE security functional requirements and the TSFI. + Note that this map may have to be at a level of detail + below the component or even element level of the + requirements, because of operations (assignments, + refinements, selections) performed on the functional + requirement by the ST author. + + For example, the + component contains an element with assignments. If the + ST contained, for instance, ten rules in the assignment, and these ten + rules were covered by three different TSFI, it would be + inadequate for the evaluator to map to TSFI A, B, and C and claim they had + completed the work unit. Instead, the evaluator would + map (rule 1) to TSFI A; + (rule 2) to TSFI B; + etc. It might also be the case that the interface is a + wrapper interface (e.g., IOCTL), in which case the + mapping would need to be specific to certain set of + parameters for a given interface. + + The evaluator must recognise that for requirements that + have little or no manifestation at the TSF boundary + (e.g., ) it is not + expected that they completely map those requirements to + the TSFI. The analysis for those requirements will be + performed in the analysis for the TOE design () when included in the ST. It is + also important to note that since the parameters, + actions, and error messages associated with TSFIs must + be fully specified, the evaluator should be able to + determine if all aspects of an SFR appear to be + implemented at the interface level. + + + + The evaluator shall examine the functional specification + to determine that it is an accurate instantiation of the + SFRs. + + For each functional requirement in the ST that results + in effects visible at the TSF boundary, the information + in the associated TSFI for that requirement specifies + the required functionality described by the + requirement. For example, if the ST contains a + requirement for access control lists, and the only TSFI + that map to that requirement specify functionality for + Unix-style protection bits, then the functional + specification is not accurate with respect to the + requirements. + + The evaluator must recognise that for requirements that + have little or no manifestation at the TSF boundary + (e.g., ) it is not + expected that the evaluator completely map those + requirements to the TSFI. The analysis for those + requirements will be performed in the analysis for the + TOE design () when + included in the ST. + + + + + + + + + + The objective of this sub-activity is to determine whether + the developer has completely described all of the TSFI in + a manner such that the evaluator is able to determine + whether the TSFI are completely and accurately described, + and appears to implement the security functional + requirements of the ST. The completeness of the interfaces + is judged based upon the implementation + representation. + + + + The evaluation evidence for this sub-activity that is + required by the work-units is: + + + the ST; + + + the functional specification; + + + the TOE design; + + + the implementation representation. + + + + The evaluation evidence for this sub-activity that is used + if included in the ST for the TOE is: + + + the security architecture description; + + + the TSF internals description; + + + the formal security policy model; + + + the operational user guidance; + + + + + The developer shall provide a functional specification. + + + The developer shall provide a tracing from the functional + specification to the SFRs. + + + The functional specification shall completely represent the + TSF. + + + The functional specification shall describe the TSFI using a + semi-formal style. + + + The functional specification shall describe the purpose and + method of use for all TSFI. + + + The functional specification shall identify and describe all + parameters associated with each TSFI. + + + The functional specification shall describe all actions + associated with each TSFI. + + + The functional specification shall describe all direct error + messages that may result from an invocation of each TSFI. + + The functional specification + shall describe all error messages that do not result from an + invocation of a TSFI. + + + The functional specification shall provide a rationale for + each error message contained in the TSF implementation yet + does not result from an invocation of a TSFI. + + + The tracing shall demonstrate that the SFRs trace to TSFIs + in the functional specification. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + The evaluator shall examine the functional specification + to determine that the TSF is fully represented. + + The identification of the TSFI is a necessary + prerequisite to all other activities in this + sub-activity. The TSF must be identified (done as part + of the work units) in + order to identify the TSFI. This activity can be done at + a high level to ensure that no large groups of + interfaces have been missed (network protocols, hardware + interfaces, configuration files), or at a low level as + the evaluation of the functional specification + proceeds. + + In making an assessment for this work unit, the + evaluator determines that all portions of the TSF are + addressed in terms of the interfaces listed in the + functional specification. All portions of the TSF should + have a corresponding interface description, or if there + are no corresponding interfaces for a portion of the + TSF, the evaluator determines that that is + acceptable. + + + + + The evaluator shall examine the functional specification + to determine that it is presented using a semiformal + style. + + A semi-formal presentation is characterised by a + standardised format with a well-defined syntax that + reduces ambiguity that may occur in informal + presentations. Since the intent of the semi-formal + format is to enhance the reader's ability to understand + the presentation, use of certain structured presentation + methods (pseudo-code, flow charts, block diagrams) are + appropriate, though not required. + + For the purposes of this activity, the evaluator should + ensure that the interface descriptions are formatted in + a structured, consistent manner and use common + terminology. A semiformal presentation of the interfaces + also implies that the level of detail of the + presentation for the interfaces is largely consistent + across all TSFI. For the functional specification, it is + acceptable to refer to external specifications for + portions of the interface as long as those external + specifications are themselves semiformal. + + + + + The evaluator shall examine the functional specification + to determine that it states the purpose of each + TSFI. + + The purpose of a TSFI is a general statement summarising + the functionality provided by the interface. It is not + intended to be a complete statement of the actions and + results related to the interface, but rather a statement + to help the reader understand in general what the + interface is intended to be used for. The evaluator + should not only determine that the purpose exists, but + also that it accurately reflects the TSFI by taking into + account other information about the interface, such as + the description of actions and error messages. + + + + + The evaluator shall examine the functional specification + to determine that the method of use for each TSFI is + given. + + The method of use for a TSFI summarises how the + interface is manipulated in order to invoke the actions + and obtain the results associated with the TSFI. The + evaluator should be able to determine, from reading this + material in the functional specification, how to use + each interface. This does not necessarily mean that + there needs to be a separate method of use for each + TSFI, as it may be possible to describe in general how + kernel calls are invoked, for instance, and then + identify each interface using that general + style. Different types of interfaces will require + different method of use specifications. APIs, network + protocol interfaces, system configuration parameters, + and hardware bus interfaces all have very different + methods of use, and this should be taken into account by + the developer when developing the functional + specification, as well as by the evaluator evaluating + the functional specification. + + For administrative interfaces whose functionality is documented + as being inaccessible to untrusted users, the evaluator ensures + that the method of making the functions inaccessible is + described in the functional specification. It should be noted + that this inaccessibility needs to be tested by the developer in + their test suite. + + The evaluator should not only determine that the set of + method of use descriptions exist, but also that they + accurately cover each TSFI. + + The evaluator shall examine the functional specification to + determine the completeness of the TSFI + The evaluator shall use the design documentation to identify the possible types of + interfaces. The evaluator shall search the design documentation and the guidance + documentation for potential TSFI not contained in the developer's documentation, + thus indicating that the set of TSFI defined by the developer is incomplete. The + evaluator shall examine the arguments presented by the developer that the TSFI is + complete and check down to the lowest level of design or with the + implementation representation that no additional TSFI exist. + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely identifies all + parameters associated with every TSFI. + + The evaluator examines the functional specification to + ensure that all of the parameters are described for each + TSFI. Parameters are explicit inputs or outputs to an + interface that control the behaviour of that + interface. For examples, parameters are the arguments + supplied to an API; the various fields in packet for a + given network protocol; the individual key values in the + Windows Registry; the signals across a set of pins on a + chip; etc. + + In order to determine that all of the parameters are + present in the TSFI, the evaluator should examine the + rest of the interface description (actions, error + messages, etc.) to determine if the effects of the + parameter are accounted for in the description. The + evaluator should also check other evidence provided for + the evaluation (e.g., TOE design, security architecture + description, operational user guidance, implementation + representation) to see if behaviour or additional + parameters are described there but not in the functional + specification. + + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely and accurately describes + all parameters associated with every TSFI. + + Once all of the parameters have been identified, the + evaluator needs to ensure that they are accurately + described, and that the description of the parameters is + complete. A parameter description tells what the + parameter is in some meaningful way. For instance, the + interface foo(i) could be described as + having ``parameter i which is an integer''; this is not + an acceptable parameter description. A description such + as ``parameter i is an integer that indicates the number + of users currently logged in to the system''. is much + more acceptable. + + In order to determine that the description of the + parameters is complete, the evaluator should examine the + rest of the interface description (purpose, method of + use, actions, error messages, etc.) to determine if the + descriptions of the parameter(s) are accounted for in + the description. The evaluator should also check other + evidence provided (e.g., TOE design, architectural + design, operational user guidance, implementation + representation) to see if behaviour or additional + parameters are described there but not in the functional + specification. + + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely and accurately describes + all actions associated with every TSFI. + + The evaluator checks to ensure that all of the actions + are described. actions available through an interface + describe what the interface does (as opposed to the TOE + design, which describes how the actions are provided by + the TSF). + + actions of an interface describe functionality that can + be invoked through the interface, and can be categorised + as regular actions, and + SFR-related actions. Regular actions + are descriptions of what the interface does. The amount + of information provided for this description is + dependant on the complexity of the interface. The + SFR-related actions are those that are visible at any + external interface (for instance, audit activity caused + by the invocation of an interface (assuming audit + requirements are included in the ST) should be + described, even though the result of that action is + generally not visible through the invoked + interface). Depending on the parameters of an interface, + there may be many different actions able to be invoked + through the interface (for instance, an API might have + the first parameter be a ``subcommand'', and the + following parameters be specific to that subcommand. The + IOCTL API in some Unix systems is an example of such an + interface). + In order to determine that the description of the + actions of a TSFI is complete, the evaluator should + review the rest of the interface description (parameter + descriptions, error messages, etc.) to determine if the + actions described are accounted for. The evaluator + should also analyse other evidence provided for the + evaluation (e.g., TOE design, security architecture + description, operational user guidance, implementation + representation) to see if there is evidence of actions + that are described there but not in the functional + specification. + + + + + The evaluator shall examine the presentation of the TSFI + to determine that it completely and accurately describes + all errors messages resulting from an invocation of each + TSFI. + + Errors can take many forms, depending on the interface + being described. For an API, the interface itself may + return an error code; set a global error condition, or + set a certain parameter with an error code. For a + configuration file, an incorrectly configured parameter + may cause an error message to be written to a log + file. For a hardware PCI card, an error condition may + raise a signal on the bus, or trigger an exception + condition to the CPU. + + Errors (and the associated error messages) come about + through the invocation of an interface. The processing + that occurs in response to the interface invocation may + encounter error conditions, which trigger (through an + implementation-specific mechanism) an error message to + be generated. In some instances this may be a return + value from the interface itself; in other instances a + global value may be set and checked after the invocation + of an interface. It is likely that a TOE will have a + number of low-level error messages that may result from + fundamental resource conditions, such as ``disk full'' + or ``resource locked''. While these error messages may + map to a large number of TSFI, they could be used to + detect instances where detail from an interface + description has been omitted. For instance, a TSFI that + produces a ``disk full'' message, but has no obvious + description of why that TSFI should cause an access to + the disk in its description of actions, might cause the + evaluator to examine other evidence (, ) related + that TSFI to determine if the description is complete + and accurate. + + The evaluator determines that, for each TSFI, the exact + set of error messages that can be returned on invoking + that interface can be determined. The evaluator reviews + the evidence provided for the interface to determine if + the set of errors seems complete. They cross-check this + information with other evidence provided for the + evaluation (e.g., TOE design, security architecture + description, operational user guidance, implementation + representation) to ensure that there are no errors + steaming from processing mentioned that are not included + in the functional specification. + + + + + The evaluator shall examine the presentation of the TSFI to determine + that it completely and accurately describes the meaning of all + error messages resulting from an invocation of each TSFI. + + In order to determine accuracy, the evaluator must be + able to understand meaning of the error. For example, if + an interface returns a numeric code of 0, 1, or 2, the + evaluator would not be able to understand the error if + the functional specification only listed: ``possible + errors resulting from invocation of the + foo() interface are 0, 1, or + 2''. Instead the evaluator checks to ensure that the + errors are described such as: ``possible errors + resulting from invocation of the foo() + interface are 0 (processing successful), 1 (file not + found), or 2 (incorrect filename + specification)''. + + In order to determine that the description of the errors + due to invoking a TSFI is complete, the evaluator + examines the rest of the interface description + (parameter descriptions, actions, etc.) to determine if + potential error conditions that might be caused by using + such an interface are accounted for. The evaluator also + checks other evidence provided for the evaluation (e.g., + TOE design, security architecture description, + operational user guidance, implementation + representation) to see if error processing related to + the TSFI is described there but is not described in the + functional specification. + + + + + The evaluator shall examine the functional specification + to determine that it completely and accurately describes + all errors messages that do not result from an + invocation of any TSFI. + + This work unit complements work unit , which describes those + error messages that result from an invocation of the + TSFI. Taken together, these work units cover all error + messages that might be generated by the TSF. + + The evaluator assesses the completeness and accuracy of + the functional specification by comparing its contents + to instances of error message generation within the + implementation representation. Most of these error + messages will have already been covered by work unit + . + + The error messages related to this work unit are + typically those that are not expected to be generated, + but are constructed as a matter of good programming + practises. For example, a case statement that defines + actions resulting from each of a list of cases may end + with a final else statement to apply + to anything that might not be expected; this practise + ensures the TSF does not get into an undefined state. + However, it is not expected that the path of execution + would ever get to this else + statement; therefore, any error message generation + within this else statement would + never be generated. Although it would not get + generated, it must still be included in the functional + specification. + + + + + The evaluator shall examine the functional specification + to determine that it provides a rationale for each error + message contained in the TSF implementation yet does not + result from an invocation of a TSFI. + + The evaluator ensures that every error message found + under work unit + contains a rationale describing why it cannot be invoked + from the TSFI. + + As was described in the previous work unit, this + rationale might be as straightforward as the fact that + the error message in question is provided for + completeness of execution logic and that it is never + expected to be generated. The evaluator ensures that the + rationale for each such error message is logical. + + + + The evaluator shall check that the tracing links the + SFRs to the corresponding TSFIs. + + The tracing is provided by the developer to serve as a + guide to which SFRs are related to which TSFIs. This + tracing can be as simple as a table; it is used as input + to the evaluator for use in the following work units, in + which the evaluator verifies its completeness and + accuracy. + + + + The evaluator shall determine that the functional + specification is an accurate and complete instantiation of + the SFRs. + + + The evaluator shall examine the functional specification + to determine that it is a complete instantiation of the + SFRs. + + To ensure that all SFRs are covered by the functional + specification, as well as the test coverage analysis, + the evaluator may build upon the developer's tracing + (see a map between + the TOE security functional requirements and the TSFI. + Note that this map may have to be at a level of detail + below the component or even element level of the + requirements, because of operations (assignments, + refinements, selections) performed on the functional + requirement by the ST author. + + For example, the + component contains an element with assignments. If the + ST contained, for instance, ten rules in the assignment, and these ten + rules were covered by three different TSFI, it would be + inadequate for the evaluator to map to TSFI A, B, and C and claim they had + completed the work unit. Instead, the evaluator would + map (rule 1) to TSFI A; + (rule 2) to TSFI B; + etc. It might also be the case that the interface is a + wrapper interface (e.g., IOCTL), in which case the + mapping would need to be specific to certain set of + parameters for a given interface. + + The evaluator must recognise that for requirements that + have little or no manifestation at the TSF boundary + (e.g., ) it is not + expected that they completely map those requirements to + the TSFI. The analysis for those requirements will be + performed in the analysis for the TOE design () when included in the ST. It is + also important to note that since the parameters, + actions, and error messages associated with TSFIs must + be fully specified, the evaluator should be able to + determine if all aspects of an SFR appear to be + implemented at the interface level. + + + + The evaluator shall examine the functional specification + to determine that it is an accurate instantiation of the + SFRs. + + For each functional requirement in the ST that results + in effects visible at the TSF boundary, the information + in the associated TSFI for that requirement specifies + the required functionality described by the + requirement. For example, if the ST contains a + requirement for access control lists, and the only TSFI + that map to that requirement specify functionality for + Unix-style protection bits, then the functional + specification is not accurate with respect to the + requirements. + + The evaluator must recognise that for requirements that + have little or no manifestation at the TSF boundary + (e.g., ) it is not + expected that the evaluator completely map those + requirements to the TSFI. The analysis for those + requirements will be performed in the analysis for the + TOE design () when + included in the ST. + + + + + + + + + (Need Objectives text for FSP.6 methodology) + + + + The evaluation evidence for this sub-activity that is + required by the work-units is: + + + the ST; + + + the functional specification; + + + the TOE design. + + + + The evaluation evidence for this sub-activity that is used + if included in the ST for the TOE is: + + + the security architecture description; + + + the implementation representation; + + + the TSF internals description; + + + the formal security policy model; + + + the operational user guidance; + + + + + The developer shall provide a functional specification. + + + The developer shall provide a formal presentation of the + functional specification of the TSF. + + + The developer shall provide a tracing from the functional + specification to the SFRs. + + + The functional specification shall completely represent the + TSF. + + + The functional specification shall describe the TSFI using a + formal style. + + + The functional specification shall describe the purpose and + method of use for all TSFI. + + + The functional specification shall identify and describe all + parameters associated with each TSFI. + + + The functional specification shall describe all actions + associated with each TSFI. + + + The functional specification shall describe all direct error + messages that may result from an invocation of each TSFI. + + + The functional specification shall describe all error messages + contained in the TSF implementation representation. + + + The functional specification shall provide a rationale for + each error message contained in the TSF implementation that + is not otherwise described in the functional specification + justifying why it is not associated with a TSFI. + + + The formal presentation of the functional specification of + the TSF shall describe the TSFI using a formal style, + supported by informal, explanatory text where appropriate. + + + The tracing shall demonstrate that the SFRs trace to TSFIs + in the functional specification. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + The evaluator shall determine that the functional + specification is an accurate and complete instantiation of + the SFRs. + + + + + + + The function of the family + is for the developer to make available the implementation + representation (and, at higher levels, the implementation + itself) of the TOE in a form that can be analysed by the + evaluator. The implementation representation is used in + analysis activities for other families (analysing the TOE + design, for instance) to demonstrate that the TOE conforms + its design and to provide a basis for analysis in other + areas of the evaluation (e.g., the search for + vulnerabilities). The implementation representation is + expected to be in a form that captures the detailed internal + workings of the TSF. This may be software source code, + firmware source code, hardware diagrams and/or IC hardware + design language code or layout data. + + + + The implementation representation of the TOE is made + available so that it can be analysed by the evaluator to + demonstrate that the TOE conforms its design and to provide + a basis for analysis in other areas of the evaluation (e.g., + the search for vulnerabilities). The implementation + representation captures the detailed internal workings of + the TSF. This may be software source code, firmware source + code, hardware diagrams and/or chip specifications. + + + + The components in this family are levelled on the amount of + implementation that is mapped to the TOE design + description. + + + + Source code or hardware diagrams and/or IC hardware design + language code or layout data that are used to build the + actual hardware are examples of parts of an implementation + representation. It is important to note that while the + implementation representation must be made available to the + evaluator, this does not imply that the evaluator needs to + possess that representation. For instance, the developer may + require that the evaluator review the implementation + representation at a site of the developer's choosing. + + The entire implementation representation is made available + to ensure that analysis activities are not curtailed due to + lack of information. This does not, however, imply that all + of the representation is examined when the analysis + activities are being performed. This is likely impractical + in almost all cases, in addition to the fact that it most + likely will not result in a higher-assurance TOE + vs. targeted sampling of the implementation + representation. The implementation representation is made + available to allow analysis of other TOE design + decompositions (e.g., functional specification, TOE design), + and to gain confidence that the security functionality + described at a higher level in the design actually appear to + be implemented in the TOE. Conventions in some forms of the + implementation representation may make it difficult or + impossible to determine from just the implementation + representation itself what the actual result of the + compilation or run-time interpretation will be. For example, + compiler directives for C language compilers will cause the + compiler to exclude or include entire portions of the + code. For this reason, it is important that such ``extra'' + information or related tools (scripts, compilers, etc.) be + provided so that the implementation representation can be + accurately determined. + + The purpose of the mapping between the implementation + representation and the TOE design description is to aid the + evaluator's analysis. The internal workings of the TOE may + be better understood when the TOE design is analysed with + corresponding portions of the implementation representation. + The mapping serves as an index into the implementation + representation. At the lower component, only a subset of the + implementation representation is mapped to the TOE design + description. Because of the uncertainty of which portions of + the implementation representation will need such a mapping, + the developer may choose either to map the entire + implementation representation beforehand, or to wait to see + which portions of the implementation representation the + evaluator requires to be mapped. + + The implementation representation is manipulated by the + developer in a form that is suitable for transformation to + the actual implementation. For instance, the developer may + work with files containing source code, which is eventually + compiled to become part of the TSF. The developer makes + available the implementation representation in the form used + by the developer, so that the evaluator may use automated + techniques in the analysis. This also increases the + confidence that the implementation representation examined + is actually the one used in the production of the TSF (as + opposed to the case where it is supplied in an alternate + presentation format, such as a word processor document). It + should be noted that other forms of the implementation + representation may also be used by the developer; these + forms are supplied as well. The overall goal is to supply + the evaluator with the information that will maximise the + effectiveness of the evaluator's analysis efforts. + + Some forms of the implementation representation may require + additional information because they introduce significant + barriers to understanding and analysis. Examples include + ``shrouded'' source code or source code that has been + obfuscated in other ways such that it prevents understanding + and/or analysis. These forms of implementation + representation typically result from the TOE developer + taking a version of the implementation representation and + running a shrouding or obfuscation program on it. While the + shrouded representation is what is compiled and may be + closer to the implementation (in terms of structure) than + the original, un-shrouded representation, supplying such + obfuscated code may cause significantly more time to be + spent in analysis tasks involving the representation. When + such forms of representation are created, the components + require details on the shrouding tools/algorithms used so + that the un-shrouded representation can be supplied, and the + additional information can be used to gain confidence that + the shrouding process does not compromise any security + functionality. + + + + + + + The objective of this sub-activity is to determine that + the implementation representation made available by the + developer is suitable for use in other analysis + activities; suitability is judged by its + conformance to the requirements for this component. + + + + The entire implementation representation is made available + to ensure that analysis activities are not curtailed due + to lack of information. This does not, however, imply that + all of the representation is examined when the analysis + activities are being performed. This is likely impractical + in almost all cases, in addition to the fact that it most + likely will not result in a higher-assurance TOE + vs. targeted sampling of the implementation + representation. For this sub-activity, this is even + truer. It would not be productive for the evaluator to + spend large amounts of time verifying the requirements for + one portion of the implementation representation, and then + use a different portion of the implementation + representation in performing analysis for other work + units. Therefore, the evaluator is encouraged to select + the sample of the implementation representation from the + areas of the TOE that will be of most interest during the + analysis performed during work units from other families + (e.g. , and ). + + + + The evaluation evidence for this sub-activity is: + + + the implementation representation; + + + the documentation of the development tools, as + resulting from ; + + + TOE design description. + + + + + The developer shall make available the implementation + representation for the entire TSF. + + + The developer shall provide a mapping between the TOE design + description and the sample of the implementation + representation. + + + The implementation representation shall define the TSF to a + level of detail such that the TSF can be generated without + further design decisions. + + + The implementation representation shall be in the form used + by the development personnel. + + + The mapping between the TOE design description and the + sample of the implementation representation shall + demonstrate their correspondence. + + + The evaluator shall confirm that, for the selected sample of + the implementation representation, the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the implementation + representation defines the TSF to a level of detail such + that the TSF can be generated without further design + decisions. + + Source code or hardware diagrams and/or IC hardware + design language code or layout data that are used to + build the actual hardware are examples of parts of an + implementation representation. The evaluator samples the + implementation representation to gain confidence that it + is at the appropriate level and not, for instance, a + pseudo-code level which requires additional design + decisions to be made. The evaluator is encouraged to + perform a quick check when first looking at the + implementation representation to assure themselves that + the developer is on the right track. However, the + evaluator is also encourage to perform the bulk of this + check while working on other work units that call for + examining the implementation; this will ensure the + sample examined for this work unit is relevant. + + + + + The evaluator shall check that the implementation + representation is in the form used by development + personnel. + + The implementation representation is manipulated by the + developer in form that it suitable for transformation to + the actual implementation. For instance, the developer + may work with files containing source code, which is + eventually compiled to become part of the TSF. The + developer makes available the implementation + representation in the form they use, so that the + evaluator may use automated techniques in the + analysis. This also increases the confidence that the + implementation representation examined is actually the + one used in the production of the TSF (as opposed to the + case where it is supplied in an alternate presentation + format, such as a word processor document). It should be + noted that other forms of the implementation + representation may also be used by the developer; these + forms are supplied as well. The overall goal is to + supply the evaluator with the information that will + maximise the evaluator's analysis efforts. + + The evaluator samples the implementation representation + to gain confidence that it is the version that is usable + by the developer. The sample is such that the evaluator + has assurance that all areas of the implementation + representation are in conformance with the requirement; + however, a complete examination of the entire + implementation representation is unnecessary. + + Conventions in some forms of the implementation + representation may make it difficult or impossible to + determine from just the implementation representation + itself what the actual result of the compilation or + run-time interpretation will be. For example, compiler + directives for C language compilers will cause the + compiler to exclude or include entire portions of the + code. + + Some forms of the implementation representation may + require additional information because they introduce + significant barriers to understanding and + analysis. Examples include shrouded source code or + source code that has been obfuscated in other ways such + that it prevents understanding and/or analysis. These + forms of implementation representation typically result + from by taking a version of the implementation + representation that is used by the TOE developer and + running a shrouding or obfuscation program on it. While + the shrouded representation is what is compiled and may + be closer to the implementation (in terms of structure) + than the original, un-shrouded representation, supplying + such obfuscated code may cause significantly more time + to be spent in analysis tasks involving the + representation. When such forms of representation are + created, the components require details on the shrouding + tools/algorithms used so that the un-shrouded + representation can be supplied, and the additional + information can be used to gain confidence that the + shrouding process does not compromise any security + mechanisms. + + The evaluator samples the implementation representation + to gain confidence that all of the information needed to + interpret the implementation representation has been + supplied. Note that the tools are among those referenced + by components. The + evaluator is encouraged to perform a quick check when + first looking at the implementation representation to + assure themselves that the developer is on the right + track. However, the evaluator is also encouraged to + perform the bulk of this check while working on other + work units that call for examining the implementation; + this will ensure the sample examined for this work unit + is relevant. + + + + + The evaluator shall examine the mapping between the TOE + design description and the sample of the implementation + representation to determine that it is accurate. + + The evaluator augments the determination of existence + (specified in work unit ) by verifying the accuracy of a portion of + the implementation representation and the TOE design + description. For parts of the TOE design description + that are interesting, the evaluator would verify the + implementation representation accurately reflects the + description provided in the TOE design + description. + + For example, the TOE design description might identify a + login module that is used to identify and authenticate + users. If user authentication is sufficiently + significant, the evaluator would verify that the + corresponding code in fact implements that service as + described in the TOE design description. It might also + be worthwhile to verify that the code accepts the + parameters as described in the functional + specification. + + It is worth pointing out the developer must choose + whether to perform the mapping for the entire + implementation representation, thereby guaranteeing that + the chosen sample will be covered, or waiting for the + sample to be chosen before performing the mapping. The + first option is likely more work, but may be completed + before the evaluation begins. The second option is less + work, but will produce a suspension of evaluation + activity while the necessary evidence is being + produced. + + + + + + + + + + + The objective of this sub-activity is to determine that + the implementation representation made available by the + developer can be transformed into the implementation that + is used in the testing activities. + + + + The evaluation evidence for this sub-activity is: + + + the implementation representation; + + + the documentation of the development tools, as + resulting from ; + + + TOE design description. + + + + + The developer shall make available the implementation + representation for the entire TSF. + + + The developer shall provide a mapping between the TOE design + description and the entire implementation representation. + + + The implementation representation shall define the TSF to a + level of detail such that the TSF can be generated without + further design decisions. + + + The implementation representation shall be in the form used + by the development personnel. + + + The mapping between the TOE design description and the + entire implementation representation shall demonstrate their + correspondence. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + + + + This family addresses the assessment of the internal + structure of the TSF. A TSF whose internals are + well-structured is easier to implement and less likely to + contain flaws that could lead to vulnerabilities; it is also + easier to maintain without the introduction of flaws. + + + + The internal structure of the TSF can aid or hamper + understandability of the implementation representation. + Source code that conforms to coding standards, that exhibit + a minimum of interactions, and that is written in modules + each with a single purpose, is much easier to understand + than poorly-structured code with unnecessary or + loosely-defined interactions. + + + + The components in this family are levelled on the basis of + the amount of structure and minimisation of complexity + required. places + requirements for well-structured internals on only selected + parts of the TSF. This component is not included in an EAL + because this component is viewed for use in special + circumstances (e.g., the sponsor has a specific concern + regarding a cryptographic module, which is isolated from the + rest of the TSF) and would not be widely applicable. + + At the next level, the requirements for well-structured + internals are placed on the entire TSF. Finally, + minimisation of complexity is introduced in the highest + component. + + + + These requirements, when applied to the internal structure + of the TSF, typically result in improvements that aid both + the developer and the evaluator in understanding the TSF, + and also provide the basis for designing and evaluating test + suites. Further, improving understandability of the TSF + should assist the developer in simplifying its + maintainability. + + The requirements in this family are presented at a fairly + abstract level. The wide variety of TOEs makes it impossible + to codify anything more specific than ``well-structured'' or + ``minimum complexity''. Judgements on structure and + complexity are expected to be derived from the specific + technologies used in the TOE. For example, software is + likely to be considered well-structured if it exhibits the + characteristics cited in the software engineering + disciplines. The components within this family call for + identifying the standards for measuring the characteristic + of being well-structured and not overly-complex. + + + + + + + + The objective of this component is to provide a means for + requiring specific portions of the TSF to be + well-structured. The intent is that the entire TSF has + been designed and implemented using sound engineering + principles, but the analysis is performed upon only a + specific subset. + + + + This component requires the PP or ST author to fill in an + assignment with the subset of the TSF. This subset may be + identified in terms of the internals of the TSF at any + layer of abstraction. For example: + + the structural elements of the TSF as identified + in the TOE design (e.g. ``The developer shall design + and implement the audit subsystem + such that it has well-structured internals.'') + the implementation (e.g. ``The developer shall + design and implement the encrypt.c and + decrypt.c files such that it has + well-structured internals.'' or ``The developer shall + design and implement the 6227 IC chip + such that it has well-structured + internals.'') + + It is likely this would not be readily accomplished by + referencing the claimed SFRs (e.g. ``The developer shall + design and implement the portion of the TSF that + provide anonymity as defined in + such that it has well-structured + internals.'') because this does not indicate where to + focus the analysis. + + This component has limited value and would be suitable in cases + where potentially-malicious users/subjects have limited or + strictly controlled access to the TSFIs or where there is + another means of protection (e.g., domain separation) that + ensures the chosen subset of the TSF cannot be adversely + affected by the rest of the TSF (e.g., the cryptographic + functionality, which is isolated from the rest of the TSF, is + well-structured). + + + + The objective of this sub-activity is to determine whether + the defined subset of the TSF is designed and structured + such that the likelihood of flaws is reduced and that + maintenance can be more readily performed without the + introduction of flaws. + + + + The role of the internals description is to provide + evidence of the structure of the design and implementation + of the TSF. + + The structure of the design has two aspects: the + constituent parts of the TSF and the procedures used to + design the TSF. In cases where the TSF is designed in a + manner consistent with the design represented by the TOE + design (see ), the + assessment of the TSF design is obvious. In cases where + the design procedures (see ) + are being followed, the assessment of the TSF design + procedures is similarly obvious. + + In cases where the TSF is implemented using + procedure-based software, this structure is assessed on + the basis of its modularity; the + modules identified in the internals description are the + same as the modules identified in the TOE design (). A module consists of one or + more source code files that cannot be decomposed into + smaller compilable units. + + The use of the assignment in this component levies stricter + constraints on the subset of the TSF that is explicitly + identified in the assignment + than on the remainder of the TSF. + While the entire TSF is to be designed using good + engineering principles and result in a well-structured TSF, only + the specified subset is specifically analysed for this + characteristic. The evaluator determines that the developer's + application of coding standards result in a TSF that is + understandable. + + The primary goal of this component is to ensure the TSF + subset's implementation representation is understandable + to facilitate maintenance and analysis (of both the + developer and evaluator). + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the TOE design description; + + + the implementation representation (if is part of the claimed + assurance); + + + the TSF internals description and justification; + + + the documentation of the coding standards, as + resulting from . + + + + + The developer shall design and implement subset + of the TSF such that it has well-structured + internals. + + + The developer shall provide an internals description and + justification. + + + The justification shall explain the characteristics used to + judge the meaning of ``well-structured''. + + + The TSF internals description shall demonstrate that the + assigned subset of the TSF is well-structured. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + The evaluator shall examine the justification to + determine that it identifies the basis for determining + whether the TSF is well-structured. + + The evaluator verifies that the criteria for determining + the characteristic of being well-structured are clearly + defined in the justification. Acceptable criteria + typically originate from industry standards for the + technology discipline. For example, procedural software + that executes linearly is traditionally viewed as + well-structured if it adheres to software engineering + programming practises, such as those defined in the IEEE + Standard (IEEE Std 610.12-1990). For + example, it would identify the criteria for the + procedural software portions of the TSF subset: + + the process used for modular + decomposition + coding standards used in the development of the + implementation + a description of the maximum acceptable level of + intermodule coupling exhibited by the TSF + subset + a description of the minimum acceptable level of + cohesion exhibited the modules of the TSF + subset + + For other types of technologies used in the TOE - such as + non-procedural software (e.g. object-oriented programming), + widespread commodity hardware (e.g. PC microprocessors), and + special-purpose hardware (e.g. smart-card processors) - the + evaluator should seek guidance from the evaluation authority for + determining the adequacy of criteria for being + ``well-structured''. + + + + The evaluator shall check the TSF internals + description to determine that it identifies the Assigned + subset of the TSF. + + This subset may be identified in terms of the internals + of the TSF at any layer of abstraction. For example, it + may be in terms of the structural elements of the TSF as + identified in the TOE design (e.g. the audit subsystem), + or in terms of the implementation + (e.g. encrypt.c and + decrypt.c files, or the 6227 IC + chip). + + It is insufficient to identify this subset in terms of + the claimed SFRs (e.g. the portion of the TSF that + provide anonymity as defined in ) because this does not indicate where to + focus the analysis. + + + + The evaluator shall examine the TSF internals + description to determine that it demonstrates that the + assigned TSF subset is well-structured. + + The evaluator examines the internals description to + ensure that it provides a sound explanation of how the + TSF subset meets the criteria from + + For example, it would explain how the procedural + software portions of the TSF subset meets the following: + + that there is a one-to-one correspondence + between the modules identified in the TSF subset and + the modules described in the TOE design () + how the TSF design is a reflection of the + modular decomposition process + a justification for all instances where the + coding standards were not used or met + a justification for any coupling or cohesion + outside the acceptable bounds + + + + The evaluator shall perform an internals analysis on the + assigned subset of the TSF. + + + The evaluator shall determine that the TOE design for + the assigned TSF subset is well-structured. + + The evaluator examines a sample of the TOE design to + verify the accuracy of the justification. For example, a + sample of the TOE design is analysed to determine its + adherence to the design standards, etc. As with all + areas where the evaluator performs activities on a + subset the evaluator provides a justification of the + sample size and scope + + The description of the TOE's decomposition into + subsystems and modules will make the argument that the + TSF subset is well-structured self-evident. Verification + that the procedures for structuring the TSF (as examined + in ) are being followed + will make it self-evident that the TSF subset is + well-structured. + + + + The evaluator shall determine that the assigned TSF + subset is well-structured. + + If is not part of the + claimed assurance, then this work unit is not applicable + and is therefore considered to be satisfied. + + The evaluator examines a sample of the TSF subset to + verify the accuracy of the internals description. For + example, a sample of the procedural software portions of + the TSF subset is analysed to determine its cohesion and + coupling, its adherence to the coding standards, etc. As + with all areas where the evaluator performs activities + on a subset the evaluator provides a justification of + the sample size and scope. + + + + + + + + + + + The objective of this component is to provide a means for + requiring the TSF to be well-structured. The intent is + that the entire TSF has been designed and implemented + using sound engineering principles. + + + + Judgements on the adequacy of the structure are expected to + be derived from the specific technologies used in the TOE. + This component calls for identifying the standards for + measuring the characteristic of being + well-structured. + + + + The objective of this sub-activity is to determine whether + the TSF is designed and structured such that the + likelihood of flaws is reduced and that maintenance can be + more readily performed without the introduction of + flaws. + + + + The role of the internals description is to provide + evidence of the structure of the design and implementation + of the TSF. + + The structure of the design has two aspects: the + constituent parts of the TSF and the procedures used to + design the TSF. In cases where the TSF is designed in a + manner consistent with the design represented by the TOE + design (see ), the + assessment of the TSF design is obvious. In cases where + the design procedures (see ) + are being followed, the assessment of the TSF design + procedures is similarly obvious. + + In cases where the TSF is implemented using + procedure-based software, this structure is assessed on + the basis of its modularity; the + modules identified in the internals description are the + same as the modules identified in the TOE design (). A module consists of one or + more source code files that cannot be decomposed into + smaller compilable units. + + The primary goal of this component is to ensure the TSF's + implementation representation is understandable to + facilitate maintenance and analysis (of both the developer + and evaluator). + + + + The evaluation evidence for this sub-activity is: + + + the modular design description; + + + the implementation representation (if is part of the claimed + assurance)); + + + the TSF internals description; + + + the documentation of the coding standards, as + resulting from . + + + + + The developer shall design and implement the entire TSF such + that it has well-structured internals. + + + The developer shall provide an internals description and + justification. + + + The justification shall describe the characteristics used to + judge the meaning of ``well-structured''. + + + The TSF internals description shall demonstrate that the + entire TSF is well-structured. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + The evaluator shall examine the justification to + determine that it identifies the basis for determining + whether the TSF is well-structured. + + The evaluator verifies that the criteria for determining + the characteristic of being well-structured are clearly + defined in the justification. Acceptable criteria + typically originate from industry standards for the + technology discipline. For example, procedural software + that executes linearly is traditionally viewed as + well-structured if it adheres to software engineering + programming practises, such as those defined in the IEEE + Standard (IEEE Std 610.12-1990). For + example, it would identify the criteria for the + procedural software portions of the TSF: + + the process used for modular + decomposition + coding standards used in the development of the + implementation + a description of the maximum acceptable level of + intermodule coupling exhibited by the TSF + a description of the minimum acceptable level of + cohesion exhibited the modules of the + TSF + + For other types of technologies used in the TOE - such + as non-procedural software (e.g. object-oriented + programming), widespread commodity hardware (e.g. PC + microprocessors), and special-purpose hardware + (e.g. smart-card processors) - the evaluation authority + should be consulted for determining the adequacy of + criteria for being ``well-structured''. + + + + The evaluator shall examine the TSF internals + description to determine that it demonstrates that the + TSF is well-structured. + + The evaluator examines the internals description to + ensure that it provides a sound explanation of how the + TSF meets the criteria from + + For example, it would explain how the procedural + software portions of the TSF meet the following: + + that there is a one-to-one correspondence + between the modules identified in the TSF and the + modules described in the TOE design () + how the TSF design is a reflection of the + modular decomposition process + a justification for all instances where the + coding standards were not used or met + a justification for any coupling or cohesion + outside the acceptable bounds + + + + The evaluator shall perform an internals analysis on the + TSF. + + + The evaluator shall determine that the TOE design is + well-structured. + + The evaluator examines the TOE design of a sample of the + TSF to verify the accuracy of the justification. For + example, a sample of the TOE design is analysed to + determine its adherence to the design standards, etc. As + with all areas where the evaluator performs activities + on a subset the evaluator provides a justification of + the sample size and scope + + The description of the TOE's decomposition into + subsystems and modules will make the argument that the + TSF subset is well-structured self-evident. Verification + that the procedures for structuring the TSF (as examined + in ) are being followed + will make it self-evident that the TSF subset is + well-structured. + + + + The evaluator shall determine that the TSF is + well-structured. + + If is not part of the + claimed assurance, then this work unit is not applicable + and is therefore considered to be satisfied. + + The evaluator examines a sample of the TSF to verify the + accuracy of the internals description. For example, a + sample of the procedural software portions of the TSF is + analysed to determine its cohesion and coupling, its + adherence to the coding standards, etc. As with all + areas where the evaluator performs activities on a + subset the evaluator provides a justification of the + sample size and scope. + + + + + + + + + + + The objective of this component is to provide a means for + requiring the TSF to be well-structured and of minimal + complexity. The intent is that the entire TSF has been + designed and implemented using sound engineering + principles. + + + + Judgements on the adequacy of the structure and complexity + are expected to be derived from the specific technologies + used in the TOE. This component calls for identifying the + standards for measuring the structure and + complexity. + + + + The evaluation evidence for this sub-activity is: + + + the modular design description; + + + the implementation representation; + + + the TSF internals description; + + + the documentation of the coding standards, as + resulting from . + + + + + The developer shall design and implement the entire TSF such + that it has well-structured internals. + + + The developer shall provide an internals description and + justification. + + + The justification shall describe the characteristics used to + judge the meaning of ``well-structured'' and ``complex''. + + + The TSF internals description shall demonstrate that the + entire TSF is well-structured and is not overly complex. + + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + The evaluator shall perform an internals analysis on the + entire TSF. + + + + + + + It is the objective of this family to provide additional + assurance from the development of a formal security + policy model of the TSF, and establishing a + correspondence between the functional specification and this + security policy model. Preserving internal consistency the + security policy model is expected to formally establish the + security principles from its characteristics by means of a + mathematical proof. + + + + A formal security model precisely describes important + aspects of security and their relationship to the behaviour + of the TSF. Formalism helps to prove mathematically the + thoroughness of the security. + + + + This family contains only one component. + + + + Inadequacies in a TOE can result either from a failure in + understanding the security requirements or from a flawed + implementation of those security requirements. Defining the + security requirements adequately to ensure their + understanding may be problematic because the definition must + be sufficiently precise to prevent undesired results or + subtle flaws during implementation of the TOE. Throughout + the design, implementation, and review processes, the + modelled security requirements may be used as precise design + and implementation guidance, thereby providing increased + assurance that the modelled security requirements are + satisfied by the TOE. The precision of the model and + resulting guidance is significantly improved by casting the + model in a formal language and verifying the security + requirements by formal proof. + + The creation of a formal security policy model helps to + identify and eliminate ambiguous, inconsistent, + contradictory, or unenforceable security policy + elements. Once the TOE has been built, the formal model + serves the evaluation effort by contributing to the + evaluator's judgement of how well the developer has + understood the security functionality being implemented and + whether there are inconsistencies between the security + requirements and the TOE design. The confidence in the model + is accompanied by a proof that it contains no + inconsistencies. + + A formal security model is a precise formal presentation of + the important aspects of security and their relationship to + the behaviour of the TOE; it identifies the set of rules and + practises that regulates how the TSF manages, protects, and + otherwise controls the system resources. The model includes + the set of restrictions and properties that specify how + information and computing resources are prevented from being + used to violate the SFRs, accompanied by a persuasive set of + engineering arguments showing that these restrictions and + properties play a key role in the enforcement of the SFRs. + It consists both of the formalisms that express the security + functionality, as well as ancillary text to explain the + model and to provide it with context. The security behaviour + of the TSF is modelled both in terms of external behaviour + (i.e. how the TSF interacts with the rest of the TOE and + with its operational environment), as well as its internal + behaviour. + + The Security Policy Model of the TOE is informally + abstracted from its realisation by considering the proposed + security requirements of the ST. The informal abstraction is + taken to be successful if the TOE's principles (also termed + ``invariants'') turn out to be enforced by its + characteristics. The purpose of formal methods lies within + the enhancement of the rigour of enforcement. Informal + arguments are always prone to fallacies; especially if + relationships among subjects, objects and operations get + more and more involved. In order to minimise the risk of + insecure state arrivals the rules and characteristics of the + security policy model are mapped to respective properties + and features within some formal system, whose rigour and + strength can afterwards be used to obtain the security + properties by means of theorems and formal proof. + + While the term ``formal security policy model'' is used in + academic circles, the CC's approach has no fixed definition + of ``security''; it would equate to whatever SFRs are being + claimed. Therefore, the formal security policy model is + merely a formal representation of the set of SFRs being + claimed. + + The term security policy has + traditionally been associated with only access control + policies, whether label-based (mandatory access control) or + user-based (discretionary access control). However, a + security policy is not limited to access control; there are + also audit policies, identification policies, authentication + policies, encryption policies, management policies, and any + other security policies that are enforced by the TOE, as + described in the PP/ST. contains an assignment for identifying these + policies that are formally modelled. + + + + + + The objectives of this sub-activity are to determine + whether the formal TOE security policy model clearly and + consistently describes the rules of operation, states, + transition, invariants, and other security properties of + the claimed SFRs and whether this description corresponds + with the description of the security functionality in the + functional specification. + + + + This activity applies to cases where the developer has + formally modelled all security policies of the TOE that + are capable of being modelled formally. + + A formal TOE security policy model is a representation of + the rules (synonymously termed ``principles'') and + characteristics of security policies in mathematical + terms. Their formal counterparts are called security + properties and security features, respectively. The + representation includes but is not limited to algebraic + specifications, finite state machines and logic formalisms + strong enough to formally infer the properties from the + features. The formal security policy model is accompanied + by an informal interpretation explaining how the rules and + characteristics are mapped to the respective properties + and features. + + It is recognised that not all policies (see work unit + ) can be formally + modelled for all TOEs. This is because either the state of + the art is insufficient to formally model a given policy, + or because the nature of the TOE renders impossible the + modelling of policies that would otherwise be possible to + model. If none of the SFRs can be formally modelled, this + component cannot be met. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the functional specification; + + + the TOE security policy model; + + + the operational user guidance; + + + + + The developer shall provide a formal security policy model for + the list of policies that are formally + modelled. + + For each policy covered by the formal security policy model, the + model shall identify the relevant portions of the statement of + SFRs that make up that policy. + + + The developer shall provide a formal proof of correspondence + between the model and any formal functional specification. + + + The developer shall provide a demonstration of + correspondence between the model and the functional + specification. + + + The model shall be in a formal style, supported by + explanatory text as required, and identify the security + policies of the TSF that are modelled. + + + For all policies that are modelled, the model shall define + security for the TOE and provide a formal proof that the TOE + cannot reach a state that is not secure. + + + The correspondence between the model and the functional + specification shall be at the correct level of formality. + + + The correspondence shall show that the functional + specification is consistent and complete with respect to the + model. + + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the TOE security policy + model to determine that it is written in a formal + style. + + The evaluator identifies the formal framework upon which + the TOE security policy model is based and ensures that + it is founded on well established mathematical concepts, + and identifies the security properties and features + addressed in the application notes and ensures the + formalisation of at least one security policy. If no + policy is formally modelled, this component cannot be + successfully claimed. + + For additional guidance on formal methods refer to . + + + + + The evaluator shall examine the TOE security policy + model to determine that it contains all necessary + informal explanatory text. + + Supporting narrative descriptions are necessary for all + parts of the model (for example, to make clear the + meaning of any formal notation and how they are used) + including the security properties and features. + + + + + The evaluator shall examine the TOE security policy + model to determine that it contains all policies that + can be formally modelled. + + It is recognised that not all policies can be formally + modelled for all TOEs. This is because either the state + of the art is insufficient to formally model a given + policy, or because the nature of the TOE renders + impossible the modelling of policies that would + otherwise be possible to model. + + While access control, information flow control, and data + integrity policies have all been formally modelled + successfully, the possibility of modelling other + policies is based on a case by case decision. Abstention + from formally modelling security relevant policies + requires argumentation and rests the burden of proof + entirely on the developer's side. + + For any security policy where formal models are not + possible, the policy must be identified in the + assignment of . + + + + + The evaluator shall examine the model to determine that + the security behaviour of the TOE is clearly + articulated. + + The security policy model's properties describe the + TOE's behaviour in enforcing the principles of the + policy. For example, a policy that is modelled on the + basis of state transitions would include principles of + its states, identify its initial state, and define what + it means to be a secure state. + + The security policy model's features describe the + attributes and conditions of the TOE that come into + consideration when enforcing its policy's + characteristics. For example, a policy that is modelled + on the basis of state transitions would describe the + necessary conditions to transform the TOE from one state + to the next. + + An informal interpretation of all formal concepts + (including attributes, predicates and variables, if + available) must also be provided in order to make clear + their intended meaning. + + + + + The evaluator shall examine the correspondence between + the security policy model and the formal functional + specification to determine that it is presented in a + formal style. + + If no part of the functional specification is formal, + this work unit is not applicable and is therefore + considered to be satisfied. The corresponding work will + be performed under work unit . + + For any part of the functional specification that is + formally presented, the correspondence between that part + of the functional specification and the security policy + model must be formal. Analysis of the content is + performed as part of work units through . + + For guidance on formal methods refer to . + + + + + The evaluator shall examine the correspondence between + the security policy model and the semiformal functional + specification to determine that it is presented in a + semiformal style. + + If the entire functional specification is formal, this + work unit is not applicable and is therefore considered + to be satisfied. The corresponding work will be + performed under work unit . + + For formally-modelled policies whose corresponding + description in the functional specification is not + formally presented, the correspondence between the model + and the functional specification must be a semiformal + demonstration. Analysis of the content is performed as + part of work units + through . + + If a security policy model exists, either this work unit + or the previous work unit (or both) will be + applicable. + + + + + The evaluator shall examine the TOE security policy + model rationale to determine that it formally proves the + correspondence between the security properties and the + security features. + + The proof shall show that the security features enforce + the security properties. To determine the enforcement, + the evaluator considers the security properties and the + security features and verifies that the arguments used + in the proof are valid. The proof of correspondence + between the security properties and the security + features shall be formal. + + + + + The evaluator shall examine the TOE security policy + model rationale to determine that it proves the internal + consistency of the TOE security policy model. + + The proof shall show the absence of contradictions + within the TOE security policy model. In determining the + absence of contradictions, the evaluator verifies that + the arguments used in the proof are valid. + + Since the TOE security policy model is formal, the proof + of its internal consistency shall be formal. It is + recognised that a complete formal proof of the internal + consistency of the TOE security policy model usually is + not possible due to the fundamental nature of formal + frameworks. Generally, it is sufficient to generate + evidence using formal proofs based on the specific TOE + security policy model that prove the internal + consistency by means of a combination with generic + arguments of the formal framework. + + + + + The evaluator shall examine the TOE security policy + model rationale to determine that the behaviour modelled + is consistent with respect to policies described by the + security policies (as articulated by the functional + requirements in the ST). + + The examination considers the informal relationships of + the model. Hence the meaning of consistency reflects + the conventional understanding in contrast to the + internal consistency concept of the previous work + unit. + + In determining consistency, the evaluator verifies that + the rationale shows that each description of properties + and features in the security policy model accurately + reflects the intent of the security policies. For + example, if a policy stated that access control was + necessary to the granularity of a single individual, + then a security policy model describing the security + behaviour of a TOE in the context of controlling groups + of users would not be consistent. Likewise, if the + policy stated that access control for groups of users + was necessary, then a security policy model describing + the security behaviour of a TOE in the context of + controlling individual users would also not be + consistent. + + The evaluator also examines whether the security + policies are reflected within their formal counterparts + of the security policy model. + + + + + The evaluator shall examine the TOE security policy + model rationale to determine that the behaviour modelled + is complete with respect to the policies described by + the security policies (i.e. as articulated by the + functional requirements in the ST). + + In determining completeness of this rationale, the + evaluator considers the properties and features of the + security policy model and maps those properties and + features to explicit policy statements (i.e. functional + requirements). The rationale should show that all + policies that are required to be modelled have an + associated property or feature description in the TOE + security policy model. + + Abstention from formally modelling policy statements + always calls for justification on the developer's side + (also confer the application notes above). + + + + + The evaluator shall examine the demonstration of + correspondence to determine that all Assigned policies + are mapped to functions within the functional + specification. + + If all policies are included within the security policy + model (i.e. they are all formally modelled) and the + assignment in is + therefore empty, this work unit is not applicable and is + therefore considered to be satisfied. + + The evaluator verifies that the correspondence + demonstrates that the descriptions of the SFR-related + functions in the functional specification correspond to + the SFRs. This may be done as part of the work units addressing + correspondence to the SFRs. However, if the developer + provides a well-structured semiformal or informal + security policy model to better articulate the notions + of security enforced by the TOE, the evaluator will + verify that such a model is consistent with the + SFRs. + + + + + + + + The design description of a TOE provides both context for a + description of the TSF, and a thorough description of the + TSF. As assurance needs increase, the level of detail + provided in the description also increases. As the size and + complexity of the TSF increase, multiple levels of + decomposition are appropriate. The design requirements are + intended to provide information (commensurate with the given + assurance level) so that a determination can be made that + the security functional requirements are realised. + + + + The design description provides a further-refined + description of the TSF from that presented in the functional + specification. The functional specification provides a + description of what the TSF does at its + interface; the design description provides more insight into + the TSF by describing how the TSF works in + order to perform the functions supporting the SFRs. At lower + assurance levels, complete details relating to all portions + of the TSF are not required. As the desired assurance + increases, more detail is made available so that analysis + can be performed that supports the assurance claims being + made. + + + + The components in this family are levelled on the basis of + the amount of information that is required to be presented + with respect to the TSF, and on the degree of formalism + required of the design description. + + + + The goal of design documentation is to provide sufficient + information to determine the TSF boundary, and to describe + how the TSF implements the Security + Functional Requirements. The amount and structure of the + design documentation will depend on the complexity of the + TOE and the number of SFRs; in general, a very complex TOE + with a large number of SFRs will require more design + documentation than a very simple TOE implementing only a few + SFRs. Very complex TOEs will benefit (in terms of the + assurance provided) from the production of differing levels + of decomposition in describing the design, while very simple + TOEs do not require both high-level and low-level + descriptions of its implementation. + + This family uses two levels of decomposition: the + subsystem and the module. + A module is the most specific description of functionality: + it is a description of the implementation. A developer + should be able to implement the part of the TOE described by + the module with no further design decisions. A subsystem is + a description of the design of the TOE; it helps to provide + a high-level description of what a portion of the TOE is + doing and how. As such, a subsystem may be further divided + into lower-level subsystems, or into modules. Very complex + TOEs might require several levels of subsystems in order to + adequately convey a useful description of how the TOE works. + Very simple TOEs, in contrast, might not require a subsystem + level of description; the module might clearly describe how + the TOE works. + + The general approach adopted for design documentation is + that, as the level of assurance increases, the emphasis of + description shifts from the general (subsystem level) to + more (module level) detail. In cases where a module-level + of abstraction is appropriate because the TOE is simple + enough to be described at the module level, yet the level of + assurance calls for a subsystem level of description, the + module-level description alone will suffice. For complex + TOEs, however, this is not the case: an enormous amount of + (module-level) detail would be incomprehensible without an + accompanying subsystem level of description. + + This approach follows the general paradigm that providing + additional detail about the implementation of the TSF will + result in greater assurance that the SFRs are implemented + correctly, and provide information that can be used to + demonstrate this in testing (). + + In the requirements for this family, the term + interface is used as the means of + communication (between two subsystems or modules). It + describes how the communication is invoked; this is similar + to the details of TSFI (see ). The term interaction is + used to identify the purpose for communication; it + identifies why two subsystems or modules are + communicating. + + + The requirements define collections of details about + subsystems and modules to be provided: + + The subsystems and modules are + identified with a simple list of what + they are. + + Subsystems and modules may be categorised + (either implicitly or explicitly) as ``SFR-enforcing'', + ``SFR-supporting'', or ``SFR-non-interfering''; these terms are + used the same as they are used in . + + A subsystem's behaviour is what it does. The + behaviour may also be categorised as SFR-enforcing, + SFR-supporting, or SFR-non-interfering. The behaviour of the + subsystem is never categorised as more SFR-relevant than the + category of the subsystem itself. For example, an SFR-enforcing + subsystem can have SFR-enforcing behaviour as well as + SFR-supporting or SFR-non-interfering behaviour. + A behaviour summary of a + subsystem is an overview of the actions it performs + (e.g. ``The TCP subsystem assembles IP datagrams into + reliable byte streams''). + A behaviour description of a + subsystem is an explanation of everything it + does. This description should be at a level of detail + that one can readily determine whether the behaviour + has any relevance to the enforcement of the + SFRs. + + A description of interactions among or between + subsystems or modules identifies the reason that subsystems or + modules communicate, and characterises the information that is + passed. It need not define the information to the same level of + detail as an interface specification. For example, it would be + sufficient to say ``subsystem X requests a block of memory from + the memory manager, which responds with the location of the + allocated memory. + A description of interfaces provides the + details of how the interactions among modules are achieved. + Rather than describing the reason the modules are communicating + or the purpose of their communication (that is, the description + of interactions), the description of interfaces describes the + details of how that communication is accomplished, in terms of + the structure and contents of the messages, semaphores, internal + process communications, etc. + + + The purpose describes how a module provides + their functionality. It provides sufficient detail that no + further design decisions are needed. The correspondence between + the implementation representation that implements the module, + and the purpose of the module should be readily apparent. + A module is otherwise described + in terms of whatever is identified in the + element. Subsystems and modules, and + ``SFR-enforcing'', etc. are all further explained in + greater detail in . + + + + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the functional specification; + + + security architecture description; + + + the TOE design. + + + + + The developer shall provide the design of the TOE. + + + The developer shall provide a mapping from the TSFI of the + functional specification to the lowest level of + decomposition available in the TOE design. + + The design shall describe the structure of the TOE in terms + of subsystems. + + + The design shall identify all subsystems of the TSF. + + + The design shall describe the behaviour of each + SFR-supporting or SFR-non-interfering TSF subsystem in + sufficient detail to determine that it is not SFR-enforcing. + + + The design shall summarise the SFR-enforcing behaviour of + the SFR-enforcing subsystems. + + + The design shall provide a description of the interactions + among SFR-enforcing subsystems of the TSF, and between the + SFR-enforcing subsystems of the TSF and other subsystems of + the TSF. + + + The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the TOE design to determine + that the structure of the entire TOE is described in + terms of subsystems. + + The evaluator ensures that all of the subsystems of the + TOE are identified. This description of the TOE will be + used as input to work unit , where the parts of the TOE that make up + the TSF are identified. That is, this requirement is on + the entire TOE rather than on only the TSF. + + The TOE (and TSF) may be described in multiple layers of + abstraction (i.e. subsystems and modules) Depending upon + the complexity of the TOE, its design may be described + in terms of subsystems and modules, as described in CC + Part 3 . At this + level of assurance, the decomposition only need be at + the ``subsystem'' level. + + In performing this activity, the evaluator examines + other evidence presented for the TOE (e.g., ST, operator + user guidance) to determine that the description of the + TOE in such evidence is consistent with the description + contained in the TOE design. + + + + + The evaluator shall examine the TOE design to determine + that all subsystems of the TSF are identified. + + In work unit all of + the subsystems of the TOE were identified, and a + determination made that the non-TSF subsystems were + correctly characterised. Building on that work, the + subsystems that were not characterised as non-TSF + subsystems should be precisely identified. The evaluator + determines that, of the hardware and software installed + and configured according to the guidance, each subsystem has been + accounted for as either one that is part of the TSF, or + one that is not. + + + + + The evaluator shall examine the TOE design to determine that + each SFR-supporting or SFR-non-interfering subsystem of the TSF + is described such that the evaluator can determine that the + subsystem is SFR-supporting or SFR-non-interfering. + + SFR-supporting and SFR-non-interfering subsystems do not need to + be described in detail as to how they function in the system. + However, the evaluator makes a determination, based on the + evidence provided by the developer, that the subsystems that do + not have high-level descriptions are SFR-supporting or + SFR-non-interfering. Note that if the developer provides a + uniform level of detailed documentation then this work unit will + be largely satisfied, since the point of categorising the + subsystems is to allow the developer to provide less information + for SFR-supporting and SFR-non-interfering subsystems than for + SFR-enforcing subsystems. + + An SFR-supporting subsystem is one that is depended on + by an SFR-enforcing subsystem in order to implement an + SFR, but does not play as direct a role as an + SFR-enforcing subsystem. An SFR-non-interfering + subsystem is one that is not depended upon, in either a + supporting or enforcing role, to implement an + SFR. + + + + + The evaluator shall examine the TOE design to determine + that it provides a complete, accurate, and high-level + description of the SFR-enforcing behaviour of the + SFR-enforcing subsystems. + + The developer may designate subsystems as SFR-enforcing, + SFR-supporting, and SFR non-interfering, but these + ``tags'' are used only to describe the amount and type + of information the developer must provide, and can be + used to limit the amount of information the developer + has to develop if their engineering process does not + produce the documentation required. Whether the + subsystems have been categorised by the developer or + not, it is the + evaluator's responsibility to determine that the + subsystems have the appropriate information for their + role (SFR-enforcing, etc.) in the TOE, and to obtain the + appropriate information from the developer should the + developer fail to provide the required information for a + particular subsystem. + + SFR-enforcing behaviour refers to how a + subsystem provides the functionality that implements an + SFR. A high-level description need not refer to + specific data structures (although it may), but instead + talks about more general data flow, message flow, and + control relationships within a subsystem. The goal of + these descriptions is to give the evaluator enough + information to understand how the + SFR-enforcing behaviour is achieved. Note that the + evaluator should find unacceptable asserts of + SFR-enforcement in the TOE design documentation for this + work unit. It should be noted that it is the + evaluator's determination with respect to what + ``high-level'' means for a particular TOE, and the + evaluator obtains enough information from the developer + to make a sound verdict for this work unit. + + To determine completeness and accuracy, the evaluator + examines other information available (e.g., functional + specification, security architecture description, + implementation representation). Descriptions of + functionality in these documents should be consistent + with what is provided for evidence for this work + unit + + + + + The evaluator shall examine the TOE design to determine + that interactions between the subsystems of the TSF are + described. + + The goal of describing the interactions between the + SFR-enforcing subsystems and other subsystems is to help provide + the reader a better understanding of how the TSF performs it + functions. These interactions do not need to be characterised at + the implementation level (e.g., parameters passed from one + routine in a subsystem to a routine in a different subsystem; + global variables; hardware signals (e.g., interrupts) from a + hardware subsystem to an interrupt-handling subsystem), but the + data elements identified for a particular subsystem that are + going to be used by another subsystem need to be covered in this + discussion. Any control relationships between subsystems (e.g., + a subsystem responsible for configuring a rule base for a + firewall system and the subsystem that actually implements these + rules) should also be described. + + The evaluators need to use their own judgement in assessing the + completeness of the description. If the reason for an + interaction is unclear, or if there are SFR-related interactions + (discovered, for instance, in examining the descriptions of + subsystem behaviour) that do not appear to be described, the + evaluator ensures that this information is provided by the + developer. However, if the evaluator can determine that + interactions among a particular set of subsystems, while + incompletely described by the developer, will not aid in + understanding the overall functionality nor security + functionality provided by the TSF, then the evaluator may choose + to consider the description sufficient, and not pursue + completeness for its own sake. + + + + + The evaluator shall examine the TOE design to determine + that it contains a complete and accurate mapping from + the TSFI described in the functional specification to + the subsystems of the TSF described in the TOE + design. + + The subsystems described in the TOE design provide a + description of how the TSF works at a detailed level for + SFR-enforcing portions of the TSF, and at a higher level + for other portions of the TSF. The TSFI provide a + description of how the implementation is exercised. The + evidence from the developer identifies the subsystem + that is initially involved when an operation is + requested at the TSFI, and identify the various + subsystems that are primarily responsible for + implementing the functionality. Note that a complete + ``call tree'' for each TSFI is not required for this + work unit. + + The evaluator assesses the completeness of the mapping + by ensuring that all of the TSFI map to at least one + subsystem. The verification of accuracy is more + complex. + + The first aspect of accuracy is that each TSFI is mapped + to a subsystem at the TSF boundary. This determination + can be made by reviewing the subsystem description and + interactions, and from this information determining its + place in the architecture. The next aspect of accuracy + is that the mapping makes sense. For instance, mapping a + TSFI dealing with access control to a subsystem that + checks passwords is not accurate. The evaluator should + again use judgement in making this determination. The + goal is that this information aids the evaluator in + understanding the system and implementation of the SFRs, + and ways in which entities at the TSF boundary can + interact with the TSF. The bulk of the assessment of + whether the SFRs are described accurately by the + subsystems is performed in other work units. + + + + The evaluator shall determine that the design is an accurate + and complete instantiation of all security functional + requirements. + + + The evaluator shall examine the TOE security functional + requirements and the TOE design, to determine that all + ST security functional requirements are covered by the + TOE design. + + The evaluator may construct a map between the TOE security + functional requirements and the TOE design. This map will + likely be from a functional requirement to a set of + subsystems. Note that this map may have to be at a level of + detail below the component or even element level of the + requirements, because of operations (assignments, refinements, + selections) performed on the functional requirement by the ST + author. + + For example, the + component contains an element with assignments. If the + ST contained, for instance, ten rules in the assignment, and these ten + rules were implemented in specific places within fifteen + modules, it would be inadequate for the evaluator to map + to one subsystem and + claim the work unit had been completed. Instead, the + evaluator would map + (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A, + behaviours x, p, and q; etc. + + + + The evaluator shall examine the TOE design to determine + that it is an accurate instantiation of all security + functional requirements. + + The evaluator ensures that each security requirement + listed in the TOE security functional requirements + subclause of the ST has a corresponding design description + in the TOE design that accurately details how the TSF + meets that requirement. This requires that the evaluator + identify a collection of subsystems that are responsible + for implementing a given functional requirement, and + then examine those subsystems to understand how the + requirement is implemented. Finally, the evaluator would + assess whether the requirement was accurately + implemented. + + As an example, if the ST requirements specified a + role-based access control mechanism, the evaluator would + first identify the subsystems that contribute to this + mechanism's implementation. This could be done by + in-depth knowledge or understanding of the TOE design or + by work done in the previous work unit. Note that this + trace is only to identify the subsystems, and is not the + complete analysis. + + The next step would be to understand what mechanism the + subsystems implemented. For instance, if the design + described an implementation of access control based on + UNIX-style protection bits, the design would not be an + accurate instantiation of those access control + requirements present in the ST example used above. If + the evaluator could not determine that the mechanism was + accurately implemented because of a lack of detail, the + evaluator would have to assess whether all of the + SFR-enforcing subsystems have been identified, or if + adequate detail had been provided for those + subsystems. + + + + + + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the functional specification; + + + security architecture description; + + + the TOE design. + + + + + The developer shall provide the design of the TOE. + + + The developer shall provide a mapping from the TSFI of the + functional specification to the lowest level of + decomposition available in the TOE design. + + + The design shall describe the structure of the TOE in terms + of subsystems. + + + The design shall identify all subsystems of the TSF. + + + The design shall describe the behaviour of each SFR + non-interfering subsystem of the TSF in detail sufficient to + determine that it is SFR non-interfering. + + + The design shall describe the SFR-enforcing behaviour of the + SFR-enforcing subsystems. + + + The design shall summarise the SFR-supporting and + SFR-non-interfering behaviour of the SFR-enforcing subsystems. + + + The design shall summarise the behaviour of the + SFR-supporting subsystems. + + + The design shall provide a description of the interactions + among all subsystems of the TSF. + + + The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the TOE design to determine + that the structure of the entire TOE is described in + terms of subsystems. + + The evaluator ensures that all of the subsystems of the + TOE are identified. This description of the TOE will be + used as input to work unit , where the parts of the TOE that make up + the TSF are identified. That is, this requirement is on + the entire TOE rather than on only the TSF. + + The TOE (and TSF) may be described in multiple layers of + abstraction (i.e. subsystems and modules) Depending upon + the complexity of the TOE, its design may be described + in terms of subsystems and modules, as described in CC + Part 3 . At this + level of assurance, the decomposition only need be at + the ``subsystem'' level. + + In performing this activity, the evaluator examines + other evidence presented for the TOE (e.g., ST, operator + user guidance) to determine that the description of the + TOE in such evidence is consistent with the description + contained in the TOE design. + + + + + The evaluator shall examine the TOE design to determine + that all subsystems of the TSF are identified. + + In work unit all of + the subsystems of the TOE were identified, and a + determination made that the non-TSF subsystems were + correctly characterised. Building on that work, the + subsystems that were not characterised as non-TSF + subsystems should be precisely identified. The evaluator + determines that, of the hardware and software installed + and configured according to the guidance, each subsystem has been + accounted for as either one that is part of the TSF, or + one that is not. + + + + + The evaluator shall examine the TOE design to determine + that each SFR-non-interfering subsystem of the TSF is + described such that the evaluator can determine that the + subsystem is SFR-non-interfering. + + SFR-non-interfering subsystems do not need to be + described in detail as to how they function in the + system. However, the evaluator makes a determination, + based on the evidence provided by the developer, that + the subsystems that do not have detailed descriptions + are SFR-non-interfering. Note that if the developer + provides a uniform level of detailed documentation then + this work unit will be largely satisfied, since the + point of categorising the subsystems is to allow the + developer to provide less information for + SFR-non-interfering subsystems than for SFR-enforcing + and SFR-supporting subsystems. + + An SFR-non-interfering subsystem is one on which the + SFR-enforcing and SFR-supporting subsystems have no + dependence; that is, they play no role in implementing + SFR functionality. + + + + + The evaluator shall examine the TOE design to determine + that it provides a complete, accurate, and detailed + description of the SFR-enforcing behaviour of the + SFR-enforcing subsystems. + + The developer may designate subsystems as SFR-enforcing, + SFR-supporting, and SFR non-interfering, but these + ``tags'' are used only to describe the amount and type + of information the developer must provide, and can be + used to limit the amount of information the developer + has to develop if their engineering process does not + produce the documentation required. Whether the + subsystems have been categorised by the developer or + not, it is the + evaluator's responsibility to determine that the + subsystems have the appropriate information for their + role (SFR-enforcing, etc.) in the TOE, and to obtain the + appropriate information from the developer should the + developer fail to provide the required information for a + particular subsystem. + + SFR-enforcing behaviour refers to how a + subsystem provides the functionality that implements an + SFR. While not at the level of an algorithmic + description, a detailed description of behaviour + typically discusses how the functionality is provided in + terms of what key data and data structures are, what + control relationships exist within a subsystem, and how + these elements work together to provide the + SFR-enforcing behaviour. Such a description also + references SFR-supporting behaviour, which the evaluator + should consider in performing subsequent work + units. + + To determine completeness and accuracy, the evaluator + examines other information available (e.g., functional + specification, security architecture description). Descriptions of + functionality in these documents should be consistent + with what is provided for evidence for this work unit. + + + + + The evaluator shall examine the TOE design to determine that it + provides a complete and accurate high-level description of the + SFR-supporting and SFR-non-interfering behaviour of the + SFR-enforcing subsystems. + + The developer may designate subsystems as SFR-enforcing, + SFR-supporting, and SFR non-interfering, but these + ``tags'' are used only to describe the amount and type + of information the developer must provide, and can be + used to limit the amount of information the developer + has to develop if their engineering process does not + produce the documentation required. Whether the + subsystems have been categorised by the developer or + not, it is the + evaluator's responsibility to determine that the + subsystems have the appropriate information for their + role (SFR-enforcing, etc.) in the TOE, and to obtain the + appropriate information from the developer should the + developer fail to provide the required information for a + particular subsystem. + + In contrast to the previous work unit, this work unit calls for + the evaluator to assess the information provided for + SFR-enforcing subsystems that is SFR-supporting or + SFR-non-interfering. The goal of this assessment is two-fold. + First, it should provide the evaluator greater understanding of + the way each subsystem works. Second, the evaluator determines + that all SFR-enforcing behaviour exhibited by a subsystem has + been described. Unlike the previous work unit, the information + provided for the SFR-supporting or SFR-non-interfering behaviour + does not have to be as detailed as that provided by the + SFR-enforcing behaviour. For example, data structures or data + items that do not pertain to SFR-enforcing functionality will + likely not need to be described in detail, if at all. It is the + evaluator's determination, however, with respect to what + ``high-level'' means for a particular TOE, and the evaluator + obtains enough information from the developer (even if it turns + out to be equivalent to information provided for the parts of + the subsystem that are SFR-enforcing) to make a sound verdict + for this work unit. + + The evaluator is cautioned, however, that ``perfect'' + assurance is not a goal nor required by this work unit, + so judgement will have to be exercised in determine the + amount and composition of the evidence required to make + a verdict on this work unit. + + To determine completeness and accuracy, the evaluator examines + other information available (e.g., functional specification, + security architecture description). Descriptions of functionality in these + documents should be consistent with what is provided for + evidence for this work unit. In particular, the functional + specification should be used to determine that the behaviour + required to implement the TSF Interfaces described by the + functional specification are completely described by the + subsystem, since the behaviour will either be SFR-enforcing, + SFR-supporting or SFR-non-interfering. + + + + + The evaluator shall examine the TOE design to determine + that it provides a complete and accurate high-level + description of the behaviour of the SFR-supporting + subsystems. + + The developer may designate subsystems as SFR-enforcing, + SFR-supporting, and SFR non-interfering, but these + ``tags'' are used only to describe the amount and type + of information the developer must provide, and can be + used to limit the amount of information the developer + has to develop if their engineering process does not + produce the documentation required. Whether the + subsystems have been categorised by the developer or + not, it is the + evaluator's responsibility to determine that the + subsystems have the appropriate information for their + role (SFR-enforcing, etc.) in the TOE, and to obtain the + appropriate information from the developer should the + developer fail to provide the required information for a + particular subsystem. + + In contrast to the previous two work units, this work + unit calls for the developer to provide (and the + evaluator to assess) information about SFR supporting + subsystems. Such subsystems should be referenced by the + descriptions of the SFR-enforcing subsystems, as well as + by the descriptions of interactions in work unit . The goal of evaluator's + assessment, like that for the previous work unit, is + two-fold. First, it should provide the evaluator with + an understanding of the way each SFR-supporting + subsystem works. Second, the evaluator determines that + the behaviour is described in enough detail so that the + way in which the subsystem supports the SFR-enforcing + behaviour is clear, and that the behaviour is not itself + SFR-enforcing. The information provided for + SFR-supporting subsystem's behaviour does not have to be + as detailed as that provided by the SFR-enforcing + behaviour. For example, data structures or data items + that do not pertain to SFR-enforcing functionality will + likely not need to be described in detail, if at all. + It is the evaluator's determination, however, with + respect to what ``high-level'' means for a particular + TOE, and the evaluator obtains enough information from + the developer (even if it turns out to be equivalent to + information provided for the parts of the subsystem that + are SFR-enforcing) to make a sound verdict for this work + unit. + + The evaluator is cautions, however, that ``perfect'' + assurance is not a goal nor required by this work unit, + so judgement will have to be exercised in determine the + amount and composition of the evidence required to make + a verdict on this work unit. + + To determine completeness and accuracy, the evaluator + examines other information available (e.g., functional + specification, security architecture description, + implementation representation). Descriptions of + functionality in these documents should be consistent + with what is provided for evidence for this work unit. + In particular, the functional specification should be + used to determine that the behaviour required to + implement the TSF Interfaces described by the functional + specification are completely described by the + subsystem. + + + + + The evaluator shall examine the TOE design to determine + that interactions between the subsystems of the TSF are + described. + + The goal of describing the interactions between the subsystems + is to help provide the reader a better understanding of how the + TSF performs it functions. These interactions do not need to be + characterised at the implementation level (e.g., parameters + passed from one routine in a subsystem to a routine in a + different subsystem; global variables; hardware signals (e.g., + interrupts) from a hardware subsystem to an interrupt-handling + subsystem), but the data elements identified for a particular + subsystem that are going to be used by another subsystem need to + be covered in this discussion. Any control relationships + between subsystems (e.g., a subsystem responsible for + configuring a rule base for a firewall system and the subsystem + that actually implements these rules) should also be + described. + + It should be noted while the developer should characterise all + interactions between subsystems, the evaluators need to use + their own judgement in assessing the completeness of the + description. If the reason for an interaction is unclear, or if + there are SFR-related interactions (discovered, for instance, in + examining the descriptions of subsystem behaviour) that do not + appear to be described, the evaluator ensures that this + information is provided by the developer. However, if the + evaluator can determine that interactions among a particular set + of subsystems, while incompletely described by the developer, + will not aid in understanding the overall functionality nor + security functionality provided by the TSF, then the evaluator + may choose to consider the description sufficient, and not + pursue completeness for its own sake. + + + + + The evaluator shall examine the TOE design to determine + that it contains a complete and accurate mapping from + the TSFI described in the functional specification to + the subsystems of the TSF described in the TOE + design. + + The subsystems described in the TOE design provide a + description of how the TSF works at a detailed level for + SFR-enforcing portions of the TSF, and at a higher level + for other portions of the TSF. The TSFI provide a + description of how the implementation is exercised. The + evidence from the developer identifies the subsystem + that is initially involved when an operation is + requested at the TSFI, and identify the various + subsystems that are primarily responsible for + implementing the functionality. Note that a complete + ``call tree'' for each TSFI is not required for this + work unit. + + The evaluator assesses the completeness of the mapping + by ensuring that all of the TSFI map to at least one + subsystem. The verification of accuracy is more + complex. + + The first aspect of accuracy is that each TSFI is mapped + to a subsystem at the TSF boundary. This determination + can be made by reviewing the subsystem description and + interactions, and from this information determining its + place in the architecture. The next aspect of accuracy + is that the mapping makes sense. For instance, mapping a + TSFI dealing with access control to a subsystem that + checks passwords is not accurate. The evaluator should + again use judgement in making this determination. The + goal is that this information aids the evaluator in + understanding the system and implementation of the SFRs, + and ways in which entities at the TSF boundary can + interact with the TSF. The bulk of the assessment of + whether the SFRs are described accurately by the + subsystems is performed in other work units. + + + + The evaluator shall determine that the design is an accurate + and complete instantiation of all security functional + requirements. + + + The evaluator shall examine the TOE security functional + requirements and the TOE design, to determine that all + ST security functional requirements are covered by the + TOE design. + + The evaluator may construct a map between the TOE security + functional requirements and the TOE design. This map will + likely be from a functional requirement to a set of + subsystems. Note that this map may have to be at a level of + detail below the component or even element level of the + requirements, because of operations (assignments, refinements, + selections) performed on the functional requirement by the ST + author. + + For example, the + component contains an element with assignments. If the + ST contained, for instance, ten rules in the assignment, and these ten + rules were implemented in specific places within fifteen + modules, it would be inadequate for the evaluator to map + to one subsystem and + claim the work unit had been completed. Instead, the + evaluator would map + (rule 1) to subsystem A, behaviours x, y, and z; (rule 2) to subsystem A, + behaviours x, p, and q; etc. + + + + The evaluator shall examine the TOE design to determine + that it is an accurate instantiation of all security + functional requirements. + + The evaluator ensures that each security requirement + listed in the TOE security functional requirements + subclause of the ST has a corresponding design description + in the TOE design that accurately details how the TSF + meets that requirement. This requires that the evaluator + identify a collection of subsystems that are responsible + for implementing a given functional requirement, and + then examine those subsystems to understand how the + requirement is implemented. Finally, the evaluator would + assess whether the requirement was accurately + implemented. + + As an example, if the ST requirements specified a + role-based access control mechanism, the evaluator would + first identify the subsystems that contribute to this + mechanism's implementation. This could be done by + in-depth knowledge or understanding of the TOE design or + by work done in the previous work unit. Note that this + trace is only to identify the subsystems, and is not the + complete analysis. + + The next step would be to understand what mechanism the + subsystems implemented. For instance, if the design + described an implementation of access control based on + UNIX-style protection bits, the design would not be an + accurate instantiation of those access control + requirements present in the ST example used above. If + the evaluator could not determine that the mechanism was + accurately implemented because of a lack of detail, the + evaluator would have to assess whether all of the + SFR-enforcing subsystems have been identified, or if + adequate detail had been provided for those + subsystems. + + + + + + + + + The objective of this sub-activity is to determine whether + the TOE design provides a description of the TOE in terms + of subsystems sufficient to determine the TSF boundary, + and provides a description of the TSF internals in terms + of modules (and optionally higher-level abstractions). It + provides a detailed description of the SFR-enforcing + modules and enough information about the SFR-supporting + and SFR-non-interfering modules for the evaluator to + determine that the SFRs are completely and accurately + implemented; as such, the TOE design provides an + explanation of the implementation representation. + + + + There are three types of activity that the evaluator must + undertake with respect to the TOE design. First, the evaluator + determines that the TSF boundary has been adequately + described. Second, the evaluator determines that the developer + has provided documentation that conforms to the content and + presentation requirements for this subsystem, and that is + consistent with other documentation provided for the + TOE. Finally, the evaluator must analyse the design information + provided for the SFR-enforcing modules (at a detailed level) and + the SFR-supporting and SFR-non-interfering modules (at a less detailed level) to + understand how the system is implemented, and with that + knowledge ensure that the TSFI in the functional specification + are adequately described, and that the test information + adequately tests the TSF (done in the work units). + + It is important to note that while the developer is obligated to + provide a complete description of the TSF (although + SFR-enforcing modules will have more detail than the + SFR-supporting or SFR-non-interfering modules), the evaluator is + expected to use their judgement in performing their + analysis. While the evaluator is expected to look at every + module, the detail to which they examine each module may + vary. The evaluator analyses each module in order to gain enough + understanding to determine the effect of the functionality of + the module on the security of the system, and the depth to which + they need to analyse the module may vary depending on the + module's role in the system. An important aspect of this + analysis is that the evaluator should use the other + documentation provided (TSS, functional specification, security + architecture description, and the TSF internal document) in + order to determine that the functionality that is described is + correct, and that the implicit designation of SFR-supporting or + SFR-non-interfering modules (see below) is supported by their + role in the system architecture. + + The developer may designate modules as SFR-enforcing, + SFR-supporting, and SFR non-interfering, but these + ``tags'' are used only to describe the amount and type + of information the developer must provide, and can be + used to limit the amount of information the developer + has to develop if their engineering process does not + produce the documentation required. Whether the + modules have been categorised by the developer or + not, it is the + evaluator's responsibility to determine that the + modules have the appropriate information for their + role (SFR-enforcing, etc.) in the TOE, and to obtain the + appropriate information from the developer should the + developer fail to provide the required information for a + particular module. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the functional specification; + + + security architecture description; + + + the TOE design. + + + + + The developer shall provide the design of the TOE. + + + The developer shall provide a mapping from the TSFI of the + functional specification to the lowest level of + decomposition available in the TOE design. + + + The design shall describe the structure of the TOE in terms + of subsystems. + + + The design shall describe the TSF in terms of modules. + + + The design shall identify all subsystems of the TSF. + + + The design shall provide a description of each subsystem of + the TSF. + + + The design shall provide a description of the interactions + among all subsystems of the TSF. + + + The design shall provide a mapping from the subsystems of + the TSF to the modules of the TSF. + + + The design shall describe each SFR-enforcing module in terms of + its purpose and relationship with other modules. + + + The design shall describe each SFR-enforcing module in terms of + its SFR-related interfaces, return values from those interfaces, + interaction with other modules and called + SFR-related interfaces to other SFR-enforcing modules. + + + The design shall describe each SFR-supporting or + SFR-non-interfering module in terms of its purpose and + interaction with other modules. + + + The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the TOE design to determine + that the structure of the entire TOE is described in + terms of subsystems. + + The evaluator ensures that all of the subsystems of the + TOE are identified. This description of the TOE will be + used as input to work unit , where the parts of the TOE that make up + the TSF are identified. That is, this requirement is on + the entire TOE rather than on only the TSF. + + The TOE (and TSF) may be described in multiple layers of + abstraction (i.e. subsystems and modules). Depending upon the + complexity of the TOE, its design may be described in terms of + subsystems and modules, as described in CC Part 3 . For a very simple TOE that can be + described solely at the ``module'' level (see ), this work unit is not + applicable and therefore considered to be satisfied. + + In performing this activity, the evaluator examines + other evidence presented for the TOE (e.g., ST, operator + user guidance) to determine that the description of the + TOE in such evidence is consistent with the description + contained in the TOE design. + + + + + The evaluator shall examine the TOE design to determine + that the entire TSF is described in terms of + modules. + + The evaluator will examine the modules for specific + properties in other work units; in this work unit the + evaluator determines that the modular description covers + the entire TSF, and not just a portion of the TSF. The + evaluator uses other evidence provided for the + evaluation (e.g., functional specification, + security architecture description) in making this + determination. For example, if the + functional specification contains interfaces to + functionality that does not appear to be described in + the TOE design description, it may be the case that a + portion of the TSF has not been included + appropriately. Making this determination will likely be + an iterative process, where as more analysis is done on + the other evidence, more confidence can be gained with + respect to the completeness of the documentation. + + Unlike subsystems, modules describe the implementation in a level of detail that can serve + as a guide to reviewing the implementation representation. A description of a module should + be such that one could create an implementation of the module from the description, and the + resulting implementation would be 1) identical to the actual TSF implementation in terms of + the interfaces presented, 2) identical in the use of interfaces that are mentioned in the + design, and 3) functionally equivalent to the description of the purpose of the TSF module. + For instance, RFC 793 provides a high-level description of the TCP protocol. It is + necessarily implementation independent. While it provides a wealth of detail, it is + not + a suitable design description because it is not specific to an implementation. An actual + implementation can add to the protocol specified in the RFC, and implementation choices (for + instance, the use of global data vs. local data in various parts of the implementation) may + have an impact on the analysis that is performed. The design description of the TCP module would + list the interfaces presented by the implementation (rather than just those defined in RFC 793), + as well as an algorithm description of the processing associated with the modules implementing + TCP (assuming it was part of the TSF). + + + + + The evaluator shall examine the TOE design to determine + that all subsystems of the TSF are identified. + + If the design is presented solely in terms of modules, + then subsystems in these requirements are equivalent to + modules and the activity should be performed at the + module level. + + In work unit all of + the subsystems of the TOE were identified, and a + determination made that the non-TSF subsystems were + correctly characterised. Building on that work, the + subsystems that were not characterised as non-TSF + subsystems should be precisely identified. The evaluator + determines that, of the hardware and software installed + and configured according to the guidance, each subsystem has been + accounted for as either one that is part of the TSF, or + one that is not. + + + + + The evaluator shall examine the TOE design to determine + that each subsystem of the TSF describes its role in + the enforcement of SFRs described in the ST. + + If the design is presented solely in terms of modules, + then this work unit will be considered satisfied by the + assessment done in subsequent work units; no explicit + action on the part of the evaluator is necessary in this + case. + + On systems that are complex enough to warrant a + subsystem-level description of the TSF in addition to + the modular description, the goal of the subsystem-level + description is to give the evaluator context for the + modular description that follows. Therefore, the + evaluator ensures that the subsystem-level description + contains a description of how the security functional + requirements are achieved in the design, but at a level + of abstraction above the modular description. This + description should discuss the mechanisms used at a + level that is aligned with the module description; this + will provide the evaluators the road map needed to + intelligently assess the information contained in the + module description. A well-written set of subsystem + descriptions will help guide the evaluator in + determining the modules that are most important to + examine, thus focusing the evaluation activity on the + portions of the TSF that have the most relevance with + respect to the enforcement of the SFRs. + + The evaluator ensures that all subsystems of the TSF + have a description. While the description should focus + on the role that the subsystem plays in enforcing or + supporting the implementation of the SFRs, enough + information must be present so that a context for + understanding the SFR-related functionality is + provided. + + The evaluator shall examine the TOE design to determine that + each SFR-non-interfering subsystem of the TSF is described such that + the evaluator can determine that the subsystem is SFR-non-interfering. + If the design is presented solely in terms of modules, then this work unit + will be considered satisfied by the assessment done in subsequent work units; + no explicit action on the part of the evaluator is necessary in this case. + An SFR-non-interfering subsystem is one on which the SFR-enforcing and + SFR-supporting subsystems have no dependence; that is, they play no role + in implementing SFR functionality. + The evaluator ensures that all subsystems of the TSF have a description. + While the description should focus on the role that the subsystem do not plays + in enforcing or supporting the implementation of the SFRs, enough information + must be present so that a context for understanding the SFR-non-interfering + functionality is provided. + + + + The evaluator shall examine the TOE design to determine + that interactions between the subsystems of the TSF are + described. + + If the design is presented solely in terms of modules, + then this work unit will be considered satisfied by the + assessment done in subsequent work units; no explicit + action on the part of the evaluator is necessary in this + case. + + On systems that are complex enough to warrant a subsystem-level + description of the TSF in addition to the modular description, + the goal of describing the interactions between the subsystems + is to help provide the reader a better understanding of how the + TSF performs its functions. These interactions do not need to be + characterised at the implementation level (e.g., parameters + passed from one routine in a subsystem to a routine in a + different subsystem; global variables; hardware signals (e.g., + interrupts) from a hardware subsystem to an interrupt-handling + subsystem), but the data elements identified for a particular + subsystem that are going to be used by another subsystem should + be covered in this discussion. Any control relationships + between subsystems (e.g., a subsystem responsible for + configuring a rule base for a firewall system and the subsystem + that actually implements these rules) should also be described. + + It should be noted while the developer should characterise all + interactions between subsystems, the evaluators need to use + their own judgement in assessing the completeness of the + description. If the reason for an interaction is unclear, or if + there are SFR-related interactions (discovered, for instance, in + examining the module-level documentation) that do not appear to + be described, the evaluator ensures that this information is + provided by the developer. However, if the evaluator can + determine that interactions among a particular set of + subsystems, while incompletely described by the developer, and a + complete description will not aid in understanding the overall + functionality nor security functionality provided by the TSF, + then the evaluator may choose to consider the description + sufficient, and not pursue completeness for its own sake. + + + + + The evaluator shall examine the TOE design to determine + that the mapping between the subsystems of the TSF and + the modules of the TSF is complete. + + If the design is presented solely in terms of modules, + then this work unit is considered satisfied. + + For TOEs that are complex enough to warrant a + subsystem-level description of the TSF in addition to + the modular description, the developer provides a simple + mapping showing how the modules of the TSF are allocated + to the subsystems. This will provide the evaluator a + guide in performing their module-level assessment. To + determine completeness, the evaluator examines each + mapping and determines that all subsystems map to at + least one module, and that all modules map to exactly + one subsystem. + + + + + The evaluator shall examine the TOE design to determine + that the mapping between the subsystems of the TSF and + the modules of the TSF is accurate. + + If the design is presented solely in terms of modules, + then this work unit is considered satisfied. + + For TOEs that are complex enough to warrant a + subsystem-level description of the TSF in addition to + the modular description, the developer provides a simple + mapping showing how the modules of the TSF are allocated + to the subsystems. This will provide the evaluator a + guide in performing their module-level assessment. The + evaluator may choose to check the accuracy of the + mapping in conjunction with performing other work + units. An ``inaccurate'' mapping is one where the module + is mistakenly associated with a subsystem where its + functions are not used within the subsystem. Because the + mapping is intended to be a guide supporting more + detailed analysis, the evaluator is cautioned to apply + appropriate effort to this work unit. Expending + extensive evaluator resources verifying the accuracy of + the mapping is not necessary. Inaccuracies that lead to + mis-understandings related to the design that are + uncovered as part of this or other work units are the + ones that should be associated with this work unit and + corrected. + + + + + The evaluator shall examine the TOE design to determine + that the description of the purpose of each + SFR-enforcing module and relationship with other modules is complete and accurate. + + The developer may designate modules as SFR-enforcing, + SFR-supporting, and SFR non-interfering, but these + ``tags'' are used only to describe the amount and type + of information the developer must provide, and can be + used to limit the amount of information the developer + has to develop if their engineering process does not + produce the documentation required. Whether the + modules have been categorised by the developer or + not, it is the + evaluator's responsibility to determine that the + modules have the appropriate information for their + role (SFR-enforcing, etc.) in the TOE, and to obtain the + appropriate information from the developer should the + developer fail to provide the required information for a + particular module. + + The purpose of a module provides a description + indicating what function the module is fulfilling. A + word of caution to evaluator is in order. The focus of + this work unit should be to provide the evaluator an + understanding of how the module works so that + determinations can be made about the soundness of the + implementation of the SFRs, as well as to support + architectural analysis performed for component. As long as the evaluator has a + sound understanding of the module's operation, and its + relationship to other modules and the TOE as a whole, + the evaluator should consider the objective of the work + achieved and not engage in a documentation exercise for + the developer (by requiring, for example, a complete + algorithmic description for a self-evident + implementation representation). + Because the modules are at such a low level, it may be difficult + determine completeness and accuracy impacts from other + documentation, such as operational user guidance, the functional + specification, the TSF internals, or the security architecture + description. However, the evaluator uses the information present + in those documents to the extent possible to help ensure that + the purpose is accurately and completely described. This + analysis can be aided by the analysis performed for the work + units for the element, + which maps the TSFI in the functional specification to the + modules of the TSF. + + + + + The evaluator shall examine the TOE design to determine + that the description of the interfaces presented by each + SFR-enforcing module contain an accurate and complete + description of the SFR-related parameters, the + invocation conventions for each interface, and any + values returned directly by the interface. + + The SFR-related interfaces of a module are those + interfaces used by other modules as a means to invoke + the SFR-related operations provided, and to provide + inputs to or receive outputs from the module. The + purpose in the specification of these interfaces is to + permit the exercise of them during testing. + Inter-module interfaces that are not SFR-related need + not be specified or described, since they are not a + factor in testing. Likewise, other internal interfaces + that are not a factor in traversing SFR-related paths of + execution (such as those internal paths that are fixed) + need not be specified or described, since they are not a factor in testing. + + SFR-related interfaces are described in terms of how + they are invoked, and any values that are returned. This + description would include a list of SFR-related + parameters, and descriptions of these parameters. Note + that global data would also be considered parameters if + used by the module (either as inputs or outputs) when + invoked. If a parameter were expected to take on a set + of values (e.g., a ``flag'' parameter), the complete set + of values the parameter could take on that would have an + effect on module processing would be + specified. Likewise, parameters representing data + structures are described such that each field of the + data structure is identified and described. Note that + different programming languages may have additional + ``interfaces'' that would be non-obvious; an example + would be operator/function overloading in C++. This + ``implicit interface'' in the class description would + also be described as part of the low-level TOE + design. Note that although a module could present only + one interface, it is more common that a module presents + a small set of related interfaces. + + In terms of the assessment of parameters (inputs and + outputs) to a module, any use of global data must also + be considered. A module ``uses'' global data if it + either reads or writes the data. In order to assure the + description of such parameters (if used) is complete, + the evaluator uses other information provided about the + module in the TOE design (interfaces, algorithmic + description, etc.), as well as the description of the + particular set of global data assessed in work unit + . For instance, the + evaluator could first determine the processing the + module performs by examining its function and interfaces + presented (particularly the parameters of the + interfaces). They could then check to see if the + processing appears to ``touch'' any of the global data + areas identified in the TOE design. The evaluator then + determines that, for each global data area that appears + to be ``touched'', that global data area is listed as a + means of input or output by the module the evaluator is + examining. + + Invocation conventions are a programming-reference-type + description that one could use to correctly invoke a + module's interface if one were writing a program to make + use of the module's functionality through that + interface. This includes necessary inputs and outputs, + including any set-up that may need to be performed with + respect to global variables. + + Values returned through the interface refer to values + that are either passed through parameters or messages; + values that the function call itself returns in the + style of a ``C'' program function call; or values passed + through global means (such as certain error routines in + *ix-style operating systems). + + In order to assure the description is complete, the + evaluator uses other information provided about the + module in the TOE design (e.g., algorithmic description, + global data used) to ensure that it appears all data + necessary for performing the functions of the module is + presented to the module, and that any values that other + modules expect the module under examination to provide + are identified as being returned by the module. The + evaluator determines accuracy by ensuring that the + description of the processing matches the information + listed as being passed to or from an interface. + + + + + + The evaluator shall examine the TOE design to determine that + SFR-supporting and SFR-non-interfering modules are correctly + categorised. + + In the cases where the developer has provided different amounts + of information for different modules, an implicit categorisation + has been done. That is, modules (for instance) with detail + presented on their SFR-related interfaces (see ) are candidate SFR-enforcing + modules, although examination by the evaluator may lead to a + determination that some set of them are SFR-supporting or + SFR-non-interfering. Those with only a description of their + purpose and interaction with other modules (for instance) are + ``implicitly categorised'' as SFR-supporting or + SFR-non-interfering. + + In these cases, a key focus of the evaluator for this work unit + is attempting to determine from the evidence provided for each + module implicitly categorised as SFR-supporting or + SFR-non-interfering and the evaluation information about other + modules (in the TOE design, the functional specification, the + security architecture description, and the operational user + guidance), whether the module is indeed SFR-supporting or + SFR-non-interfering. At this level of assurance some error + should be tolerated; the evaluator does not have to be + absolutely sure that a given module is SFR-supporting or + SFR-non-interfering, even though it is labelled as + such. However, if the evidence provided indicates that a + SFR-supporting or SFR-non-interfering module is SFR-enforcing, + the evaluator requests additional information from the developer + in order to resolve the apparent inconsistency. For instance, + suppose the documentation for Module A (an SFR-enforcing module) + indicates that it calls Module B to perform an access check on a + certain type of construct. When the evaluator examines the + information associated with Module B, they find that all the + developer has provided is a purpose and a set of interactions + (thus implicitly categorising Module B as SFR-supporting or + SFR-non-interfering). On examining the purpose and interactions + from Module A, the evaluator finds no mention of Module B + performing any access checks, and Module A is not listed as a + module with which Module B interacts. At this point the + evaluator should approach the developer to resolve the + discrepancies between the information provided in Module A and + that in Module B. + + Another example would be where the evaluator examines the + mapping of the TSFI to the modules as provided by . This examination shows that + Module C is associated with an SFR requiring identification of + the user. Again, when the evaluator examines the information + associated with Module C, they find that all the developer has + provided is a purpose and a set of interactions (thus implicitly + categorising Module C as SFR-supporting or + SFR-non-interfering). Examining the purpose and interactions + presented for Module C, the evaluator is unable to determine why + Module C, listed as mapping to a TSFI concerned with user + identification, would not be classified as SFR-enforcing. Again, + the evaluator should approach the developer to resolve this + discrepancy. + + + A final example is from the opposite point of view. As + before, the developer has provided information associated + with Module D consisting of a purpose and a set of + interactions (thus implicitly categorising Module D as + SFR-supporting or SFR-non-interfering). The evaluator + examines all of the evidence provided, including the purpose + and interactions for Module D. The purpose appears to give a + meaningful description of Module D's function in the TOE, + the interactions are consistent with that description, and + there is nothing to indicate that Module D is + SFR-enforcing. In this case, the evaluator should not demand + more information about Module D ``just be to sure'' it is + correctly categorised. The developer has met their + obligations and the resulting assurance the evaluator has in + the implicit categorisation of Module D is (by definition) + appropriate for this assurance level. + + + + + The evaluator shall examine the TOE design to determine that the + description of the purpose of each SFR-supporting or + SFR-non-interfering module is complete and accurate. + + The description of the purpose of a module indicates + what function the module is fulfilling. From the + description, the evaluator should be able to obtain a + general idea of the module's role. In order to assure + the description is complete, the evaluator uses the + information provided about the module's interactions + with other modules to assess whether the reasons for the + module being called are consistent with the module's + purpose. If the interaction description contains + functionality that is not apparent from, or in conflict + with, the module's purpose, the evaluator needs to + determine whether the problem is one of accuracy or of + completeness. The evaluator should be wary of purposes + that are too short, since meaningful analysis based on a + one-sentence purpose is likely to be impossible. + + Because the modules are at such a low level, it may be difficult determine + completeness and accuracy impacts from other documentation, + such as administrative guidance, the functional specification, + the security architecture description, or the TSF internals document. + However, the evaluator uses the information present in those documents + to the extent possible to help ensure that the function is accurately + and completely described. This analysis can be aided by the analysis + performed for the work units for the ADV_TDS.3.10C element, + which maps the TSFI in the functional specification to the modules of the TSF. + + + + + The evaluator shall examine the TOE design to determine that the + description of a SFR-supporting or SFR-non-interfering module's + interaction with other modules is complete and accurate. + + It is important to note that, in terms of the Part 3 + requirement and this work unit, the term + interaction is intended to convey less + rigour than interface. An interaction + does not need to be characterised at the implementation + level (e.g., parameters passed from one routine in a + module to a routine in a different module; global + variables; hardware signals (e.g., interrupts) from a + hardware subsystem to an interrupt-handling subsystem), + but the data elements identified for a particular module + that are going to be used by another module should be + covered in this discussion. Any control relationships + between modules (e.g., a module responsible for + configuring a rule base for a firewall system and the + module that actually implements these rules) should also + be described. + + Because the modules are at such a low level, it may be difficult + determine completeness and accuracy impacts from other + documentation, such as operational user guidance, the functional + specification, the security architecture description, or the TSF + internals document. However, the evaluator uses the information + present in those documents to the extent possible to help ensure + that the function is accurately and completely described. This + analysis can be aided by the analysis performed for the work + units for the element, + which maps the TSFI in the functional specification to the + modules of the TSF. + + A module's interaction with other modules goes beyond + just a call-tree-type document. The interaction is + described from a functional perspective of why a module + interacts with other modules. The module's purpose + describes what functions the module provides to other + modules; the interactions should describe what the + module depends on from other modules in order to + accomplish this function. + + + + + + The evaluator shall examine the TOE design to determine + that it contains a complete and accurate mapping from + the TSFI described in the functional specification to + the modules of the TSF described in the TOE + design. + + The modules described in the TOE design provide a description of + the implementation of the TSF. The TSFI provide a description of + how the implementation is exercised. The evidence from the + developer identifies the module that is initially invoked when + an operation is requested at the TSFI, and identifies the chain + of modules invoked up to the module that is primarily + responsible for implementing the functionality. However, a + complete call tree for each TSFI is not required for this work + unit. The cases in which more than one module would have to be + identified are where there are ``entry point'' modules or + wrapper modules that have no functionality other than + conditioning inputs or de-multiplexing an input. Mapping to one + of these modules would not provide any useful information to the + evaluator. + + The evaluator assesses the completeness of the mapping + by ensuring that all of the TSFI map to at least one + module. The verification of accuracy is more + complex. + + The first aspect of accuracy is that each TSFI is mapped to a module at the TSF boundary. + This determination can be made by reviewing the module description and its + interfaces/interactions. The next aspect of accuracy is that each TSFI identifies + a chain of modules between the initial module identified and a module + that is primarily responsible for implementing the function presented at the TSF. + Note that this may be the initial module, or there may be several modules, + depending on how much pre-conditioning of the inputs is done. It should be noted that + one indicator of a pre-conditioning module is that it is invoked for a large number + of the TSFI, where the TSFI are all of similar type (e.g., system call). + The final aspect of accuracy is that the mapping makes sense. For instance, + mapping a TSFI dealing with access control to a module that checks passwords + is not accurate. The evaluator should again use judgement in making this determination. + The goal is that this information aids the evaluator in understanding the system and + implementation of the SFRs, and ways in which entities at the TSF boundary can interact + with the TSF. The bulk of the assessment of whether the SFRs are described accurately + by the modules is performed in other work units. + + + + The evaluator shall determine that the design is an accurate + and complete instantiation of all security functional + requirements. + + + The evaluator shall examine the TOE security functional + requirements and the TOE design, to determine that all + ST security functional requirements are covered by the + TOE design. + + The evaluator may construct a map between the TOE + security functional requirements and the TOE design. + This map will likely be from a functional requirement to + a set of subsystems, and later to modules. Note that this map may have to be + at a level of detail below the component or even element + level of the requirements, because of operations + (assignments, refinements, selections) performed on the + functional requirement by the ST author. + + For example, the + component contains an element with assignments. If the + ST contained, for instance, ten rules in the assignment, and these ten + rules were implemented in specific places within fifteen + modules, it would be inadequate for the evaluator to map + to one subsystem and + claim the work unit had been completed. Instead, the + evaluator would map + (rule 1) to modules x, y, and z of subsystem A; + (rule 2) to modules x, p, and q of subsystem A; etc. + + + + The evaluator shall examine the TOE design to determine + that it is an accurate instantiation of all security + functional requirements. + + The evaluator may construct a map between the TOE security + functional requirements and the TOE design. This map will + likely be from a functional requirement to a set of + subsystems. Note that this map may have to be at a level of + detail below the component or even element level of the + requirements, because of operations (assignments, refinements, + selections) performed on the functional requirement by the ST + author. + + As an example, if the ST requirements specified a + role-based access control mechanism, the evaluator would + first identify the subsystems, and modules that contribute to this + mechanism's implementation. This could be done by + in-depth knowledge or understanding of the TOE design or + by work done in the previous work unit. Note that this + trace is only to identify the subsystems, and modules, and is not the + complete analysis. + + The next step would be to understand what mechanism the + subsystems, and modules implemented. For instance, if the design + described an implementation of access control based on + UNIX-style protection bits, the design would not be an + accurate instantiation of those access control + requirements present in the ST example used above. If + the evaluator could not determine that the mechanism was + accurately implemented because of a lack of detail, the + evaluator would have to assess whether all of the + SFR-enforcing subsystems and modules have been identified, or if + adequate detail had been provided for those subsystems and modules. + + + + + + + + + The objective of this sub-activity is to determine whether + the TOE design provides a description of the TOE in terms + of subsystems sufficient to determine the TSF boundary, + and provides a description of the TSF internals in terms + of modules (and optionally higher-level abstractions). It + provides a detailed description of the SFR-enforcing and + SFR-supporting modules and enough information about the + SFR-non-interfering modules for the evaluator to determine + that the SFRs are completely and accurately implemented; + as such, the TOE design provides an explanation of the + implementation representation. + + + + There are three types of activity that the evaluator must + undertake with respect to the TOE design. First, the evaluator + determines that the TSF boundary has been adequately + described. Second, the evaluator determines that the developer + has provided documentation that conforms to the content and + presentation requirements this subsystem, and that is consistent + with other documentation provided for the TOE. Finally, the + evaluator must analyse the design information provided for the + SFR-enforcing modules (at a detailed level) and the + SFR-supporting and SFR-non-interfering modules (at a less detailed level) to + understand how the system is implemented, and with that + knowledge ensure that the TSFI in the functional specification + are adequately described, and that the test information + adequately tests the TSF (done in the work units). + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the functional specification; + + + security architecture description; + + + the TOE design. + + + + + The developer shall provide the design of the TOE. + + + The developer shall provide a mapping from the TSFI of the + functional specification to the lowest level of + decomposition available in the TOE design. + + + The design shall describe the structure of the TOE in terms + of subsystems. + + + The design shall describe the TSF in terms of modules, + designating each module as SFR-enforcing, + SFR-supporting, or SFR-non-interfering. + + + The design shall identify all subsystems of the TSF. + + + The design shall provide a semiformal description of each subsystem of + the TSF, supported by informal, explanatory text where appropriate. + + + The design shall provide a description of the interactions + among all subsystems of the TSF. + + + The design shall provide a mapping from the subsystems of + the TSF to the modules of the TSF. + + + The design shall describe each SFR-enforcing and SFR-supporting + module in terms of its purpose and relationship with other + modules. + + + The design shall describe each SFR-enforcing and SFR-supporting module + in terms of its SFR-related interfaces, return values from those interfaces, + interaction with other modules and called SFR-related + interfaces to other SFR-enforcing or SFR-supporting modules. + + + The design shall describe each SFR-non-interfering module in + terms of its purpose and interaction with other modules. + + + The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the TOE design to determine + that the structure of the entire TOE is described in + terms of subsystems. + + The evaluator ensures that all of the subsystems of the + TOE are identified. This description of the TOE will be + used as input to work unit , where the parts of the TOE that make up + the TSF are identified. That is, this requirement is on + the entire TOE rather than on only the TSF. + + The TOE (and TSF) may be described in multiple layers of + abstraction (i.e. subsystems and modules) Depending upon + the complexity of the TOE, its design may be described + in terms of subsystems and modules, as described in CC + Part 3 . For a very + simple TOE that can be described solely at the + ``module'' level (see ), this work unit is not applicable and + therefore considered to be satisfied. + + In performing this activity, the evaluator examines + other evidence presented for the TOE (e.g., ST, operator + user guidance) to determine that the description of the + TOE in such evidence is consistent with the description + contained in the TOE design. + + + + + The evaluator shall examine the TOE design to determine + that the entire TSF is described in terms of + modules. + + The evaluator will examine the modules for specific + properties in other work units; in this work unit the + evaluator determines that the modular description covers + the entire TSF, and not just a portion of the TSF. The + evaluator uses other evidence provided for the + evaluation (e.g., functional specification, + architectural description) in making this + determination. For example, if the functional + specification contains interfaces to functionality that + does not appear to be described in the TOE design + description, it may be the case that a portion of the + TSF has not been included appropriately. Making this + determination will likely be an iterative process, where + as more analysis is done on the other evidence, more + confidence can be gained with respect to the + completeness of the documentation. + + Unlike subsystems, modules describe the implementation in a level of detail that can serve + as a guide to reviewing the implementation representation. A description of a module should + be such that one could create an implementation of the module from the description, and the + resulting implementation would be 1) identical to the actual TSF implementation in terms of + the interfaces presented, 2) identical in the use of interfaces that are mentioned in the + design, and 3) functionally equivalent to the description of the purpose of the TSF module. + For instance, RFC 793 provides a high-level description of the TCP protocol. It is + necessarily implementation independent. While it provides a wealth of detail, it is + not + a suitable design description because it is not specific to an implementation. An actual + implementation can add to the protocol specified in the RFC, and implementation choices (for + instance, the use of global data vs. local data in various parts of the implementation) may + have an impact on the analysis that is performed. The design description of the TCP module would + list the interfaces presented by the implementation (rather than just those defined in RFC 793), + as well as an algorithm description of the processing associated with the modules implementing + TCP (assuming it was part of the TSF). + + + + + The evaluator shall check the TOE design to determine + that the TSF modules are identified as either + SFR-enforcing, SFR-supporting, or + SFR-non-interfering. + + The purpose of designating each module (according to the role a + particular module plays in the enforcement of the SFRs) is to + allow developers to provide less information about the parts of + the TSF that have little role in security. It is always + permissible for the developer to provide more information or + detail than the requirements demand, as might occur when the + information has been gathered outside the evaluation context. In + such cases the developer must still designate the modules as + either SFR-enforcing, SFR-supporting, or + SFR-non-interfering. + + The accuracy of these designations is continuously + reviewed as the evaluation progresses. The concern is + the mis-designation of modules as being less important + (and hence, having less information) than is really the + case. While blatant mis-designations may be immediately + apparent (e.g., designating an authentication module as + anything but SFR-enforcing when is one of the SFRs being claimed), other + mis-designations might not be discovered until the TSF + is better understood. The evaluator must therefore keep + in mind that these designations are the developer's + initial best effort, but are subject to change. Further + guidance is provided under work unit , which examines the + accuracy of these designations. + + + + + The evaluator shall examine the TOE design to determine + that all subsystems of the TSF are identified. + + If the design is presented solely in terms of modules, + then subsystems in these requirements are equivalent to + modules and the activity should be performed at the + module level. + + In work unit all of + the subsystems of the TOE were identified, and a + determination made that the non-TSF subsystems were + correctly characterised. Building on that work, the + subsystems that were not characterised as non-TSF + subsystems should be precisely identified. The evaluator + determines that, of the hardware and software installed + and configured according to the guidance, each subsystem has been + accounted for as either one that is part of the TSF, or + one that is not. + The evaluator shall examine the TDS documentation to determine + that the semiformal notation used for describing the subsystems, modules and + their interfaces is defined or referenced.A semiformal notation can be either defined by the sponsor or + a corresponding standard be referenced. The evaluator should provide a mapping + of security functions and their interfaces outlining in what part of the + documentation a function or interface is semiformal described and what notation + is used. The evaluator examines all semiformal notations used to make sure that + they are of a semiformal style and to justify the appropriateness of the manner + how the semiformal notations are used for the TOE.The evaluator is reminded that a semi-formal presentation is + characterised by a standardised format with a well-defined syntax that reduces + ambiguity that may occur in informal presentations. The syntax of all semiformal + notations used in the functional specification shall be defined or a corresponding + standard be referenced. The evaluator verifies that the semiformal notations used + for expressing the functional specification are capable of expressing features + relevant to security. In order to determine this, the evaluator can refer to the + SFR and compare the TSF security features stated in the ST and those described + in the FSP using the semiformal notations. + + + + The evaluator shall examine the TOE design to determine + that each subsystem of the TSF describes its role in + the enforcement of SFRs described in the ST. + + If the design is presented solely in terms of modules, + then this work unit will be considered satisfied by the + assessment done in subsequent work units; no explicit + action on the part of the evaluator is necessary in this + case. + + On systems that are complex enough to warrant a + subsystem-level description of the TSF in addition to + the modular description, the goal of the subsystem-level + description is to give the evaluator context for the + modular description that follows. Therefore, the + evaluator ensures that the subsystem-level description + contains a description of how the security functional + requirements are achieved in the design, but at a level + of abstraction above the modular description. This + description should discuss the mechanisms used at a + level that is aligned with the module description; this + will provide the evaluators the road map needed to + intelligently assess the information contained in the + module description. A well-written set of subsystem + descriptions will help guide the evaluator in + determining the modules that are most important to + examine, thus focusing the evaluation activity on the + portions of the TSF that have the most relevance with + respect to the enforcement of the SFRs. + + The evaluator ensures that all subsystems of the TSF + have a description. While the description should focus + on the role that the subsystem plays in enforcing or + supporting the implementation of the SFRs, enough + information must be present so that a context for + understanding the SFR-related functionality is + provided. + + The evaluator shall examine the TOE design to determine that + each SFR-non-interfering subsystem of the TSF is described such that + the evaluator can determine that the subsystem is SFR-non-interfering. + If the design is presented solely in terms of modules, then this work unit + will be considered satisfied by the assessment done in subsequent work units; + no explicit action on the part of the evaluator is necessary in this case. + An SFR-non-interfering subsystem is one on which the SFR-enforcing and + SFR-supporting subsystems have no dependence; that is, they play no role + in implementing SFR functionality. + The evaluator ensures that all subsystems of the TSF have a description. + While the description should focus on the role that the subsystem do not plays + in enforcing or supporting the implementation of the SFRs, enough information + must be present so that a context for understanding the SFR-non-interfering + functionality is provided. + + + + The evaluator shall examine the TOE design to determine + that interactions between the subsystems of the TSF are + described. + + If the design is presented solely in terms of modules, + then this work unit will be considered satisfied by the + assessment done in subsequent work units; no explicit + action on the part of the evaluator is necessary in this + case. + + On systems that are complex enough to warrant a subsystem-level + description of the TSF in addition to the modular description, + the goal of describing the interactions between the subsystems + is to help provide the reader a better understanding of how the + TSF performs it functions. These interactions do not need to be + characterised at the implementation level (e.g., parameters + passed from one routine in a subsystem to a routine in a + different subsystem; global variables; hardware signals (e.g., + interrupts) from a hardware subsystem to an interrupt-handling + subsystem), but the data elements identified for a particular + subsystem that are going to be used by another subsystem need to + be covered in this discussion. Any control relationships + between subsystems (e.g., a subsystem responsible for + configuring a rule base for a firewall system and the subsystem + that actually implements these rules) should also be + described. + + It should be noted while the developer should characterise all + interactions between subsystems, the evaluators need to use + their own judgement in assessing the completeness of the + description. If the reason for an interaction is unclear, or if + there are SFR-related interactions (discovered, for instance, in + examining the module-level documentation) that do not appear to + be described, the evaluator ensures that this information is + provided by the developer. However, if the evaluator can + determine that interactions among a particular set of + subsystems, while incompletely described by the developer, and a + complete description will not aid in understanding the overall + functionality nor security functionality provided by the TSF, + then the evaluator may choose to consider the description + sufficient, and not pursue completeness for its own sake. + + + + + The evaluator shall examine the TOE design to determine + that the mapping between the subsystems of the TSF and + the modules of the TSF is complete. + + If the design is presented solely in terms of modules, + then this work unit is considered satisfied. + + For TOEs that are complex enough to warrant a + subsystem-level description of the TSF in addition to + the modular description, the developer provides a simple + mapping showing how the modules of the TSF are allocated + to the subsystems. This will provide the evaluator a + guide in performing their module-level assessment. To + determine completeness, the evaluator examines each + mapping and determines that all subsystems map to at + least one module, and that all modules map to exactly + one subsystem. + + + + + The evaluator shall examine the TOE design to determine + that the mapping between the subsystems of the TSF to + the modules of the TSF is accurate. + + If the design is presented solely in terms of modules, + then this work unit is considered satisfied. + + For TOEs that are complex enough to warrant a + subsystem-level description of the TSF in addition to + the modular description, the developer provides a simple + mapping showing how the modules of the TSF are allocated + to the subsystems. This will provide the evaluator a + guide in performing their module-level assessment. The + evaluator may choose to check the accuracy of the + mapping in conjunction with performing other work + units. An ``inaccurate'' mapping is one where the module + is mistakenly associated with a subsystem where its + functions are not used within the subsystem. Because the + mapping is intended to be a guide supporting more + detailed analysis, the evaluator is cautioned to apply + appropriate effort to this work unit. Expending + extensive evaluator resources verifying the accuracy of + the mapping is not necessary. Inaccuracies that lead to + mis-understandings related to the design that are + uncovered as part of this or other work units are the + ones that should be associated with this work unit and + corrected. + + + + + The evaluator shall examine the TOE design to determine + that the description of the purpose of each + SFR-enforcing and SFR-supporting module, and relationship with other modules + is complete and accurate. + + The developer may designate modules as SFR-enforcing, + SFR-supporting, and SFR non-interfering, but these + ``tags'' are used only to describe the amount and type + of information the developer must provide, and can be + used to limit the amount of information the developer + has to develop if their engineering process does not + produce the documentation required. Whether the modules + have been categorised by the developer or not, it is the + evaluator's responsibility to determine that the modules + have the appropriate information for their role + (SFR-enforcing, etc.) in the TOE, and to obtain the + appropriate information from the developer should the + developer fail to provide the required information for a + particular module. + + The purpose of a module provides a description + indicating what function the module is fulfilling. A + word of caution to evaluator is in order. The focus of + this work unit should be to provide the evaluator an + understanding of how the module works so that + determinations can be made about the soundness of the + implementation of the SFRs, as well as to support + architectural analysis performed for subsystems. As long as the evaluator has a + sound understanding of the module's operation, and its + relationship to other modules and the TOE as a whole, + the evaluator should consider the objective of the work + achieved and not engage in a documentation exercise for + the developer (by requiring, for example, a complete + algorithmic description for a self-evident + implementation representation). + Because the modules are at such a low level, it may be difficult + determine completeness and accuracy impacts from other + documentation, such as operational user guidance, the functional + specification, the TSF internals, or the security architecture + description. However, the evaluator uses the information present + in those documents to the extent possible to help ensure that + the purpose is accurately and completely described. This + analysis can be aided by the analysis performed for the work + units for the element, + which maps the TSFI in the functional specification to the + modules of the TSF. + + + + + The evaluator shall examine the TOE design to determine + that the description of the interfaces presented by each + SFR-enforcing and SFR-supporting module contain an + accurate and complete description of the SFR-related + parameters, the invocation conventions for each + interface, and any values returned directly by the + interface. + + The SFR-related interfaces of a module are those + interfaces used by other modules as a means to invoke + the SFR-related operations provided, and to provide + inputs to or receive outputs from the module. The + purpose in the specification of these interfaces is to + permit the exercise of them during testing. + Inter-module interfaces that are not SFR-related need + not be specified or described, since they are not a + factor in testing. Likewise, other internal interfaces + that are not a factor in traversing SFR-related paths of + execution (such as those internal paths that are + fixed). + SFR-related interfaces of SFR-supporting modules are all + interfaces of SFR-supporting modules that are called directly + or indirectly from SFR-enforcing modules. Those interfaces + need to be described with all the parameter used in such a + call. This allows the evaluator to understand the purpose of + the call to the SFR-supporting module in the context of + operation of the SFR-enforcing modules. + + SFR-related interfaces are described in terms of how + they are invoked, and any values that are returned. This + description would include a list of parameters, and + descriptions of these parameters. Note that global data + would also be considered parameters if used by the + module (either as inputs or outputs) when invoked. If a + parameter were expected to take on a set of values + (e.g., a ``flag'' parameter), the complete set of values + the parameter could take on that would have an effect on + module processing would be specified. Likewise, + parameters representing data structures are described + such that each field of the data structure is identified + and described. Note that different programming languages + may have additional ``interfaces'' that would be + non-obvious; an example would be operator/function + overloading in C++. This ``implicit interface'' in the + class description would also be described as part of the + low-level TOE design. Note that although a module could + present only one interface, it is more common that a + module presents a small set of related + interfaces. + + In terms of the assessment of parameters (inputs and + outputs) to a module, any use of global data must also + be considered. A module ``uses'' global data if it + either reads or writes the data. In order to assure the + description of such parameters (if used) is complete, + the evaluator uses other information provided about the + module in the TOE design (interfaces, algorithmic + description, etc.), as well as the description of the + particular set of global data assessed in work unit + . For instance, the + evaluator could first determine the processing the + module performs by examining its function and interfaces + presented (particularly the parameters of the + interfaces). They could then check to see if the + processing appears to ``touch'' any of the global data + areas identified in the TDS design. The evaluator then + determines that, for each global data area that appears + to be ``touched'', that global data area is listed as a + means of input or output by the module the evaluator is + examining. + + Invocation conventions are a programming-reference-type + description that one could use to correctly invoke a + module's interface if one were writing a program to make + use of the module's functionality through that + interface. This includes necessary inputs and outputs, + including any set-up that may need to be performed with + respect to global variables. + + Values returned through the interface refer to values + that are either passed through parameters or messages; + values that the function call itself returns in the + style of a ``C'' program function call; or values passed + through global means (such as certain error routines in + *ix-style operating systems). + + In order to assure the description is complete, the + evaluator uses other information provided about the + module in the TOE design (e.g., algorithmic description, + global data used) to ensure that it appears all data + necessary for performing the functions of the module is + presented to the module, and that any values that other + modules expect the module under examination to provide + are identified as being returned by the module. The + evaluator determines accuracy by ensuring that the + description of the processing matches the information + listed as being passed to or from an interface. + + + + + + The evaluator shall examine the TOE design to determine + that SFR-non-interfering modules are correctly + categorised. + + As mentioned in work unit , + less information is required about modules that are + SFR-non-interfering. A key focus of the evaluator for this work + unit is attempting to determine from the evidence provided for + each module implicitly categorised as SFR-non-interfering and + the evaluation (information about other modules in the TOE + design, the functional specification, the security architecture + description, the operational user guidance, the TSF internals + document, and perhaps even the implementation representation) + whether the module is indeed SFR-non-interfering. At this level + of assurance some error should be tolerated; the evaluator does + not have to be absolutely sure that a given module is + SFR-non-interfering, even though it is labelled as + such. However, if the evidence provided indicates that a + SFR-non-interfering module is SFR-enforcing or SFR-supporting, + the evaluator requests additional information from the developer + in order to resolve the apparent inconsistency. For example, + suppose the documentation for Module A (an SFR-enforcing module) + indicates that it calls Module B to perform an access check on a + certain type of construct. When the evaluator examines the + information associated with Module B, it is discovered that the + only information the developer has provided is a purpose and a + set of interactions (thus implicitly categorising Module B as + SFR-supporting or SFR-non-interfering). On examining the purpose and interactions + from Module A, the evaluator finds no mention of Module B + performing any access checks, and Module A is not listed as a + module with which Module B interacts. At this point the + evaluator should approach the developer to resolve the + discrepancies between the information provided in Module A and + that in Module B. + + Another example would be where the evaluator examines + the mapping of the TSFI to the modules as provided by + . This examination + shows that Module C is associated with an SFR requiring + identification of the user. Again, when the evaluator + examines the information associated with Module C, they + find that all the developer has provided is a purpose + and a set of interactions (thus implicitly categorising + Module C as SFR-non-interfering). Examining the purpose + and interactions presented for Module C, the evaluator + is unable to determine why Module C, listed as mapping + to a TSFI concerned with user identification, would not + be classified as SFR-enforcing or SFR-supporting. Again, + the evaluator should approach the developer to resolve + this discrepancy. + + A final example illustrates the opposite situation. As + before, the developer has provided information + associated with Module D consisting of a purpose and a + set of interactions (thus implicitly categorising Module + D as SFR-non-interfering). The evaluator examines all of + the evidence provided, including the purpose and + interactions for Module D. The purpose appears to give a + meaningful description of Module D's function in the + TOE, the interactions are consistent with that + description, and there is nothing to indicate that + Module D is SFR-enforcing or SFR-supporting. In this + case, the evaluator should not demand more information + about Module D ``just be to sure'' it is correctly + categorised. The developer has met the obligations and + the resulting assurance the evaluator has in the + implicit categorisation of Module D is (by definition) + appropriate for this assurance level. + + + + + The evaluator shall examine the TOE design to determine + that the description of the purpose of each + SFR-non-interfering module is complete and + accurate. + + The description of the purpose of a module indicates + what function the module is fulfilling. From the + description, the evaluator should be able to obtain a + general idea of the module's role. In order to assure + the description is complete, the evaluator uses the + information provided about the module's interactions + with other modules to assess whether the reasons for the + module being called are consistent with the module's + purpose. If the interaction description contains + functionality that is not apparent from, or in conflict + with, the module's purpose, the evaluator needs to + determine whether the problem is one of accuracy or of + completeness. The evaluator should be wary of purposes + that are too short, since meaningful analysis based on a + one-sentence purpose is likely to be impossible. + + Because the modules are at such a low level, it may be difficult + determine completeness and accuracy impacts from other + documentation, such as operational user guidance, the functional + specification, the security architecture description, or the TSF + internals document. However, the evaluator uses the information + present in those documents to the extent possible to help ensure + that the function is accurately and completely described. This + analysis can be aided by the analysis performed for the work + units for the element, + which maps the TSFI in the functional specification to the + modules of the TSF. + + + + + The evaluator shall examine the TOE design to determine + that the description of a SFR-non-interfering module's + interaction with other modules is complete and + accurate. + + It is important to note that, in terms of the Part 3 + requirement and this work unit, the term + interaction is intended to convey less + rigour than interface. An interaction + does not need to be characterised at the implementation + level (e.g., parameters passed from one routine in a + module to a routine in a different module; global + variables; hardware signals (e.g., interrupts) from a + hardware subsystem to an interrupt-handling subsystem), + but the data elements identified for a particular module + that are going to be used by another module should be + covered in this discussion. Any control relationships + between modules (e.g., a module responsible for + configuring a rule base for a firewall system and the + module that actually implements these rules) should also + be described. + + A module's interaction with other modules can be captured in + many ways. The intent for the TOE design is to allow the + evaluator to understand (in part through analysis of module + interactions) the role of the SFR-supporting and + SFR-non-interfering modules in the overall TOE + design. Understanding of this role will aid the evaluator in + performing work unit . + + A module's interaction with other modules goes beyond + just a call-tree-type document. The interaction is + described from a functional perspective of why a module + interacts with other modules. The module's purpose + describes what functions the module provides to other + modules; the interactions should describe what the + module depends on from other modules in order to + accomplish this function. + + Because the modules are at such a low level, it may be difficult + determine completeness and accuracy impacts from other + documentation, such as operational user guidance, the functional + specification, the security architecture description, or the TSF + internals document. However, the evaluator uses the information + present in those documents to the extent possible to help ensure + that the interactions are accurately and completely + described. + + + + + The evaluator shall examine the TOE design to determine + that it contains a complete and accurate mapping from + the TSFI described in the functional specification to + the modules of the TSF described in the TOE + design. + + The modules described in the TOE design provide a + description of the implementation of the TSF. The TSFI + provide a description of how the implementation is + exercised. The evidence from the developer identifies + the module that is initially invoked when an operation + is requested at the TSFI, and identify the chain of + modules invoked up to the module that is primarily + responsible for implementing the functionality. However, + a complete call tree for each TSFI is not required for + this work unit. The cases in which more than one module + would have to be identified are where there are ``entry + point'' modules or wrapper modules that have no + functionality other than conditioning inputs or + de-multiplexing an input. Mapping to one of these + modules would not provide any useful information to the + evaluator. + + The evaluator assesses the completeness of the mapping + by ensuring that all of the TSFI map to at least one + module. The verification of accuracy is more + complex. + + The first aspect of accuracy is that each TSFI is mapped + to a module at the TSF boundary. This determination can + be made by reviewing the module description and its + interfaces/interactions. The next aspect of accuracy is + that each TSFI identifies a chain of modules between the + initial module identified and a module that is primarily + responsible for implementing the function presented at + the TSF. Note that this may be the initial module, or + there may be several modules, depending on how much + pre-conditioning of the inputs is done. It should be + noted that one indicator of a pre-conditioning module is + that it is invoked for a large number of the TSFI, where + the TSFI are all of similar type (e.g., system + call). The final aspect of accuracy is that the mapping + makes sense. For instance, mapping a TSFI dealing with + access control to a module that checks passwords is not + accurate. The evaluator should again use judgement in + making this determination. The goal is that this + information aids the evaluator in understanding the + system and implementation of the SFRs, and ways in which + entities at the TSF boundary can interact with the + TSF. The bulk of the assessment of whether the SFRs are + described accurately by the modules is performed in + other work units. + + + + The evaluator shall determine that the design is an accurate + and complete instantiation of all security functional + requirements. + + + The evaluator shall examine the TOE security functional + requirements and the TOE design, to determine that all + ST security functional requirements are covered by the + TOE design. + + The evaluator may construct a map between the TOE + security functional requirements and the TOE design. + This map will likely be from a functional requirement to + a set of subsystems, and later to modules. Note that this map may have to be + at a level of detail below the component or even element + level of the requirements, because of operations + (assignments, refinements, selections) performed on the + functional requirement by the ST author. + + For example, the + component contains an element with assignments. If the + ST contained, for instance, ten rules in the assignment, and these ten + rules were implemented in specific places within fifteen + modules, it would be inadequate for the evaluator to map + to one subsystem and + claim the work unit had been completed. Instead, the + evaluator would map + (rule 1) to modules x, y and z of subsystem A; + (rule 2) to x, p, and q of subsystem A; etc. + + + + The evaluator shall examine the TOE design to determine + that it is an accurate instantiation of all security + functional requirements. + + The evaluator may construct a map between the TOE security + functional requirements and the TOE design. This map will + likely be from a functional requirement to a set of + subsystems. Note that this map may have to be at a level of + detail below the component or even element level of the + requirements, because of operations (assignments, refinements, + selections) performed on the functional requirement by the ST + author. + + As an example, if the ST requirements specified a + role-based access control mechanism, the evaluator would + first identify the subsystems, and modules that contribute to this + mechanism's implementation. This could be done by + in-depth knowledge or understanding of the TOE design or + by work done in the previous work unit. Note that this + trace is only to identify the subsystems, and modules, and is not the + complete analysis. + + The next step would be to understand what mechanism the + subsystems, and modules implemented. For instance, if the design + described an implementation of access control based on + UNIX-style protection bits, the design would not be an + accurate instantiation of those access control + requirements present in the ST example used above. If + the evaluator could not determine that the mechanism was + accurately implemented because of a lack of detail, the + evaluator would have to assess whether all of the + SFR-enforcing subsystems and modules have been identified, or if + adequate detail had been provided for those subsystems and modules. + + + + + + + + + The objective of this sub-activity is to determine whether + the TOE design provides a description of the TOE in terms + of subsystems sufficient to determine the TSF boundary, + and provides a description of the TSF internals in terms + of modules (and optionally higher-level abstractions). It + provides a detailed description of all modules for the + evaluator to determine that the SFRs are completely and + accurately implemented; as such, the TOE design provides + an explanation of the implementation + representation. + + + + At this level, there is no differentiation of required + information according to SFR-relevance. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the functional specification; + + + security architecture description; + + + the TOE design; + + + the security architecture description; + + + the implementation representation. + + + + + The developer shall provide the design of the TOE. + + + The developer shall provide a mapping from the TSFI of the + functional specification to the lowest level of + decomposition available in the TOE design. + + + The design shall describe the structure of the TOE in terms + of subsystems. + + + The design shall describe the TSF in terms of modules, + designating each module as SFR-enforcing, + SFR-supporting, or SFR-non-interfering. + + + The design shall identify all subsystems of the TSF. + + + The design shall provide a semiformal description of each + subsystem of the TSF, supported by informal, explanatory text where + appropriate. + + + The design shall provide a description of the interactions among all subsystems of the TSF. + + + The design shall provide a mapping from the subsystems of + the TSF to the modules of the TSF. + + + The design shall provide a semiformal description of each module + in terms of its purpose, interaction, interfaces, return values + from those interfaces, and called interfaces to other modules, + supported by informal, explanatory text where appropriate. + + + The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + The evaluator shall determine that the design is an accurate + and complete instantiation of all security functional + requirements. + + + + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the functional specification; + + + security architecture description; + + + the TOE design; + + + the security architecture description; + + + the implementation representation. + + + + + The developer shall provide the design of the TOE. + + + The developer shall provide a mapping from the TSFI of the + functional specification to the lowest level of + decomposition available in the TOE design. + + + The developer shall provide a formal specification of the + TSF subsystems. + + + The developer shall provide a proof of correspondence + between the formal specifications of the TSF subsystems and + of the functional specification. + + + The design shall describe the structure of the TOE in terms + of subsystems. + + + The design shall describe the TSF in terms of modules, + designating each module as SFR-enforcing, + SFR-supporting, or SFR-non-interfering. + + + The design shall identify all subsystems of the TSF. + + + The design shall provide a semiformal description of each + subsystem of the TSF, supported by informal, explanatory text where + appropriate. + + + The design shall provide a description of the interactions among all subsystems of the TSF. + + + The design shall provide a mapping from the subsystems of + the TSF to the modules of the TSF. + + + The design shall describe each module in semiformal style in terms + of its purpose, interaction, interfaces, return values from those interfaces, + and called interfaces to other modules, supported by informal, explanatory + text where appropriate. + + + The formal specification of the TSF subsystems shall + describe the TSF using a formal style, supported by + informal, explanatory text where appropriate. + + + The mapping shall demonstrate that all TSFIs trace to the behaviour described in the TOE design that they invoke. + + + The proof of correspondence between the formal + specifications of the TSF subsystems and of the functional + specification shall demonstrate that all behaviour described + in the TOE design is a correct and complete refinement of + the TSFI that invoked it. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + The evaluator shall determine that the design is an accurate + and complete instantiation of all security functional + requirements. + + + + + + + The guidance documents class provides the requirements for + guidance documentation for all user roles. For the secure + preparation and operation of the TOE it is necessary to + describe all relevant aspects for the secure handling of the + TOE. The class also addresses the possibility of unintended + incorrect configuration or handling of the TOE. + + In many cases it may be appropriate that guidance is provided + in separate documents for preparation and operation of the + TOE, or even separate for different user roles as end-users, + administrators, application programmers using software or + hardware interfaces, etc. + + The guidance documents class is subdivided into two families + which are concerned with the preparative user guidance (what + has to be done to transform the delivered TOE into its + evaluated configuration in the operational environment as + described in the ST) and with the operational user guidance + (what has to be done during the operation of the TOE in its + evaluated configuration). + + + + Assurance class defines + requirements directed at the understandability, coverage and + completeness of the preparative and operational documentation + provided by the developer. This documentation, which provides + information for all user roles, is an important factor in the + secure preparation and operation of the TOE. + + + + The purpose of the guidance document activity is to judge the + adequacy of the documentation describing how the user can + handle the TOE in a secure manner. Such documentation should + take into account the various types of users (e.g. those who + accept, install, administrate or operate the TOE) whose + incorrect actions could adversely affect the security of the + TOE or of their own data. + + The guidance documents class is subdivided into two families + which are concerned firstly with the preparative procedures + (all that has to be done to transform the delivered TOE into + its evaluated configuration in the environment as described in + the ST, i.e. accepting and installing the TOE) and secondly + with the operational user guidance (all that has to be done + during the operation of the TOE in its evaluated + configuration, i.e. operation and administration). + + + + The guidance documents activity applies to those functions and + interfaces which are related to the security of the TOE. The + secure configuration of the TOE is described in the ST. + + + + + Operational user guidance refers to written material that is + intended to be used by all types of users of the TOE in its + evaluated configuration: end-users, persons responsible for + maintaining and administering the TOE in a correct manner + for maximum security, and by others (e.g. programmers) using + the TOE's external interfaces. Operational user guidance + describes the security functionality provided by the TSF, + provides instructions and guidelines (including warnings), + helps to understand the TSF and includes the + security-critical information, and the security-critical + actions required, for its secure use. Misleading and + unreasonable guidance should be absent from the guidance + documentation, and secure procedures for all modes of + operation should be addressed. Insecure states should be + easy to detect. + + The operational user guidance provides a measure of + confidence that non-malicious users, administrators, + application providers and others exercising the external + interfaces of the TOE will understand the secure operation + of the TOE and will use it as intended. The evaluation of + the user guidance includes investigating whether the TOE can + be used in a manner that is insecure but that the user of + the TOE would reasonably believe to be secure. The objective + is to minimise the risk of human or other errors in + operation that may deactivate, disable, or fail to activate + security functionality, resulting in an undetected insecure + state. + + + + Requirements for operational user guidance help ensure that + all types of users are able to operate the TOE in a secure + manner (e.g. the usage constraints assumed by the PP or ST + must be clearly explained and illustrated). It should be + excluded that the TOE can be used in a manner that is + insecure but that the user of the TOE would reasonably + believe to be secure. Operational user guidance is the + primary vehicle available to the developer for providing the + TOE users with the necessary background and specific + information on how to correctly use the TOE's protection + functions. + + Operational user guidance must do two things. First, it + needs to explain what the security functionality accessible + by the user does and how it is to be used, so that users are + able to consistently and effectively protect their + information. Second, it needs to explain the user's role in + maintaining the TOE's security. + + + + This family contains only one component. + + + + There may be different user roles or groups that are + recognised by the TOE and that can interact with the + TSF. These user roles and groups should be taken into + consideration by the operational user guidance. They may be + roughly grouped into administrators and non-administrative + users, or more specifically grouped into persons responsible + for receiving, accepting, installing and maintaining the + TOE, application programmers, revisors, auditors, + daily-management, end-users. Each role can encompass an + extensive set of capabilities, or can be a single + one. + + The requirement + encompasses the aspect that any warnings to the users during + operation of a TOE with regard to the security problem + definition and the security objectives for the operational + environment described in the PP/ST are appropriately covered + in the user guidance. + + The concept of secure values, as employed in , has relevance where a user + has control over security parameters. Guidance needs to be + provided on secure and insecure settings for such + parameters. + + requires that the + user guidance describes the appropriate reactions to all + security-relevant events. Although many security-relevant + events are the result of performing functions, this need not + always be the case (e.g. the audit log fills up, an + intrusion is detected). Furthermore, a security-relevant + event may happen as a result of a specific chain of + functions or, conversely, several security-relevant events + may be triggered by one function. + + requires that the + user guidance is clear and reasonable. Misleading or + unreasonable guidance may result in a user of the TOE + believing that the TOE is secure when it is not. + + An example of misleading guidance would be the description + of a single guidance instruction that could be parsed in + more than one way, one of which may result in an insecure + state. + + An example of unreasonable guidance would be a + recommendation to follow a procedure that is so complicated + that it cannot reasonably be expected that users will follow + this guidance. + + + + + + The objectives of this sub-activity are to determine + whether the user guidance describes for each user role the + security functionality and interfaces provided by the TSF, + provides instructions and guidelines for the secure use of + the TOE, addresses secure procedures for all modes of + operation, facilitates prevention and detection of + insecure TOE states, or whether it is misleading or + unreasonable. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the functional specification; + + + the TOE design, if applicable; + + + the user guidance; + + + + + The developer shall provide operational user guidance. + + + The operational user guidance shall describe, for each user + role, the user-accessible functions and privileges that + should be controlled in a secure processing environment, + including appropriate warnings. + + + The operational user guidance shall describe, for each user + role, how to use the available interfaces provided by the + TOE in a secure manner. + + + The operational user guidance shall describe, for each user + role, the available functions and interfaces, in particular + all security parameters under the control of the user, + indicating secure values as appropriate. + + + The operational user guidance shall, for each user role, + clearly present each type of security-relevant event + relative to the user-accessible functions that need to be + performed, including changing the security characteristics + of entities under the control of the TSF. + + + The operational user guidance shall identify all possible + modes of operation of the TOE (including operation following + failure or operational error), their consequences and + implications for maintaining secure operation. + + + The operational user guidance shall, for each user role, + describe the security measures to be followed in order to + fulfil the security objectives for the operational + environment as described in the ST. + + + The operational user guidance shall be clear and reasonable. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the operational user + guidance to determine that it describes, for each user + role, the user-accessible functions and privileges that + should be controlled in a secure processing environment, + including appropriate warnings. + + The configuration of the TOE may allow different user + roles to have dissimilar privileges in making use of the + different functions of the TOE. This means that some + users are authorised to perform certain functions, while + other users may not be so authorised. These functions + and privileges should be described, for each user role, + by the user guidance. + + The user guidance identifies, for each user role, the + functions and privileges that must be controlled, the + types of commands required for them, and the reasons for + such commands. The user guidance should contain warnings + regarding the use of these functions and + privileges. Warnings should address expected effects, + possible side effects, and possible interactions with + other functions and privileges. + + + + + The evaluator shall examine the operational user + guidance to determine that it describes, for each user + role, the secure use of the available interfaces + provided by the TOE. + + The user guidance should provide advice regarding + effective use of the TSF (e.g. reviewing password + composition practises, suggested frequency of user file + backups, discussion on the effects of changing user + access privileges). + + + + + The evaluator shall examine the operational user + guidance to determine that it describes, for each user + role, the available security functionality and + interfaces, in particular all security parameters under + the control of the user, indicating secure values as + appropriate. + + The user guidance should contain an overview of the + security functionality that is visible at the user + interfaces. + + The user guidance should identify and describe the + purpose, behaviour, and interrelationships of the + security interfaces and functionality. + + For each user-accessible interface, the user guidance + should: + + + describe the method(s) by which the interface is + invoked (e.g. command-line, programming-language + system call, menu selection, command button); + + + describe the parameters to be set by the user, their + particular purposes, valid and default values, and + secure and insecure use settings of such parameters, + both individually or in combination; + + + describe the immediate TSF response, message, or + code returned. + + + + The evaluator should consider the functional + specification and the ST to determine that the TSF + described in these documents is consistent to the + operational user guidance. The evaluator has to ensure + that the operational user guidance is complete to allow + the secure use through the TSFI available to all types + of human users. The evaluator may, as an aid, prepare an + informal mapping between the guidance and these + documents. Any omissions in this mapping may indicate + incompleteness. + + + + + The evaluator shall examine the operational user + guidance to determine that it describes, for each user + role, each type of security-relevant event relative to + the user functions that need to be performed, including + changing the security characteristics of entities under + the control of the TSF and operation following failure + or operational error. + + All types of security-relevant events are detailed for + each user role, such that each user knows what events + may occur and what action (if any) he may have to take + in order to maintain security. Security-relevant events + that may occur during operation of the TOE (e.g. audit + trail overflow, system crash, updates to user records, + such as when a user account is removed when the user + leaves the organisation) are adequately defined to allow + user intervention to maintain secure operation. + + + + + The evaluator shall examine the operational user + guidance and other evaluation evidence to determine that + the guidance identifies all possible modes of operation + of the TOE (including, if applicable, operation + following failure or operational error), their + consequences and implications for maintaining secure + operation. + + Other evaluation evidence, particularly the functional + specification, provide an information source that the + evaluator should use to determine that the guidance + contains sufficient guidance information. + + If test documentation is included in the assurance + package, then the information provided in this evidence + can also be used to determine that the guidance contains + sufficient guidance documentation. The detail provided + in the test steps can be used to confirm that the + guidance provided is sufficient for the use and + administration of the TOE. + + The evaluator should focus on a single human visible + TSFI at a time, comparing the guidance for securely + using the TSFI with other evaluation evidence, to + determine that the guidance related to the TSFI is + sufficient for the secure usage (i.e. consistent with + the SFRs) of that TSFI. The evaluator should also + consider the relationships between interfaces, searching + for potential conflicts. + + + + + The evaluator shall examine the operational user + guidance to determine that it describes, for each user + role, the security measures to be followed in order to + fulfil the security objectives for the operational + environment as described in the ST. + + The evaluator analyses the security objectives for the + operational environment in the ST and determines that + for each user role, the relevant security measures are + described appropriately in the user guidance. + + The security measures described in the user guidance + should include all relevant external procedural, + physical, personnel and connectivity measures. + + Note that those measures relevant for secure + installation of the TOE are examined in . + + + + + The evaluator shall examine the operational user + guidance to determine that it is clear. + + The guidance is unclear if it can reasonably be + misconstrued by an administrator or user, and used in a + way detrimental to the TOE, or to the security provided + by the TOE. + + + + + The evaluator shall examine the operational user + guidance to determine that it is reasonable. + + The guidance is unreasonable if it makes demands on the + TOE's usage or operational environment that are + inconsistent with the ST or unduly onerous to maintain + security. + + + + + + + + Preparative procedures are useful for ensuring that the TOE + has been received and installed in a secure manner as + intended by the developer. The requirements for preparation + call for a secure transition from the delivered TOE to its + initial operational environment. This includes investigating + whether the TOE can be configured or installed in a manner + that is insecure but that the user of the TOE would + reasonably believe to be secure. + + + + Preparation requires that the delivered copy of the TOE is + accepted, configured and activated by the user to exhibit + the protection properties as needed during operation of the + TOE. The preparative procedures provide confidence that the + user will be aware of the TOE configuration parameters and + how they can affect the TSF. + + + + This family contains only one component. + + + + It is recognised that the application of these requirements + will vary depending on aspects such as whether the TOE is + delivered in an operational state, or whether it has to be + installed at the TOE owner's site, etc. + + The first process covered by the preparative procedures is + the consumer's secure acceptance of the received TOE in + accordance with the developer's delivery procedures. If the + developer has not defined delivery procedures, security of + the acceptance has to be ensured otherwise. + + Installation of the TOE includes transforming its + operational environment into a state that conforms to the + security objectives for the operational environment provided + in the ST. + + It might also be the case that no installation is necessary, + for example a smart card. In this case it may be + inappropriate to require and analyse installation + procedures. + + The requirements in this assurance family are presented + separately from those in the family, due to the infrequent, possibly + one-time use of the preparative procedures. + + + + + The objective of this sub-activity is to determine whether + the procedures and steps for the secure preparation of the + TOE have been documented and result in a secure + configuration. + + + + The preparative procedures refer to all acceptance and + installation procedures, that are necessary to progress + the TOE to the secure configuration as described in the + ST. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the TOE including its preparative procedures; + + + the description of developer's delivery procedures, if + applicable; + + + + + The developer shall provide the TOE including its + preparative procedures. + + The preparative procedures + shall describe all the steps necessary for secure acceptance + of the delivered TOE in accordance with the developer's + delivery procedures. + + The preparative procedures + shall describe all the steps necessary for secure + installation of the TOE and for the secure preparation of + the operational environment in accordance with the security + objectives for the operational environment as described in + the ST. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + + The evaluator shall examine the provided acceptance + procedures to determine that they describe the steps + necessary for secure acceptance of the TOE in accordance + with the developer's delivery procedures. + If it is not anticipated by the developer's delivery + procedures that acceptance procedures will or can be + applied, this work unit is not applicable, and is + therefore considered to be satisfied. + + The acceptance procedures should include as a minimum, + that the user has to check that all parts of the TOE as + indicated in the ST have been delivered in the correct + version. + + The acceptance procedures should reflect the steps the + user has to perform in order to accept the delivered TOE + that are implied by the developer's delivery + procedures. + + The acceptance procedures should provide detailed + information about the following, if applicable: + + + making sure that the delivered TOE is the complete + evaluated instance; + + + detecting modification/masquerading of the delivered + TOE. + + + + + + + + The evaluator shall examine the provided installation + procedures to determine that they describe the steps + necessary for secure installation of the TOE and the + secure preparation of the operational environment in + accordance with the security objectives in the + ST. + + If it is not anticipated that installation procedures + will or can be applied (e.g. because the TOE may already + be delivered in an operational state), this work unit is + not applicable, and is therefore considered to be + satisfied. + + The installation procedures should provide detailed + information about the following, if applicable: + + + minimum system requirements for secure installation; + + + requirements for the operational environment in + accordance with the security objectives provided by + the ST; + + the steps the user has to perform in order to get to an + operational TOE being commensurate with its evaluated + configuration. Such a description shall include - for each step + - a clear scheme for the decision on the next step depended on + success, failure or problems at the current step; + + + changing the installation specific security + characteristics of entities under the control of the + TSF (for example parameters, settings, passwords); + + + handling exceptions and problems. + + + + + + The evaluator shall apply the preparative procedures to + confirm that the TOE can be prepared securely for operation. + + + The evaluator shall perform all user procedures + necessary to prepare the TOE to determine that the TOE + and its operational environment can be prepared securely + using only the supplied preparative procedures. + Preparation requires the evaluator to advance the + TOE from a deliverable state to the state in which it is + operational, including acceptance and installation of + the TOE, and enforcing the SFRs consistent with the + security objectives for the TOE specified in the + ST. + + The evaluator should follow only the developer's + procedures and may perform the activities that customers + are usually expected to perform to accept and install + the TOE, using the supplied preparative procedures only. + Any difficulties encountered during such an exercise may + be indicative of incomplete, unclear or unreasonable guidance. + + This work unit may be performed in conjunction with the + evaluation activities under . + + If it is known that the TOE will be used as a dependent + component for a composed TOE evaluation, then the + evaluator should ensure that the operational environment + is satisfied by the base component used in the composed + TOE. + + + + + + + + + Life-cycle support is an aspect of establishing discipline and + control in the processes of refinement of the TOE during its + development and maintenance. Confidence in the correspondence + between the TOE security requirements and the TOE is greater + if security analysis and the production of the evidence are + done on a regular basis as an integral part of the development + and maintenance activities. + + In the product life-cycle it is distinguished whether the TOE + is under the responsibility of the developer or the user + rather than whether it is located in the development or user + environment. The point of transition is the moment where the + TOE is handed over to the user. This is also the point of + transition from the to the class. + + The class consists of seven + families. is the high-level + description of the TOE life-cycle; a more detailed description of the management + of the configuration items. + requires a minimum set of configuration items to be managed in + the defined way. is + concerned with the developer's physical, procedural, + personnel, and other security measures; with the development tools and implementation + standards used by the developer; with the handling of security flaws. defines the procedures used for + the delivery of the TOE to the consumer. Delivery processes + occurring during the development of the TOE are denoted rather + as transportations, and are handled in the context of + integration and acceptance procedures in other families of + this class. + + Throughout this class, development and related terms + (developer, develop) are meant in the more general sense to + comprise development and production, whereas + production specifically means the process of transforming the + implementation representation into the final TOE. + + + + Assurance class defines + requirements for assurance through the adoption of a well + defined life-cycle model for all the steps of the TOE + development, including flaw remediation procedures and + policies, correct use of tools and techniques and the security + measures used to protect the development environment. + + Configuration management (CM) helps to ensure that the + integrity of the TOE is preserved, by preventing unauthorised + modifications, additions, or deletions to the TOE, thus + providing assurance that the TOE and documentation used for + evaluation are the ones prepared for distribution. + + The delivery procedures define requirements for the measures, + procedures, and standards concerned with secure delivery of + the TOE, ensuring that the security protection offered by the + TOE is not compromised during the transfer to the user. + + + + The purpose of the life-cycle support activity is to determine + the adequacy of the security procedures that the developer + uses during the development and maintenance of the TOE. These + procedures include the life-cycle model used by the developer, + the configuration management, the security measures used + throughout TOE development, the tools used by the developer + throughout the life-cycle of the TOE, the handling of security + flaws, and the delivery activity. + + Poorly controlled development and maintenance of the TOE can + result in vulnerabilities in the implementation. Conformance + to a defined life-cycle model can help to improve controls in + this area. A measurable life-cycle model used for the TOE can + remove ambiguity in assessing the development progress of the + TOE. + + The purpose of the configuration management activity is to + assist the consumer in identifying the evaluated TOE, to + ensure that configuration items are uniquely identified, and + the adequacy of the procedures that are used by the developer + to control and track changes that are made to the TOE. This + includes details on what changes are tracked, how potential + changes are incorporated, and the degree to which automation + is used to reduce the scope for error. + + Developer security procedures are intended to protect the TOE + and its associated design information from interference or + disclosure. Interference in the development process may allow + the deliberate introduction of vulnerabilities. Disclosure of + design information may allow vulnerabilities to be more easily + exploited. The adequacy of the procedures will depend on the + nature of the TOE and the development process. + + The use of well-defined development tools and the application + of implementation standards by the developer and by third + parties involved in the development process help to ensure + that vulnerabilities are not inadvertently introduced during + refinement. + + The flaw remediation activity is intended to track security + flaws, to identify corrective actions, and to distribute the + corrective action information to TOE users. + + The purpose of the delivery activity is to judge the adequacy + of the documentation of the procedures used to ensure that the + TOE is delivered to the consumer without modification. + + + + + Configuration management (CM) is one means for increasing + assurance that the TOE meets the SFRs. CM establishes this + by requiring discipline and control in the processes of + refinement and modification of the TOE and the related + information. CM systems are put in place to ensure the + integrity of the portions of the TOE that they control, by + providing a method of tracking any changes, and by ensuring + that all changes are authorised. + + The objective of this family is to require the developer's + CM system to have certain capabilities. These are meant to + reduce the likelihood that accidental or unauthorised + modifications of the configuration items will occur. The CM + system should ensure the integrity of the TOE from the early + design stages through all subsequent maintenance + efforts. + + The objective of introducing automated CM tools is to + increase the effectiveness of the CM system. While both + automated and manual CM systems can be bypassed, ignored, or + proven insufficient to prevent unauthorised modification, + automated systems are less susceptible to human error or + negligence. + + The objectives of this family include the following: + + + ensuring that the TOE is correct and complete before it + is sent to the consumer; + + + ensuring that no configuration items are missed during + evaluation; + + + preventing unauthorised modification, addition, or + deletion of TOE configuration items. + + + + + + Configuration management capabilities define the + characteristics of the configuration management + system. + + + + The components in this family are levelled on the basis of + the CM system capabilities, the scope of the CM + documentation and the evidence provided by the + developer. + + + + While it is desired that CM be applied from the early design + stages and continue into the future, this family requires + that CM be in place and in use prior to the end of the + evaluation. + + In the case where the TOE is a subset of a product, the + requirements of this family apply only to the TOE + configuration items, not to the product as a whole. + + For developers that have separate CM systems for different + life-cycle phases (for example development, production + and/or the final product), it is required to document all of + them. For evaluation purposes, the separate CM systems + should be regarded as parts of an overall CM system which is + addressed in the criteria. + + Similarly, if parts of the TOE are produced by different + developers or at different sites, the CM systems being in + use at the different places should be regarded as parts of + an overall CM system which is addressed in the criteria. In + this situation, integration aspects have also to be taken + into account. + + Several elements of this family refer to configuration + items. These elements identify CM requirements to be imposed + on all items identified in the configuration list, but leave + the contents of the list to the discretion of the + developer. can be used to + narrow this discretion by identifying specific items that + must be included in the configuration list, and hence + covered by CM. + + introduces a + requirement that the CM system uniquely identify all + configuration items. This also requires that modifications + to configuration items result in a new, unique identifier + being assigned to the configuration item. + + introduces the + requirement that the evidence shall demonstrate that the CM + system operates in accordance with the CM plan. Examples of + such evidence might be documentation such as screen + snapshots or audit trail output from the CM system, or a + detailed demonstration of the CM system by the + developer. The evaluator is responsible for determining that + this evidence is sufficient to show that the CM system + operates in accordance with the CM plan. + + introduces a + requirement that the CM system provide an automated means to + support the production of the TOE. This requires that the CM + system provide an automated means to assist in determining + that the correct configuration items are used in generating + the TOE. + + introduces a + requirement that the CM system provide an automated means to + ascertain the changes between the TOE and its preceding + version. If no previous version of the TOE exists, the + developer still needs to provide an automated means to + ascertain the changes between the TOE and a future version + of the TOE. + + + + + + A unique reference is required to ensure that there is no + ambiguity in terms of which instance of the TOE is being + evaluated. Labelling the TOE with its reference ensures + that users of the TOE can be aware of which instance of + the TOE they are using. + + + + The objectives of this sub-activity are to determine + whether the developer has clearly identified the + TOE. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the TOE suitable for testing. + + + + + The developer shall provide the TOE and a reference for the + TOE. + + + The TOE shall be labelled with its unique reference. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the TOE provided for + evaluation is labelled with its reference. + + The evaluator should ensure that the TOE contains the + unique reference which is stated in the ST. This could + be achieved through labelled packaging or media, or by a + label displayed by the operational TOE. This is to + ensure that it would be possible for consumers to + identify the TOE (e.g. at the point of purchase or + use). + + The TOE may provide a method by which it can be easily + identified. For example, a software TOE may display its + name and version number during the start up routine, or + in response to a command line entry. A hardware or + firmware TOE may be identified by a part number + physically stamped on the TOE. + + Alternatively, the unique reference provided for the TOE + may be the combination of the unique reference of each + component from which the TOE is comprised (e.g. in the + case of a composed TOE). + + + + The evaluator shall check that the TOE references used + are consistent. + + If the TOE is labelled more than once then the labels + have to be consistent. For example, it should be + possible to relate any labelled guidance documentation + supplied as part of the TOE to the evaluated operational + TOE. This ensures that consumers can be confident that + they have purchased the evaluated version of the TOE, + that they have installed this version, and that they + have the correct version of the guidance to operate the + TOE in accordance with its ST. + + The evaluator also verifies that the TOE reference is + consistent with the ST. + + If this work unit is applied to a composed TOE, the + following will apply. The composed IT TOE will not be + labelled with its unique (composite) reference, but only + the individual components will be labelled with their + appropriate TOE reference. It would require further + development for the IT TOE to be labelled, i.e. during + start-up and/or operation, with the composite reference. + If the composed TOE is delivered as the constituent + component TOEs, then the TOE items delivered will not + contain the composite reference. However, the composed + TOE ST will include the unique reference for the + composed TOE and will identify the components comprising + the composed TOE through which the consumers will be + able to determine whether they have the appropriate + items. + + + + + + + + + A unique reference is required to ensure that there is no + ambiguity in terms of which instance of the TOE is being + evaluated. Labelling the TOE with its reference ensures + that users of the TOE can be aware of which instance of + the TOE they are using. + + Unique identification of the configuration items leads to + a clearer understanding of the composition of the TOE, + which in turn helps to determine those items which are + subject to the evaluation requirements for the TOE. + + The use of a CM system increases assurance that the + configuration items are maintained in a controlled + manner. + + + + The objectives of this sub-activity are to determine + whether the developer uses a CM system that uniquely + identifies all configuration items. + + + + This component contains an implicit evaluator action to + determine that the CM system is being used. As the + requirements here are limited to identification of the TOE + and provision of a configuration list, this action is + already covered by, and limited to, the existing work + units. At the + requirements are expanded beyond these two items, and more + explicit evidence of operation is required. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the TOE suitable for testing; + + + the configuration management documentation. + + + + + The developer shall provide the TOE and a reference for the + TOE. + + + The developer shall provide the CM documentation. + + + The developer shall use a CM system. + + + The TOE shall be labelled with its unique reference. + + + The CM documentation shall describe the method used to + uniquely identify the configuration items. + + + The CM system shall uniquely identify all configuration + items. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the TOE provided for + evaluation is labelled with its reference. + + The evaluator should ensure that the TOE contains the + unique reference which is stated in the ST. This could + be achieved through labelled packaging or media, or by a + label displayed by the operational TOE. This is to + ensure that it would be possible for consumers to + identify the TOE (e.g. at the point of purchase or + use). + + The TOE may provide a method by which it can be easily + identified. For example, a software TOE may display its + name and version number during the start up routine, or + in response to a command line entry. A hardware or + firmware TOE may be identified by a part number + physically stamped on the TOE. + + Alternatively, the unique reference provided for the TOE + may be the combination of the unique reference of each + component from which the TOE is comprised (e.g. in the + case of a composed TOE). + + + + The evaluator shall check that the TOE references used + are consistent. + + If the TOE is labelled more than once then the labels + have to be consistent. For example, it should be + possible to relate any labelled guidance documentation + supplied as part of the TOE to the evaluated operational + TOE. This ensures that consumers can be confident that + they have purchased the evaluated version of the TOE, + that they have installed this version, and that they + have the correct version of the guidance to operate the + TOE in accordance with its ST. + + The evaluator also verifies that the TOE reference is + consistent with the ST. + + If this work unit is applied to a composed TOE, the + following will apply. The composed IT TOE will not be + labelled with its unique (composite) reference, but only + the individual components will be labelled with their + appropriate TOE reference. It would require further + development for the IT TOE to be labelled, i.e. during + start-up and/or operation, with the composite reference. + If the composed TOE is delivered as the constituent + component TOEs, then the TOE items delivered will not + contain the composite reference. However, the composed + TOE ST will include the unique reference for the + composed TOE and will identify the components comprising + the composed TOE through which the consumers will be + able to determine whether they have the appropriate + items. + + + + + The evaluator shall examine the method of identifying + configuration items to determine that it describes how + configuration items are uniquely identified. + + Procedures should describe how the status of each + configuration item can be tracked throughout the + life-cycle of the TOE. The procedures may be detailed in + the CM plan or throughout the CM documentation. The + information included should describe: + + + the method how each configuration item is uniquely + identified, such that it is possible to track + versions of the same configuration item; + + the method how configuration items are assigned + unique identifiers and how they are entered into the + CM system; + + the method to be used to identify superseded + versions of a configuration item. + + + + + + The evaluator shall examine the configuration items to + determine that they are identified in a way that is + consistent with the CM documentation. + Assurance that the CM system uniquely identifies + all configuration items is gained by examining the + identifiers for the configuration items. For both + configuration items that comprise the TOE, and drafts of + configuration items that are submitted by the developer + as evaluation evidence, the evaluator confirms that each + configuration item possesses a unique identifier in a + manner consistent with the unique identification method + that is described in the CM documentation. + + + + + + + + + + A unique reference is required to ensure that there is no + ambiguity in terms of which instance of the TOE is being + evaluated. Labelling the TOE with its reference ensures + that users of the TOE can be aware of which instance of + the TOE they are using. + + Unique identification of the configuration items leads to + a clearer understanding of the composition of the TOE, + which in turn helps to determine those items which are + subject to the evaluation requirements for the TOE. + + The use of a CM system increases assurance that the + configuration items are maintained in a controlled + manner. + + Providing controls to ensure that unauthorised + modifications are not made to the TOE (``CM access + control''), and ensuring proper functionality and use of + the CM system, helps to maintain the integrity of the + TOE. + + + + The objectives of this sub-activity are to determine + whether the developer uses a CM system that uniquely + identifies all configuration items, and whether the + ability to modify these items is properly + controlled. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the TOE suitable for testing; + + + the configuration management documentation. + + + + + The developer shall provide the TOE and a reference for the + TOE. + + + The developer shall provide the CM documentation. + + + The developer shall use a CM system. + + + The TOE shall be labelled with its unique reference. + + + The CM documentation shall describe the method used to + uniquely identify the configuration items. + + + The CM system shall uniquely identify all configuration + items. + + + The CM system shall provide measures such that only + authorised changes are made to the configuration items. + + + The CM documentation shall include a CM plan. + + + The CM plan shall describe how the CM system is used for the + development of the TOE. + + + The evidence shall demonstrate that all configuration items + are being maintained under the CM system. + + + The evidence shall demonstrate that the CM system is being + operated in accordance with the CM plan. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the TOE provided for + evaluation is labelled with its reference. + + The evaluator should ensure that the TOE contains the + unique reference which is stated in the ST. This could + be achieved through labelled packaging or media, or by a + label displayed by the operational TOE. This is to + ensure that it would be possible for consumers to + identify the TOE (e.g. at the point of purchase or + use). + + The TOE may provide a method by which it can be easily + identified. For example, a software TOE may display its + name and version number during the start up routine, or + in response to a command line entry. A hardware or + firmware TOE may be identified by a part number + physically stamped on the TOE. + + Alternatively, the unique reference provided for the TOE + may be the combination of the unique reference of each + component from which the TOE is comprised (e.g. in the + case of a composed TOE). + + + + The evaluator shall check that the TOE references used + are consistent. + + If the TOE is labelled more than once then the labels + have to be consistent. For example, it should be + possible to relate any labelled guidance documentation + supplied as part of the TOE to the evaluated operational + TOE. This ensures that consumers can be confident that + they have purchased the evaluated version of the TOE, + that they have installed this version, and that they + have the correct version of the guidance to operate the + TOE in accordance with its ST. + + The evaluator also verifies that the TOE reference is + consistent with the ST. + + If this work unit is applied to a composed TOE, the + following will apply. The composed IT TOE will not be + labelled with its unique (composite) reference, but only + the individual components will be labelled with their + appropriate TOE reference. It would require further + development for the IT TOE to be labelled, i.e. during + start-up and/or operation, with the composite reference. + If the composed TOE is delivered as the constituent + component TOEs, then the TOE items delivered will not + contain the composite reference. However, the composed + TOE ST will include the unique reference for the + composed TOE and will identify the components comprising + the composed TOE through which the consumers will be + able to determine whether they have the appropriate + items. + + + + + The evaluator shall examine the method of identifying + configuration items to determine that it describes how + configuration items are uniquely identified. + + Procedures should describe how the status of each + configuration item can be tracked throughout the + life-cycle of the TOE. The procedures may be detailed in + the CM plan or throughout the CM documentation. The + information included should describe: + + + the method how each configuration item is uniquely + identified, such that it is possible to track + versions of the same configuration item; + + the method how configuration items are assigned + unique identifiers and how they are entered into the + CM system; + + the method to be used to identify superseded + versions of a configuration item. + + + + + + The evaluator shall examine the configuration items to + determine that they are identified in a way that is + consistent with the CM documentation. + + Assurance that the CM system uniquely identifies all + configuration items is gained by examining the + identifiers for the configuration items. For both + configuration items that comprise the TOE, and drafts of + configuration items that are submitted by the developer + as evaluation evidence, the evaluator confirms that each + configuration item possesses a unique identifier in a + manner consistent with the unique identification method + that is described in the CM documentation. + + + + + The evaluator shall examine the CM access control + measures described in the CM plan to determine that they + are effective in preventing unauthorised access to the + configuration items. + + The evaluator may use a number of methods to determine + that the CM access control measures are effective. For + example, the evaluator may exercise the access control + measures to ensure that the procedures could not be + bypassed. The evaluator may use the outputs generated by + the CM system procedures required by . The evaluator may also witness a + demonstration of the CM system to ensure that the access + control measures employed are operating + effectively. + + + + + The evaluator shall check that the CM documentation + provided includes a CM plan. + The CM plan needs not to be a connected document, but it is + recommended that there is a single document that describes where + the various parts of the CM plan can be found. If the CM plan is + no single document, the list in the following work unit gives + hints regarding which context is expected. + + + + + The evaluator shall examine the CM plan to determine + that it describes how the CM system is used for the + development of the TOE. + + The descriptions contained in a CM plan include, if + applicable: + + + all activities performed in the TOE development that + are subject to configuration management procedures + (e.g. creation, modification or deletion of a + configuration item, data-backup, archiving); + + + which means (e.g. CM tools, forms) have to be made + available; + + + the usage of the CM tools: the necessary details for + a user of the CM system to be able to operate the CM + tools correctly in order to maintain the integrity + of the TOE; + + + which other objects (development components, tools, + assessment environments, etc) are taken under CM + control; + + + the roles and responsibilities of individuals + required to perform operations on individual + configuration items (different roles may be + identified for different types of configuration + items (e.g. design documentation or source code)); + + + how CM instances (e.g. change control boards, + interface control working groups) are introduced and + staffed; + + + the description of the change management; + + + the procedures that are used to ensure that only + authorised individuals can make changes to + configuration items; + + + the procedures that are used to ensure that + concurrency problems do not occur as a result of + simultaneous changes to configuration items; + + + the evidence that is generated as a result of + application of the procedures. For example, for a + change to a configuration item, the CM system might + record a description of the change, accountability + for the change, identification of all configuration + items affected, status (e.g. pending or completed), + and date and time of the change. This might be + recorded in an audit trail of changes made or change + control records; + + + the approach to version control and unique + referencing of TOE versions (e.g. covering the + release of patches in operating systems, and the + subsequent detection of their application). + + + + + + + The evaluator shall check that the configuration items + identified in the configuration list are being + maintained by the CM system. + + The CM system employed by the developer should maintain the + integrity of the TOE. The evaluator should check that for each + type of configuration item (e.g. design documents or source code + modules) contained in the configuration list there are examples + of the evidence generated by the procedures described in the CM + plan. In this case, the approach to sampling will depend upon + the level of granularity used in the CM system to control CM + items. Where, for example, 10,000 source code modules are + identified in the configuration list, a different sampling + strategy needs to be applied compared to the case in which there + are only 5, or even 1. The emphasis of this activity should be + on ensuring that the CM system is being operated correctly, + rather than on the detection of any minor error. + + For guidance on sampling see . + + + + + The evaluator shall check the CM documentation to + ascertain that it includes the CM system records + identified by the CM plan. + + The output produced by the CM system should provide the + evidence that the evaluator needs to be confident that + the CM plan is being applied, and also that all + configuration items are being maintained by the CM + system as required by . Example output could include change + control forms, or configuration item access approval + forms. + + + + + The evaluator shall examine the evidence to determine + that the CM system is being operated in accordance with + the CM plan. + + The evaluator should select and examine a sample of + evidence covering each type of CM-relevant operation + that has been performed on a configuration item + (e.g. creation, modification, deletion, reversion to an + earlier version) to confirm that all operations of the + CM system have been carried out in line with documented + procedures. The evaluator confirms that the evidence + includes all the information identified for that + operation in the CM plan. Examination of the evidence + may require access to a CM tool that is used. The + evaluator may choose to sample the evidence. + + For guidance on sampling see . + + Further confidence in the correct operation of the CM system and + the effective maintenance of configuration items may be + established by means of interviews with selected development + staff. In conducting such interviews, the evaluator aims + to gain a deeper understanding of how the CM system is used in + practise as well as to confirm that the CM procedures are being + applied as described in the CM documentation. Note that such + interviews should complement rather than replace the examination + of documentary evidence, and may not be necessary if the + documentary evidence alone satisfies the requirement. However, + given the wide scope of the CM plan it is possible that some + aspects (e.g. roles and responsibilities) may not be clear from + the CM plan and records alone. This is one case where + clarification may be necessary through interviews. + + It is expected that the evaluator will visit the + development site in support of this activity. + + For guidance on site visits see . + + + + + + + + + + + A unique reference is required to ensure that there is no + ambiguity in terms of which instance of the TOE is being + evaluated. Labelling the TOE with its reference ensures + that users of the TOE can be aware of which instance of + the TOE they are using. + + Unique identification of the configuration items leads to + a clearer understanding of the composition of the TOE, + which in turn helps to determine those items which are + subject to the evaluation requirements for the TOE. + + The use of a CM system increases assurance that the + configuration items are maintained in a controlled + manner. + + Providing controls to ensure that unauthorised + modifications are not made to the TOE (``CM access + control''), and ensuring proper functionality and use of + the CM system, helps to maintain the integrity of the + TOE. + + The purpose of the acceptance procedures is to ensure that + the parts of the TOE are of adequate quality and to + confirm that any creation or modification of configuration + items is authorised. Acceptance procedures are an + essential element in integration processes and in the + life-cycle management of the TOE. + + In development environments where the configuration items + are complex, it is difficult to control changes without + the support of automated tools. In particular, these + automated tools need to be able to support the numerous + changes that occur during development and ensure that + those changes are authorised. It is an objective of this + component to ensure that the configuration items are + controlled through automated means. If the TOE is + developed by multiple developers, i.e. integration has to + take place, the use of automatic tools is adequate. + + Production support procedures help to ensure that the + generation of the TOE from a managed set of configuration + items is correctly performed in an authorised manner, + particularly in the case when different developers are + involved and integration processes have to be carried + out. + + + + The objectives of this sub-activity are to determine + whether the developer has clearly identified the TOE and + its associated configuration items, and whether the + ability to modify these items is properly controlled by + automated tools, thus making the CM system less + susceptible to human error or negligence. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the TOE suitable for testing; + + + the configuration management documentation. + + + + + The developer shall provide the TOE and a reference for the + TOE. + + + The developer shall provide the CM documentation. + + + The developer shall use a CM system. + + + The TOE shall be labelled with its unique reference. + + + The CM documentation shall describe the method used to + uniquely identify the configuration items. + + + The CM system shall uniquely identify all configuration + items. + + + The CM system shall provide automated measures such that + only authorised changes are made to the configuration items. + + + The CM system shall support the production of the TOE by + automated means. + + + The CM documentation shall include a CM plan. + + + The CM plan shall describe how the CM system is used for the + development of the TOE. + + + The CM plan shall describe the procedures used to accept + modified or newly created configuration items as part of the + TOE. + + + The evidence shall demonstrate that all configuration items + are being maintained under the CM system. + + + The evidence shall demonstrate that the CM system is being + operated in accordance with the CM plan. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the TOE provided for + evaluation is labelled with its reference. + + The evaluator should ensure that the TOE contains the + unique reference which is stated in the ST. This could + be achieved through labelled packaging or media, or by a + label displayed by the operational TOE. This is to + ensure that it would be possible for consumers to + identify the TOE (e.g. at the point of purchase or + use). + + The TOE may provide a method by which it can be easily + identified. For example, a software TOE may display its + name and version number during the start up routine, or + in response to a command line entry. A hardware or + firmware TOE may be identified by a part number + physically stamped on the TOE. + + Alternatively, the unique reference provided for the TOE + may be the combination of the unique reference of each + component from which the TOE is comprised (e.g. in the + case of a composed TOE). + + + + The evaluator shall check that the TOE references used + are consistent. + + If the TOE is labelled more than once then the labels + have to be consistent. For example, it should be + possible to relate any labelled guidance documentation + supplied as part of the TOE to the evaluated operational + TOE. This ensures that consumers can be confident that + they have purchased the evaluated version of the TOE, + that they have installed this version, and that they + have the correct version of the guidance to operate the + TOE in accordance with its ST. + + The evaluator also verifies that the TOE reference is + consistent with the ST. + + If this work unit is applied to a composed TOE, the + following will apply. The composed TOE will not be + labelled with its unique (composite) reference, but only + the individual components will be labelled with their + appropriate TOE reference. It would require further + development for the composed TOE to be labelled, i.e. during + start-up and/or operation, with the composite reference. + If the composed TOE is delivered as the constituent + component TOEs, then the TOE items delivered will not + contain the composite reference. However, the composed + TOE ST will include the unique reference for the + composed TOE and will identify the components comprising + the composed TOE through which the consumers will be + able to determine whether they have the appropriate items. + + + + + The evaluator shall examine the method of identifying + configuration items to determine that it describes how + configuration items are uniquely identified. + + Procedures should describe how the status of each + configuration item can be tracked throughout the + life-cycle of the TOE. The procedures may be detailed in + the CM plan or throughout the CM documentation. The + information included should describe: + + + the method how each configuration item is uniquely + identified, such that it is possible to track + versions of the same configuration item; + + the method how configuration items are assigned + unique identifiers and how they are entered into the + CM system; + + the method to be used to identify superseded + versions of a configuration item. + + + + + + The evaluator shall examine the configuration items to + determine that they are identified in a way that is + consistent with the CM documentation. + + Assurance that the CM system uniquely identifies all + configuration items is gained by examining the + identifiers for the configuration items. For configuration + items identified under , + the evaluator confirms that each configuration item possesses + a unique identifier in a manner consistent with the unique + identification method that is described in the CM documentation. + + + + + The evaluator shall examine the CM access control + measures described in the CM plan (cf. ) to determine that they + are automated and effective in preventing unauthorised + access to the configuration items. + + The evaluator may use a number of methods to determine + that the CM access control measures are effective. For + example, the evaluator may exercise the access control + measures to ensure that the procedures could not be + bypassed. The evaluator may use the outputs generated by + the CM system procedures required by . The evaluator may also witness a + demonstration of the CM system to ensure that the access + control measures employed are operating + effectively. + + + + + The evaluator shall check the CM plan (cf. ) for automated + procedures for supporting the production of the + TOE. + + The term ``production'' applies to those processes + adopted by the developer to progress the TOE from the + implementation representation to a state acceptable for + delivery to the end customer. + + The evaluator verifies the existence of automated + production support procedures within the CM plan. + + The following are examples for automated means + supporting the production of the TOE: + + + a ``make'' tool (as provided with many software + development tools) in the case of a software TOE; + + + a tool ensuring automatically (for example by means + of bar codes) that only parts are combined which + indeed belong together in the case of a hardware + TOE. + + + + + + + The evaluator shall examine the TOE production support + procedures to determine that they are effective in + ensuring that a TOE is generated that reflects its + implementation representation. + + The production support procedures should describe which + tools have to be used to produce the final TOE from the + implementation representation in a clearly defined + way. The conventions, directives, or other necessary + constructs are described under . + + The evaluator determines that by following the + production support procedures the correct configuration + items would be used to generate the TOE. For example, in + a software TOE this may include checking that the + automated production procedures ensure that all source + files and related libraries are included in the compiled + object code. Moreover, the procedures should ensure that + compiler options and comparable other options are + defined uniquely. For a hardware TOE, this work unit may + include checking that the automatic production + procedures ensure that the belonging parts are built + together and no parts are missing. + + The customer can then be confident that the version of + the TOE delivered for installation is derived from the + implementation representation in an unambiguous way and + implements the SFRs as described in the ST. + + The evaluator should bear in mind that the CM system + need not necessarily possess the capability to produce + the TOE, but should provide support for the process that + will help reduce the probability of human error. + + + + + The evaluator shall check that the CM documentation + provided includes a CM plan. + The CM plan does not need to be contained within a single + document, but it is recommended that there is a separate + document that describes where the various parts of the CM plan + can be found. If the CM plan is provided by a set of documents, + the list in the following work unit gives guidance regarding the + required content. + + + + + The evaluator shall examine the CM plan to determine + that it describes how the CM system is used for the + development of the TOE. + + The descriptions contained in a CM plan include, if + applicable: + + + all activities performed in the TOE development that + are subject to configuration management procedures + (e.g. creation, modification or deletion of a + configuration item, data-backup, archiving); + + + which means (e.g. CM tools, forms) have to be made + available; + + + the usage of the CM tools: the necessary details for + a user of the CM system to be able to operate the CM + tools correctly in order to maintain the integrity + of the TOE; + + + the production support procedures; + + + which other objects (development components, tools, + assessment environments, etc) are taken under CM + control; + + + the roles and responsibilities of individuals + required to perform operations on individual + configuration items (different roles may be + identified for different types of configuration + items (e.g. design documentation or source code)); + + + how CM instances (e.g. change control boards, + interface control working groups) are introduced and + staffed; + + + the description of the change management; + + + the procedures that are used to ensure that only + authorised individuals can make changes to + configuration items; + + + the procedures that are used to ensure that + concurrency problems do not occur as a result of + simultaneous changes to configuration items; + + + the evidence that is generated as a result of + application of the procedures. For example, for a + change to a configuration item, the CM system might + record a description of the change, accountability + for the change, identification of all configuration + items affected, status (e.g. pending or completed), + and date and time of the change. This might be + recorded in an audit trail of changes made or change + control records; + + + the approach to version control and unique + referencing of TOE versions (e.g. covering the + release of patches in operating systems, and the + subsequent detection of their application). + + + + + + + The evaluator shall examine the CM plan to determine + that it describes the procedures used to accept modified + or newly created configuration items as parts of the + TOE. + + The descriptions of the acceptance procedures in the CM + plan should include the developer roles or individuals + responsible for the acceptance and the criteria to be + used for acceptance. They should take into account all + acceptance situations that may occur, in particular: + + + accepting an item into the CM system for the first + time, in particular inclusion of software, firmware + and hardware components from other manufacturers + into the TOE (``integration''); + + + moving configuration items to the next life-cycle + phase at each stage of the construction of the TOE + (e.g. module, subsystem, system); + + + subsequent to transports between different + development sites. + + + + If this work unit is applied to a dependent component + that is going to be integrated in a composed TOE, the CM + plan should consider the control of base components + obtained by the dependent TOE developer. + + When obtaining the components the evaluators are to + verify the following: + + + Transfer of each base component from the base + component developer to the integrator (dependent TOE + developer) was performed in accordance with the base + component TOE's secure delivery procedures, as + reported in the base component TOE certification + report. + + + The component received has the same identifiers as + those stated in the ST and Certification Report for + the component TOE. + + + All additional material required by a developer for + composition (integration) is provided. This is to + include the necessary extract of the component TOE's + functional specification. + + + + + + + The evaluator shall check that the configuration items + identified in the configuration list are being + maintained by the CM system. + + The CM system employed by the developer should maintain the + integrity of the TOE. The evaluator should check that for each + type of configuration item (e.g. design documents or source code + modules) contained in the configuration list there are examples + of the evidence generated by the procedures described in the CM + plan. In this case, the approach to sampling will depend upon + the level of granularity used in the CM system to control CM + items. Where, for example, 10,000 source code modules are + identified in the configuration list, a different sampling + strategy needs to be applied compared to the case in which there + are only 5, or even 1. The emphasis of this activity should be + on ensuring that the CM system is being operated correctly, + rather than on the detection of any minor error. + + For guidance on sampling see . + + + + + The evaluator shall check the CM documentation to + ascertain that it includes the CM system records + identified by the CM plan. + + The output produced by the CM system should provide the + evidence that the evaluator needs to be confident that + the CM plan is being applied, and also that all + configuration items are being maintained by the CM + system as required by . Example output could include change + control forms, or configuration item access approval + forms. + + + + + The evaluator shall examine the evidence to determine + that the CM system is being operated in accordance with + the CM plan. + + The evaluator should select and examine a sample of + evidence covering each type of CM-relevant operation + that has been performed on a configuration item + (e.g. creation, modification, deletion, reversion to an + earlier version) to confirm that all operations of the + CM system have been carried out in line with documented + procedures. The evaluator confirms that the evidence + includes all the information identified for that + operation in the CM plan. Examination of the evidence + may require access to a CM tool that is used. The + evaluator may choose to sample the evidence. + + For guidance on sampling see . + + Further confidence in the correct operation of the CM system and + the effective maintenance of configuration items may be + established by means of interviews with selected development + staff. In conducting such interviews, the evaluator aims + to gain a deeper understanding of how the CM system is used in + practise as well as to confirm that the CM procedures are being + applied as described in the CM documentation. Note that such + interviews should complement rather than replace the examination + of documentary evidence, and may not be necessary if the + documentary evidence alone satisfies the requirement. However, + given the wide scope of the CM plan it is possible that some + aspects (e.g. roles and responsibilities) may not be clear from + the CM plan and records alone. This is one case where + clarification may be necessary through interviews. + + It is expected that the evaluator will visit the + development site in support of this activity. + + For guidance on site visits see . + + + + + + + + + + + A unique reference is required to ensure that there is no + ambiguity in terms of which instance of the TOE is being + evaluated. Labelling the TOE with its reference ensures + that users of the TOE can be aware of which instance of + the TOE they are using. + + Unique identification of the configuration items leads to + a clearer understanding of the composition of the TOE, + which in turn helps to determine those items which are + subject to the evaluation requirements for the TOE. + + The use of a CM system increases assurance that the + configuration items are maintained in a controlled + manner. + + Providing controls to ensure that unauthorised + modifications are not made to the TOE (``CM access + control''), and ensuring proper functionality and use of + the CM system, helps to maintain the integrity of the + TOE. + + The purpose of the acceptance procedures is to ensure that + the parts of the TOE are of adequate quality and to + confirm that any creation or modification of configuration + items is authorised. Acceptance procedures are an + essential element in integration processes and in the + life-cycle management of the TOE. + + In development environments where the configuration items + are complex, it is difficult to control changes without + the support of automated tools. In particular, these + automated tools need to be able to support the numerous + changes that occur during development and ensure that + those changes are authorised. It is an objective of this + component to ensure that the configuration items are + controlled through automated means. If the TOE is + developed by multiple developers, i.e. integration has to + take place, the use of automatic tools is adequate. + + Production support procedures help to ensure that the + generation of the TOE from a managed set of configuration + items is correctly performed in an authorised manner, + particularly in the case when different developers are + involved and integration processes have to be carried + out. + + Requiring that the CM system be able to identify the + version of the implementation representation from which + the TOE is generated helps to ensure that the integrity of + this material is preserved by the appropriate technical, + physical and procedural safeguards. + + Providing an automated means of ascertaining changes + between versions of the TOE and identifying which + configuration items are affected by modifications to other + configuration items assists in determining the impact of + the changes between successive versions of the TOE. This + in turn can provide valuable information in determining + whether changes to the TOE result in all configuration + items being consistent with one another. + + + + The objectives of this sub-activity are to determine + whether the developer has clearly identified the TOE and + its associated configuration items, and whether the + ability to modify these items is properly controlled by + automated tools, thus making the CM system less + susceptible to human error or negligence. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the TOE suitable for testing; + + + the configuration management documentation. + + + + + The developer shall provide the TOE and a reference for the + TOE. + + + The developer shall provide the CM documentation. + + + The developer shall use a CM system. + + + The TOE shall be labelled with its unique reference. + + + The CM documentation shall describe the method used to + uniquely identify the configuration items. + + + The CM documentation shall justify that the acceptance + procedures provide for an adequate and appropriate review of + changes to all configuration items. + + + The CM system shall uniquely identify all configuration + items. + + + The CM system shall provide automated measures such that + only authorised changes are made to the configuration items. + + + The CM system shall support the production of the TOE by + automated means. + + + The CM system shall ensure that the person responsible for + accepting a configuration item into CM is not the person who + developed it. + + + The CM system shall identify the configuration items that + comprise the TSF. + + + The CM system shall support the audit of all changes to the + TOE by automated means, including the originator, date, and + time in the audit trail. + + + The CM system shall provide an automated means to identify + all other configuration items that are affected by the + change of a given configuration item. + + + The CM system shall be able to identify the version of the + implementation representation from which the TOE is + generated. + + + The CM documentation shall include a CM plan. + + + The CM plan shall describe how the CM system is used for the + development of the TOE. + + + The CM plan shall describe the procedures used to accept + modified or newly created configuration items as part of the + TOE. + + + The evidence shall demonstrate that all configuration items + are being maintained under the CM system. + + + The evidence shall demonstrate that the CM system is being + operated in accordance with the CM plan. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the TOE provided for + evaluation is labelled with its reference. + + The evaluator should ensure that the TOE contains the + unique reference which is stated in the ST. This could + be achieved through labelled packaging or media, or by a + label displayed by the operational TOE. This is to + ensure that it would be possible for consumers to + identify the TOE (e.g. at the point of purchase or + use). + + The TOE may provide a method by which it can be easily + identified. For example, a software TOE may display its + name and version number during the start up routine, or + in response to a command line entry. A hardware or + firmware TOE may be identified by a part number + physically stamped on the TOE. + + Alternatively, the unique reference provided for the TOE + may be the combination of the unique reference of each + component from which the TOE is comprised (e.g. in the + case of a composed TOE). + + + + The evaluator shall check that the TOE references used + are consistent. + + If the TOE is labelled more than once then the labels + have to be consistent. For example, it should be + possible to relate any labelled guidance documentation + supplied as part of the TOE to the evaluated operational + TOE. This ensures that consumers can be confident that + they have purchased the evaluated version of the TOE, + that they have installed this version, and that they + have the correct version of the guidance to operate the + TOE in accordance with its ST. + + The evaluator also verifies that the TOE reference is + consistent with the ST. + + If this work unit is applied to a composed TOE, the + following will apply. The composed IT TOE will not be + labelled with its unique (composite) reference, but only + the individual components will be labelled with their + appropriate TOE reference. It would require further + development for the IT TOE to be labelled, i.e. during + start-up and/or operation, with the composite reference. + If the composed TOE is delivered as the constituent + component TOEs, then the TOE items delivered will not + contain the composite reference. However, the composed + TOE ST will include the unique reference for the + composed TOE and will identify the components comprising + the composed TOE through which the consumers will be + able to determine whether they have the appropriate + items. + + + + + The evaluator shall examine the method of identifying + configuration items to determine that it describes how + configuration items are uniquely identified. + + Procedures should describe how the status of each + configuration item can be tracked throughout the + life-cycle of the TOE. The procedures may be detailed in + the CM plan or throughout the CM documentation. The + information included should describe: + + + the method how each configuration item is uniquely + identified, such that it is possible to track + versions of the same configuration item; + + the method how configuration items are assigned + unique identifiers and how they are entered into the + CM system; + + the method to be used to identify superseded + versions of a configuration item. + + + + + + The evaluator shall examine the CM documentation to + determine that it justifies that the acceptance + procedures provide for an adequate and appropriate + review of changes to all configuration items. + + The CM documentation should make it sufficiently clear + that by following the acceptance procedures only parts + of adequate quality are incorporated into the + TOE. + + + + + The evaluator shall examine the configuration items to + determine that they are identified in a way that is + consistent with the CM documentation. + + Assurance that the CM system uniquely identifies all + configuration items is gained by examining the + identifiers for the configuration items. For both + configuration items that comprise the TOE, and drafts of + configuration items that are submitted by the developer + as evaluation evidence, the evaluator confirms that each + configuration item possesses a unique identifier in a + manner consistent with the unique identification method + that is described in the CM documentation. + + + + + The evaluator shall examine the CM access control + measures described in the CM plan (cf. ) to determine that + they are automated and effective in preventing + unauthorised access to the configuration items. + + The evaluator may use a number of methods to determine + that the CM access control measures are effective. For + example, the evaluator may exercise the access control + measures to ensure that the procedures could not be + bypassed. The evaluator may use the outputs generated by + the CM system procedures required by . The evaluator may also witness a + demonstration of the CM system to ensure that the access + control measures employed are operating + effectively. + + + + + The evaluator shall check the CM plan (cf. ) for automated + procedures for supporting the production of the + TOE. + + The term ``production'' applies to those processes + adopted by the developer to progress the TOE from the + implementation representation to a state acceptable for + delivery to the end customer. + + The evaluator verifies the existence of automated + production support procedures within the CM plan. + + The following are examples for automated means + supporting the production of the TOE: + + + a ``make'' tool (as provided with many software + development tools) in the case of a software TOE; + + + a tool ensuring automatically (for example by means + of bar codes) that only parts are combined which + indeed belong together in the case of a hardware + TOE. + + + + + + + The evaluator shall examine the TOE production support + procedures to determine that they are effective in + ensuring that a TOE is generated that reflects its + implementation representation. + + The production support procedures should describe which + tools have to be used to produce the final TOE from the + implementation representation in a clearly defined + way. The conventions, directives, or other necessary + constructs are described under . + + The evaluator determines that by following the + production support procedures the correct configuration + items would be used to generate the TOE. For example, in + a software TOE this may include checking that the + automated production procedures ensure that all source + files and related libraries are included in the compiled + object code. Moreover, the procedures should ensure that + compiler options and comparable other options are + defined uniquely. For a hardware TOE, this work unit may + include checking that the automatic production + procedures ensure that the belonging parts are built + together and no parts are missing. + + The customer can then be confident that the version of + the TOE delivered for installation is derived from the + implementation representation in an unambiguous way and + implements the SFRs as described in the ST. + + The evaluator should bear in mind that the CM system + need not necessarily possess the capability to produce + the TOE, but should provide support for the process that + will help reduce the probability of human error. + + + + + The evaluator shall examine the CM system to determine + that it ensures that the person responsible for + accepting a configuration item is not the person who + developed it. + + The acceptance procedures describe who is responsible + for accepting a configuration item. From these + descriptions, the evaluator should be able to determine + that the person who developed a configuration item is in + no case responsible for its acceptance. + + + + + The evaluator shall examine the CM system to determine + that it identifies the configuration items that comprise + the TSF. + + The CM documentation should describe how the CM system + identifies the configuration items that comprise the + TSF. The evaluator should select a sample of + configuration items covering each type of items, + particularly containing TSF and non-TSF items, and check + that they are correctly classified by the CM + system. + + For guidance on sampling see . + + + + + The evaluator shall examine the CM system to determine + that it supports the audit of all changes to the TOE by + automated means, including the originator, date, and + time in the audit trail. + + The evaluator should inspect a sample of audit trails + and check, if they contain the minimum + information. + + + + + The evaluator shall examine the CM system to determine + that it provides an automated means to identify all + other configuration items that are affected by the + change of a given configuration item. + + The CM documentation should describe how the CM system + identifies all other configuration items that are + affected by the change of a given configuration + item. The evaluator should select a sample of + configuration items, covering all types of items, and + exercise the automated means to determine that it + identifies all items that are affected by the change of + the selected item. + + For guidance on sampling see . + + + + + The evaluator shall examine the CM system to determine + that it is able to identify the version of the + implementation representation from which the TOE is + generated. + + The CM documentation should describe how the CM system + identifies the version of the implementation + representation from which the TOE is generated. The + evaluator should select a sample of the parts used to + produce the TOE and should apply the CM system to verify + that it identifies the corresponding implementation + representation in the correct version. + + For guidance on sampling see . + + + + + The evaluator shall check that the CM documentation provided + includes a CM plan. + The CM plan needs not to be a connected document, but it is + recommended that there is a single document that describes where + the various parts of the CM plan can be found. If the CM plan is + no single document, the list in the following work unit gives + hints regarding which context is expected. + + + + + The evaluator shall examine the CM plan to determine + that it describes how the CM system is used for the + development of the TOE. + + The descriptions contained in a CM plan include, if + applicable: + + + all activities performed in the TOE development that + are subject to configuration management procedures + (e.g. creation, modification or deletion of a + configuration item, data-backup, archiving); + + + which means (e.g. CM tools, forms) have to be made + available; + + + the usage of the CM tools: the necessary details for + a user of the CM system to be able to operate the CM + tools correctly in order to maintain the integrity + of the TOE; + + + the production support procedures; + + + which other objects (development components, tools, + assessment environments, etc) are taken under CM + control; + + + the roles and responsibilities of individuals + required to perform operations on individual + configuration items (different roles may be + identified for different types of configuration + items (e.g. design documentation or source code)); + + + how CM instances (e.g. change control boards, + interface control working groups) are introduced and + staffed; + + + the description of the change management; + + + the procedures that are used to ensure that only + authorised individuals can make changes to + configuration items; + + + the procedures that are used to ensure that + concurrency problems do not occur as a result of + simultaneous changes to configuration items; + + + the evidence that is generated as a result of + application of the procedures. For example, for a + change to a configuration item, the CM system might + record a description of the change, accountability + for the change, identification of all configuration + items affected, status (e.g. pending or completed), + and date and time of the change. This might be + recorded in an audit trail of changes made or change + control records; + + + the approach to version control and unique + referencing of TOE versions (e.g. covering the + release of patches in operating systems, and the + subsequent detection of their application). + + + + + + + The evaluator shall examine the CM plan to determine + that it describes the procedures used to accept modified + or newly created configuration items as parts of the + TOE. + + The descriptions of the acceptance procedures in the CM + plan should include the developer roles or individuals + responsible for the acceptance and the criteria to be + used for acceptance. They should take into account all + acceptance situations that may occur, in particular: + + + accepting an item into the CM system for the first + time, in particular inclusion of software, firmware + and hardware components from other manufacturers + into the TOE (``integration''); + + + moving configuration items to the next life-cycle + phase at each stage of the construction of the TOE + (e.g. module, subsystem, system); + + + subsequent to transports between different + development sites. + + + + + + + The evaluator shall check that the configuration items + identified in the configuration list are being + maintained by the CM system. + + The CM system employed by the developer should maintain the + integrity of the TOE. The evaluator should check that for each + type of configuration item (e.g. design documents or source code + modules) contained in the configuration list there are examples + of the evidence generated by the procedures described in the CM + plan. In this case, the approach to sampling will depend upon + the level of granularity used in the CM system to control CM + items. Where, for example, 10,000 source code modules are + identified in the configuration list, a different sampling + strategy needs to be applied compared to the case in which there + are only 5, or even 1. The emphasis of this activity should be + on ensuring that the CM system is being operated correctly, + rather than on the detection of any minor error. + + For guidance on sampling see . + + + + + The evaluator shall check the CM documentation to + ascertain that it includes the CM system records + identified by the CM plan. + + The output produced by the CM system should provide the + evidence that the evaluator needs to be confident that + the CM plan is being applied, and also that all + configuration items are being maintained by the CM + system as required by . Example output could include + change control forms, or configuration item access + approval forms. + + + + + The evaluator shall examine the evidence to determine + that the CM system is being operated in accordance with + the CM plan. + + The evaluator should select and examine a sample of + evidence covering each type of CM-relevant operation + that has been performed on a configuration item + (e.g. creation, modification, deletion, reversion to an + earlier version) to confirm that all operations of the + CM system have been carried out in line with documented + procedures. The evaluator confirms that the evidence + includes all the information identified for that + operation in the CM plan. Examination of the evidence + may require access to a CM tool that is used. The + evaluator may choose to sample the evidence. + + For guidance on sampling see . + + Further confidence in the correct operation of the CM system and + the effective maintenance of configuration items may be + established by means of interviews with selected development + staff. In conducting such interviews, the evaluator aims + to gain a deeper understanding of how the CM system is used in + practise as well as to confirm that the CM procedures are being + applied as described in the CM documentation. Note that such + interviews should complement rather than replace the examination + of documentary evidence, and may not be necessary if the + documentary evidence alone satisfies the requirement. However, + given the wide scope of the CM plan it is possible that some + aspects (e.g. roles and responsibilities) may not be clear from + the CM plan and records alone. This is one case where + clarification may be necessary through interviews. + + It is expected that the evaluator will visit the + development site in support of this activity. + + For guidance on site visits see . + + + + The evaluator shall determine that the application of the + production support procedures results in a TOE as provided + by the developer for testing activities. + + + The evaluator shall examine the production support + procedures to determine that by following these + procedures a TOE would be produced like that one + provided by the developer for testing activities. + + If the TOE is a small software TOE and production + consists of compiling and linking, the evaluator might + confirm the adequacy of the production support + procedures by reapplying them himself. + + If the production process of the TOE is more complicated + (as for example in the case of a smart card), but has + already started, the evaluator should inspect the + application of the production support procedures during + a visit of the development site. He might compare a copy + of the TOE produced in his presence with the samples + used for his testing activities. + + For guidance on site visits see . + + Otherwise the evaluator's determination should be based + on the documentary evidence provided by the + developer. + + This work unit may be performed in conjunction with the + evaluation activities under . + + + + + + + + The objective of this family is to identify items to be + included as configuration items and hence placed under the + CM requirements of . + Applying configuration management to these additional items + provides additional assurance that the integrity of TOE is + maintained. + + + + Configuration management scope indicates the TOE items that + need to be controlled by the configuration management + system. + + + + The components in this family are levelled on the basis of + which of the following are required to be included as + configuration items: the TOE and the evaluation evidence + required by the SARs; the parts of the TOE; the + implementation representation; security flaws; and + development tools and related information. + + + + While mandates a list of + configuration items and that each item on this list be under + CM, leaves the contents of + the configuration list to the discretion of the + developer. narrows this + discretion by identifying items that must be included in the + configuration list, and hence come under the CM requirements + of . + + + + + A CM system can control changes only to those items that + have been placed under CM (i.e., the configuration items + identified in the configuration list). Placing the TOE + itself and the evaluation evidence required by the other + SARs in the ST under CM provides assurance that they have + been modified in a controlled manner with proper + authorisations. + + + + introduces the + requirement that the TOE itself and the evaluation + evidence required by the other SARs in the ST be included + in the configuration list and hence be subject to the CM + requirements of . + + + + The objective of this sub-activity is to determine whether + the developer performs configuration management on the TOE + and the evaluation evidence. These configuration items are + controlled in accordance with . + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the configuration list. + + + + + The developer shall provide a configuration list for the + TOE. + + + The configuration list shall include the following: the TOE + itself; and the evaluation evidence required by the SARs. + + + The configuration list shall uniquely identify the + configuration items. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the configuration list + includes the following set of items: + + + the TOE itself; + + + the evaluation evidence required by the SARs in the + ST. + + + + + + + The evaluator shall examine the configuration list to + determine that it uniquely identifies each configuration + item. + + The configuration list contains sufficient information + to uniquely identify which version of each item has been + used (typically a version number). Use of this list will + enable the evaluator to check that the correct + configuration items, and the correct version of each + item, have been used during the evaluation. + + + + + + + + A CM system can control changes only to those items that + have been placed under CM (i.e., the configuration items + identified in the configuration list). Placing the TOE + itself, the parts that comprise the TOE, and the + evaluation evidence required by the other SARs under CM + provides assurance that they have been modified in a + controlled manner with proper authorisations. + + + + introduces the + requirement that the parts that comprise the TOE (all + parts that are delivered to the consumer, for example + hardware parts or executable files) be included in the + configuration list and hence be subject to the CM + requirements of . + + introduces the + requirement that the configuration list indicate the + developer of each TSF relevant configuration + item. ``Developer'' here does not refer to a person, but + to the organisation responsible for the development of the + item. + + + + The objective of this sub-activity is to determine whether + the configuration list includes the TOE, the parts that + comprise the TOE, and the evaluation evidence. These configuration items are + controlled in accordance with . + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the configuration list. + + + + + The developer shall provide a configuration list for the + TOE. + + + The configuration list shall include the following: the TOE + itself; the evaluation evidence required by the SARs; and + the parts that comprise the TOE. + + + The configuration list shall uniquely identify the + configuration items. + + + For each TSF relevant configuration item, the configuration + list shall indicate the developer of the item. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the configuration list + includes the following set of items: + + the TOE itself; + + the parts that comprise the TOE; + + the evaluation evidence required by the SARs. + + + + + + + The evaluator shall examine the configuration list to + determine that it uniquely identifies each configuration + item. + + The configuration list contains sufficient information + to uniquely identify which version of each item has been + used (typically a version number). Use of this list will + enable the evaluator to check that the correct + configuration items, and the correct version of each + item, have been used during the evaluation. + + + + + The evaluator shall check that the configuration list + indicates the developer of each TSF relevant + configuration item. + + If only one developer is involved in the development of + the TOE, this work unit is not applicable, and is + therefore considered to be satisfied. + + + + + + + + A CM system can control changes only to those items that + have been placed under CM (i.e., the configuration items + identified in the configuration list). Placing the TOE + itself, the parts that comprise the TOE, the TOE + implementation representation and the evaluation evidence + required by the other SARs under CM provides assurance + that they have been modified in a controlled manner with + proper authorisations. + + + + introduces the + requirement that the TOE implementation representation be + included in the list of configuration items and hence be + subject to the CM requirements of . + + + + The objective of this sub-activity is to determine whether + the configuration list includes the TOE, the parts that + comprise the TOE, the TOE implementation representation, + and the evaluation evidence. These configuration items are + controlled in accordance with . + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the configuration list. + + + + + The developer shall provide a configuration list for the + TOE. + + + The configuration list shall include the following: the TOE + itself; the evaluation evidence required by the SARs; the + parts that comprise the TOE; and the implementation + representation. + + + The configuration list shall uniquely identify the + configuration items. + + + For each TSF relevant configuration item, the configuration + list shall indicate the developer of the item. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the configuration list + includes the following set of items: + + + the TOE itself; + + + the parts that comprise the TOE; + + + the TOE implementation representation; + + + the evaluation evidence required by the SARs in the + ST. + + + + + + + The evaluator shall examine the configuration list to + determine that it uniquely identifies each configuration + item. + + The configuration list contains sufficient information + to uniquely identify which version of each item has been + used (typically a version number). Use of this list will + enable the evaluator to check that the correct + configuration items, and the correct version of each + item, have been used during the evaluation. + + + + + The evaluator shall check that the configuration list + indicates the developer of each TSF relevant + configuration item. + + If only one developer is involved in the development of + the TOE, this work unit is not applicable, and is + therefore considered to be satisfied. + + + + + + + + A CM system can control changes only to those items that + have been placed under CM (i.e., the configuration items + identified in the configuration list). Placing the TOE + itself, the parts that comprise the TOE, the TOE + implementation representation and the evaluation evidence + required by the other SARs under CM provides assurance + that they have been modified in a controlled manner with + proper authorisations. + + Placing security flaws under CM ensures that security flaw + reports are not lost or forgotten, and allows a developer + to track security flaws to their resolution. + + + + introduces the + requirement that security flaws be included in the + configuration list and hence be subject to the CM + requirements of . This + requires that information regarding previous security + flaws and their resolution be maintained, as well as + details regarding current security flaws. + + + + The objective of this sub-activity is to determine whether + the configuration list includes the TOE, the parts that + comprise the TOE, the TOE implementation representation, + security flaws, and the evaluation evidence. These configuration items are + controlled in accordance with . + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the configuration list. + + + + + The developer shall provide a configuration list for the + TOE. + + + The configuration list shall include the following: the TOE + itself; the evaluation evidence required by the SARs; the + parts that comprise the TOE; the implementation + representation; and security flaw reports and resolution + status. + + + The configuration list shall uniquely identify the + configuration items. + + + For each TSF relevant configuration item, the configuration + list shall indicate the developer of the item. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the configuration list + includes the following set of items: + + + the TOE itself; + + + the parts that comprise the TOE; + + + the TOE implementation representation; + + + the evaluation evidence required by the SARs in the + ST; + + + the documentation used to record details of reported + security flaws associated with the implementation + (e.g., problem status reports derived from a + developer's problem database). + + + + + + + The evaluator shall examine the configuration list to + determine that it uniquely identifies each configuration + item. + + The configuration list contains sufficient information + to uniquely identify which version of each item has been + used (typically a version number). Use of this list will + enable the evaluator to check that the correct + configuration items, and the correct version of each + item, have been used during the evaluation. + + + + + The evaluator shall check that the configuration list + indicates the developer of each TSF relevant + configuration item. + + If only one developer is involved in the development of + the TOE, this work unit is not applicable, and is + therefore considered to be satisfied. + + + + + + + + A CM system can control changes only to those items that + have been placed under CM (i.e., the configuration items + identified in the configuration list). Placing the TOE + itself, the parts that comprise the TOE, the TOE + implementation representation and the evaluation evidence + required by the other SARs under CM provides assurance + that they have been modified in a controlled manner with + proper authorisations. + + Placing security flaws under CM ensures that security flaw + reports are not lost or forgotten, and allows a developer + to track security flaws to their resolution. + + Development tools play an important role in ensuring the + production of a quality version of the TOE. Therefore, it + is important to control modifications to these + tools. + + + + introduces the + requirement that development tools and other related + information be included in the list of configuration items + and hence be subject to the CM requirements of . Examples of development tools + are programming languages and compilers. Information + pertaining to TOE generation items (such as compiler + options, generation options, and build options) is an + example of information relating to development + tools. + + + + The objective of this sub-activity is to determine whether + the configuration list includes the TOE, the parts that + comprise the TOE, the TOE implementation representation, + security flaws, development tools and related information, + and the evaluation evidence. These configuration items are + controlled in accordance with . + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the configuration list. + + + + + The developer shall provide a configuration list for the + TOE. + + + The configuration list shall include the following: the TOE + itself; the evaluation evidence required by the SARs; the + parts that comprise the TOE; the implementation + representation; security flaw reports and resolution status; + and development tools and related information. + + + The configuration list shall uniquely identify the + configuration items. + + + For each TSF relevant configuration item, the configuration + list shall indicate the developer of the item. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the configuration list + includes the following set of items: + + + the TOE itself; + + + the parts that comprise the TOE; + + + the TOE implementation representation; + + + the evaluation evidence required by the SARs in the + ST; + + + the documentation used to record details of reported + security flaws associated with the implementation + (e.g., problem status reports derived from a + developer's problem database); + + + all tools (incl. test software, if applicable) + involved in the development and production of the + TOE including the names, versions, configurations + and roles of each development tool, and related + documentation. + + + For a software TOE, ``development tools'' are usually + programming languages and compiler and ``related documentation'' + comprises compiler and linker options. For a hardware TOE, + ``development tools'' might be hardware design languages, + simulation and synthesis tools, compilers, and ``related + documentation'' might comprise compiler options again. + + + + + The evaluator shall examine the configuration list to + determine that it uniquely identifies each configuration + item. + + The configuration list contains sufficient information + to uniquely identify which version of each item has been + used (typically a version number). Use of this list will + enable the evaluator to check that the correct + configuration items, and the correct version of each + item, have been used during the evaluation. + + + + + The evaluator shall check that the configuration list + indicates the developer of each TSF relevant + configuration item. + + If only one developer is involved in the development of + the TOE, this work unit is not applicable, and is + therefore considered to be satisfied. + + + + + + + + The concern of this family is the secure transfer of the + finished TOE from the development environment into the + responsibility of the user. + + The requirements for delivery call for system control and + distribution facilities and procedures that detail the + measures necessary to provide assurance that the security of + the TOE is maintained during distribution of the TOE to the + user. For a valid distribution of the TOE, the procedures + used for the distribution of the TOE address the objectives + identified in the PP/ST relating to the security of the TOE + during delivery. + + + + Delivery covers the procedures used to maintain security + during transfer of the TOE to the user, both on initial + delivery and as part of subsequent modification. It includes + special procedures or operations required to demonstrate the + authenticity of the delivered TOE. Such procedures and + measures are the basis for ensuring that the security + protection offered by the TOE is not compromised during + transfer. While compliance with the delivery requirements + cannot always be determined when a TOE is evaluated, it is + possible to evaluate the procedures that a developer has + developed to distribute the TOE to users. + + + + This family contains only one component. An increasing level + of protection is established by requiring commensurability + of the delivery procedures with the assumed attack potential + in the family . + + + + Transportations from subcontractors to the developer or + between different development sites are not considered here, + but in the family . + + The end of the delivery phase is marked by the transfer of + the TOE into the responsibility of the user. This does not + necessarily coincide with the arrival of the TOE at the + user's location. + + The delivery procedures should consider, if applicable, + issues such as: + + + ensuring that the TOE received by the consumer + corresponds precisely to the evaluated version of the + TOE; + + + avoiding or detecting any tampering with the actual + version of the TOE; + + + preventing submission of a false version of the TOE; + + + avoiding unwanted knowledge of distribution of the TOE + to the consumer: there might be cases where potential + attackers should not know when and how it is delivered; + + + avoiding or detecting the TOE being intercepted during + delivery; and + + + avoiding the TOE being delayed or stopped during + distribution. + + + + The delivery procedures should include the recipient's + actions implied by these issues. The consistent description + of these implied actions is examined in the family, if present. + + + + + The objective of this sub-activity is to determine whether + the delivery documentation describes all procedures used + to maintain security of the TOE when distributing the TOE + to the user. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the delivery documentation. + + + + + The developer shall document and provide procedures for delivery of the + TOE or parts of it to the consumer. + + + The developer shall use the delivery procedures. + + + The evaluator shall examine aspects of the delivery + process to determine that the delivery procedures are + used. + + The approach taken by the evaluator to check the + application of delivery procedures will depend on the + nature of the TOE, and the delivery process itself. In + addition to examination of the procedures themselves, + the evaluator seeks some assurance that they are applied + in practise. Some possible approaches are: + + + a visit to the distribution site(s) where practical + application of the procedures may be observed; + + + examination of the TOE at some stage during + delivery, or after the user has received it + (e.g. checking for tamper proof seals); + + + observing that the process is applied in practise + when the evaluator obtains the TOE through regular + channels; + + + questioning end users as to how the TOE was + delivered. + + + + For guidance on site visits see . + + It may be the case of a newly developed TOE that the + delivery procedures have yet to be exercised. In these + cases, the evaluator has to be satisfied that + appropriate procedures and facilities are in place for + future deliveries and that all personnel involved are + aware of their responsibilities. The evaluator may + request a ``dry run'' of a delivery if this is + practical. If the developer has produced other similar + products, then an examination of procedures in their use + may be useful in providing assurance. + + + + The delivery documentation shall describe all procedures + that are necessary to maintain security when distributing + versions of the TOE to the consumer. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the delivery documentation + to determine that it describes all procedures that are + necessary to maintain security when distributing + versions of the TOE or parts of it to the + consumer. + + The delivery documentation describes proper procedures + to maintain security of the TOE during transfer of the + TOE or its component parts and to determine the + identification of the TOE. + + The delivery documentation should cover the entire TOE, + but may contain different procedures for different parts + of the TOE. The evaluation should consider the totality + of procedures. + + The delivery procedures should be applicable across all + phases of delivery from the production environment to + the installation environment (e.g. packaging, storage + and distribution). Standard commercial practise for + packaging and delivery may be acceptable. This includes + shrink wrapped packaging, a security tape or a sealed + envelope. For the distribution, physical (e.g. public + mail or a private distribution service) or electronic + (e.g. electronic mail or downloading off the Internet) + procedures may be used. + + Cryptographic checksums or a software signature may be + used by the developer to ensure that tampering or + masquerading can be detected. Tamper proof seals + additionally indicate if the confidentiality has been + broken. For software TOEs, confidentiality might be + assured by using encryption. If availability is of + concern, a secure transportation might be + required. + + Interpretation of the term ``necessary to maintain + security'' will need to consider: + + + The nature of the TOE (e.g. whether it is software + or hardware). + + + The overall security level stated for the TOE by the + chosen level of the Vulnerability Assessment. If the + TOE is required to be resistant against attackers of + a certain potential in its intended environment, + this should also apply to the delivery of the + TOE. The evaluator should determine that a balanced + approach has been taken, such that delivery does not + present a weak point in an otherwise secure + development process. + + + The security objectives provided by the ST. The emphasis in the + delivery documentation is likely to be on measures related to + integrity, as integrity of the TOE is always important. However, + confidentiality and availability of the delivery will be of + concern in the delivery of some TOEs; procedures relating to + these aspects of the secure delivery should also be discussed in + the procedures. + + + + + + + + + + Development security is concerned with physical, procedural, + personnel, and other security measures that may be used in + the development environment to protect the TOE and its + parts. It includes the physical security of the development + location and any procedures used to select development + staff. + + + + Development security covers the physical, procedural, + personnel, and other security measures used in the + development environment. It includes physical security of + the development location(s) and controls on the selection + and hiring of development staff. + + + + The components in this family are levelled on the basis of + whether justification of the sufficiency of the security + measures is required. + + + + This family deals with measures to remove or reduce threats + existing at the developer's site. + + The evaluator should visit the site(s) in order to assess + evidence for development security. This may include sites of + subcontractors involved in the TOE development and + production. Any decision not to visit shall be agreed with + the evaluation authority. + + Although development security deals with the maintenance of + the TOE and hence with aspects becoming relevant after the + completion of the evaluation, the requirements specify only that the + development security measures be in place at the time of + evaluation. Furthermore, + does not contain any requirements related to the sponsor's + intention to apply the development security measures in the + future, after completion of the evaluation. + + It is recognised that confidentiality may not always be an + issue for the protection of the TOE in its development + environment. The use of the word ``necessary'' allows for + the selection of appropriate safeguards. + + + + + The objective of this sub-activity is to determine whether + the developer's security controls on the development + environment are adequate to provide the confidentiality + and integrity of the TOE design and implementation that is + necessary to ensure that secure operation of the TOE is + not compromised. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the development security documentation. + + + + In addition, the evaluator may need to examine other + deliverables to determine that the security controls are + well-defined and followed. Specifically, the evaluator may + need to examine the developer's configuration management + documentation (the input for the ``Production support and acceptance + procedures'' and the + ``Problem tracking CM coverage''). Evidence that the + procedures are being applied is also required. + + + The developer shall produce and provide development security + documentation. + + + The development security documentation shall describe all + the physical, procedural, personnel, and other security + measures that are necessary to protect the confidentiality + and integrity of the TOE design and implementation in its + development environment. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the development security + documentation to determine that it details all security + measures used in the development environment that are + necessary to protect the confidentiality and integrity + of the TOE design and implementation. + + The evaluator determines what is necessary by first referring to + the ST for any information that may assist in the determination + of necessary protection. + + If no explicit information is available from the ST the + evaluator will need to make a determination of the + necessary measures. In cases where the developer's + measures are considered less than what is necessary, a + clear justification should be provided for the + assessment, based on a potential exploitable + vulnerability. + + The following types of security measures are considered + by the evaluator when examining the documentation: + + + physical, for example physical access controls used + to prevent unauthorised access to the TOE + development environment (during normal working hours + and at other times); + + + procedural, for example covering: + + + granting of access to the development + environment or to specific parts of the + environment such as development machines + + + revocation of access rights when a person leaves + the development team + + + transfer of protected material within and out of + the development environment and between + different development sites in accordance with + defined acceptance procedures + + + admitting and escorting visitors to the + development environment + + + roles and responsibilities in ensuring the + continued application of security measures, and + the detection of security breaches. + + + + + personnel, for example any controls or checks made + to establish the trustworthiness of new development + staff; + + + other security measures, for example the logical + protections on any development machines. + + + + The development security documentation should identify + the locations at which development occurs, and describe + the aspects of development performed, along with the + security measures applied at each location and for + transports between different locations. For example, + development could occur at multiple facilities within a + single building, multiple buildings at the same site, or + at multiple sites. Transports of parts of the TOE or the + unfinished TOE between different development sites are + to be covered by , + whereas the transport of the finished TOE to the + consumer is dealt with in . + + Development includes the production of the TOE. + + + + + The evaluator shall examine the development + confidentiality and integrity policies in order to + determine the sufficiency of the security measures + employed. + + The evaluator should examine whether the following is included + in the policies: + + what information relating to the TOE development needs to be + kept confidential, and which members of the development + staff are allowed to access such material; + + what material must be protected from unauthorised + modification in order to preserve the integrity of + the TOE, and which members of the development staff + are allowed to modify such material. + + + The evaluator should determine that these policies are + described in the development security documentation, + that the security measures employed are consistent with + the policies, and that they are complete. + + It should be noted that configuration management + procedures will help protect the integrity of the TOE + and the evaluator should avoid overlap with the + work-units conducted for the . For example, the CM documentation may + describe the security procedures necessary for + controlling the roles or individuals who should have + access to the development environment and who may modify + the TOE. + + Whereas the + requirements are fixed, those for the , + mandating only necessary measures, are dependent on the nature of the TOE, + and on information that may be provided in the ST. The evaluators would + then determine that such a policy had been applied under this sub-activity. + + + + The evaluator shall confirm that the security measures are + being applied. + + + The evaluator shall examine the development security + documentation and associated evidence to determine that + the security measures are being applied. + + This work unit requires the evaluator to determine that + the security measures described in the development + security documentation are being followed, such that the + integrity of the TOE and the confidentiality of + associated documentation is being adequately + protected. For example, this could be determined by + examination of the documentary evidence + provided. Documentary evidence should be supplemented by + visiting the development environment. A visit to the + development environment will allow the evaluator to: + + + observe the application of security measures + (e.g. physical measures); + + + examine documentary evidence of application of + procedures; + + + interview development staff to check awareness of + the development security policies and procedures, + and their responsibilities. + + + + A development site visit is a useful means of gaining + confidence in the measures being used. Any decision not + to make such a visit should be determined in + consultation with the evaluation authority. + + For guidance on site visits see . + + + + + + + + The objective of this sub-activity is to determine whether + the developer's security controls on the development + environment are adequate to provide the confidentiality + and integrity of the TOE design and implementation that is + necessary to ensure that secure operation of the TOE is + not compromised. Additionally, sufficiency of the measures + as applied is intended be justified. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the development security documentation. + + + + In addition, the evaluator may need to examine other + deliverables to determine that the security controls are + well-defined and followed. Specifically, the evaluator may + need to examine the developer's configuration management + documentation (the input for the ``Production support and acceptance + procedures'' and the + ``Problem tracking CM coverage''). Evidence that the + procedures are being applied is also required. + + + The developer shall produce and provide development security + documentation. + + + The development security documentation shall describe all + the physical, procedural, personnel, and other security + measures that are necessary to protect the confidentiality + and integrity of the TOE design and implementation in its + development environment. + + + The development security documentation shall justify that + the security measures provide the necessary level of + protection to maintain the confidentiality and integrity of + the TOE. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the development security + documentation to determine that it details all security + measures used in the development environment that are + necessary to protect the confidentiality and integrity + of the TOE design and implementation. + + The evaluator determines what is necessary by first referring to + the ST for any information that may assist in the determination + of necessary protection. + + If no explicit information is available from the ST the + evaluator will need to make a determination of the + necessary measures. In cases where the developer's + measures are considered less than what is necessary, a + clear justification should be provided for the + assessment, based on a potential exploitable + vulnerability. + + The following types of security measures are considered + by the evaluator when examining the documentation: + + + physical, for example physical access controls used + to prevent unauthorised access to the TOE + development environment (during normal working hours + and at other times); + + + procedural, for example covering: + + + granting of access to the development + environment or to specific parts of the + environment such as development machines + + + revocation of access rights when a person leaves + the development team + + + transfer of protected material out of the + development environment and between different + development sites in accordance with defined + acceptance procedures + + + admitting and escorting visitors to the + development environment + + + roles and responsibilities in ensuring the + continued application of security measures, and + the detection of security breaches. + + + + + personnel, for example any controls or checks made + to establish the trustworthiness of new development + staff; + + + other security measures, for example the logical + protections on any development machines. + + + + The development security documentation should identify + the locations at which development occurs, and describe + the aspects of development performed, along with the + security measures applied at each location and for + transports between different locations. For example, + development could occur at multiple facilities within a + single building, multiple buildings at the same site, or + at multiple sites. Transports of parts of the TOE or the + unfinished TOE between different development sites are + to be covered by the , + whereas the transport of the finished TOE to the + consumer is dealt with in the . + + Development includes the production of the TOE. + + + + + The evaluator shall examine the development security + documentation to determine that an appropriate + justification is given why the security measures provide + the necessary level of protection to maintain the + confidentiality and integrity of the TOE. + + Since attacks on the TOE or its related information are + assumed in different design and production stages, + measures and procedures need to have an appropriate + level necessary to prevent those attacks or to make them + more difficult. + + Since this level depends on the overall attack potential + claimed for the TOE (cf. the component chosen), the development + security documentation should justify the necessary + level of protection to maintain the confidentiality and + integrity of the TOE. This level has to be achieved by + the security measures applied. + + The concept of protection measures should be consistent, + and the justification should include an analysis of how + the measures are mutually supportive. All aspects of + development and production on all the different sites + with all roles involved up to delivery of the TOE should + be analysed. + + Justification may include an analysis of potential + vulnerabilities taking the applied security measures + into account. + + There may be a convincing argument showing that e.g. + + + The technical measures and mechanisms of the + developer's infrastructure are sufficient for + keeping the appropriate security level + (e.g. cryptographic mechanisms as well as physical + protection mechanisms, properties of the CM system + (cf. )); + + The system containing the implementation + representation of the TOE (including concerning + guidance documents) provides effective protection + against logical attacks e.g. by ``Trojan'' code or + viruses. It might be adequate, if the implementation + representation is kept on an isolated system where + only the software necessary to maintain it is + installed and where no additional software is + installed afterwards. + + Data brought into this system need to be carefully considered to + prevent the installation of hidden functionality onto the + system. The effectiveness of these measures need to be tested, + e.g. by independently trying to get access to the machine, + install some additional executable (program, macro etc.) or get + some information out of the machine using logical + attacks. + + The appropriate organisational (procedural and + personal) measures are unconditionally + enforced. + + + + + The evaluator shall examine the development + confidentiality and integrity policies in order to + determine the sufficiency of the security measures + employed. + + The evaluator should examine whether the following is included + in the policies: + + what information relating to the TOE development needs to be + kept confidential, and which members of the development + staff are allowed to access such material; + + what material must be protected from unauthorised + modification in order to preserve the integrity of + the TOE, and which members of the development staff + are allowed to modify such material. + + + The evaluator should determine that these policies are + described in the development security documentation, + that the security measures employed are consistent with + the policies, and that they are complete. + + It should be noted that configuration management + procedures will help protect the integrity of the TOE + and the evaluator should avoid overlap with the + work-units conducted for the . For example, the CM documentation may + describe the security procedures necessary for + controlling the roles or individuals who should have + access to the development environment and who may modify + the TOE. + + Whereas the + requirements are fixed, those for the , mandating only necessary measures, are + dependent on the nature of the TOE, and on information + that may be provided in the ST. For example, the ST may + identify a security objective for the development + environment that requires the TOE to be developed by + staff that has security clearance. The evaluators would + then determine that such a policy had been applied under + this sub-activity. + + + + The evaluator shall confirm that the security measures are + being applied. + + + The evaluator shall examine the development security + documentation and associated evidence to determine that + the security measures are being applied. + + This work unit requires the evaluator to determine that + the security measures described in the development + security documentation are being followed, such that the + integrity of the TOE and the confidentiality of + associated documentation is being adequately + protected. For example, this could be determined by + examination of the documentary evidence + provided. Documentary evidence should be supplemented by + visiting the development environment. A visit to the + development environment will allow the evaluator to: + + + observe the application of security measures + (e.g. physical measures); + + + examine documentary evidence of application of + procedures; + + + interview development staff to check awareness of + the development security policies and procedures, + and their responsibilities. + + + + A development site visit is a useful means of gaining + confidence in the measures being used. Any decision not + to make such a visit should be determined in + consultation with the evaluation authority. + + For guidance on site visits see . + + + + + + + + Flaw remediation requires that discovered security flaws be + tracked and corrected by the developer. Although future + compliance with flaw remediation procedures cannot be + determined at the time of the TOE evaluation, it is possible + to evaluate the policies and procedures that a developer has + in place to track and correct flaws, and to distribute the + flaw information and corrections. + + + + Flaw remediation ensures that flaws discovered by the TOE + consumers will be tracked and corrected while the TOE is + supported by the developer. While future compliance with the + flaw remediation requirements cannot be determined when a + TOE is evaluated, it is possible to evaluate the procedures + and policies that a developer has in place to track and + repair flaws, and to distribute the repairs to + consumers. + + + + The components in this family are levelled on the basis of + the increasing extent in scope of the flaw remediation + procedures and the rigour of the flaw remediation + policies. + + + + This family provides assurance that the TOE will be + maintained and supported in the future, requiring the TOE + developer to track and correct flaws in the + TOE. Additionally, requirements are included for the + distribution of flaw corrections. However, this family does + not impose evaluation requirements beyond the current + evaluation. + + The TOE user is considered to be the focal point in the user + organisation that is responsible for receiving and + implementing fixes to security flaws. This is not + necessarily an individual user, but may be an organisational + representative who is responsible for the handling of + security flaws. The use of the term TOE user recognises that + different organisations have different procedures for + handling flaw reporting, which may be done either by an + individual user, or by a central administrative body. + + The flaw remediation procedures should describe the methods + for dealing with all types of flaws encountered. These flaws + may be reported by the developer, by users of the TOE, or by + other parties with familiarity with the TOE. Some flaws may + not be reparable immediately. There may be some occasions + where a flaw cannot be fixed and other (e.g. procedural) + measures must be taken. The documentation provided should + cover the procedures for providing the operational sites + with fixes, and providing information on flaws where fixes + are delayed (and what to do in the interim) or when fixes + are not possible. + + Changes applied to a TOE after its release render it + unevaluated; although some information from the original + evaluation may still apply. The phrase ``release of the + TOE'' used in this family therefore refers to a version of a + product that is a release of a certified TOE, to which + changes have been applied. + + + + + The objective of this sub-activity is to determine whether + the developer has established flaw remediation procedures + that describe the tracking of security flaws, the + identification of corrective actions, and the distribution + of corrective action information to TOE users. + + + + The evaluation evidence for this sub-activity is: + + + the flaw remediation procedures documentation. + + + + + The developer shall document and provide flaw remediation procedures + addressed to TOE developers. + + + The flaw remediation procedures documentation shall describe + the procedures used to track all reported security flaws in + each release of the TOE. + + + The flaw remediation procedures shall require that a + description of the nature and effect of each security flaw + be provided, as well as the status of finding a correction + to that flaw. + + + The flaw remediation procedures shall require that + corrective actions be identified for each of the security + flaws. + + + The flaw remediation procedures documentation shall describe + the methods used to provide flaw information, corrections + and guidance on corrective actions to TOE users. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the flaw remediation + procedures documentation to determine that it describes + the procedures used to track all reported security flaws + in each release of the TOE. + + The procedures describe the actions that are taken by + the developer from the time each suspected security flaw + is reported to the time that it is resolved. This + includes the flaw's entire time frame, from initial + detection through ascertaining that the flaw is a + security flaw, to resolution of the security + flaw. + + If a flaw is discovered not to be security-relevant, + there is no need (for the purposes of the requirements) for the flaw + remediation procedures to track it further; only that + there be an explanation of why the flaw is not + security-relevant. + + While these requirements do not mandate that there be a + publicised means for TOE users to report security flaws, + they do mandate that all security flaws that are + reported be tracked. That is, a reported security flaw + cannot be ignored simply because it comes from outside + the developer's organisation. + + + + + The evaluator shall examine the flaw remediation + procedures to determine that the application of these + procedures would produce a description of each security + flaw in terms of its nature and effects. + + The procedures identify the actions that are taken by + the developer to describe the nature and effects of each + security flaw in sufficient detail to be able to + reproduce it. The description of the nature of a + security flaw addresses whether it is an error in the + documentation, a flaw in the design of the TSF, a flaw + in the implementation of the TSF, etc. The description + of the security flaw's effects identifies the portions + of the TSF that are affected and how those portions are + affected. For example, a security flaw in the + implementation might be found that affects the + identification and authentication enforced by the TSF by + permitting authentication with the password + ``BACK DOOR''. + + + + + The evaluator shall examine the flaw remediation + procedures to determine that the application of these + procedures would identify the status of finding a + correction to each security flaw. + + The flaw remediation procedures identify the different + stages of security flaws. This differentiation includes + at least: suspected security flaws that have been + reported, suspected security flaws that have been + confirmed to be security flaws, and security flaws whose + solutions have been implemented. It is permissible that + additional stages (e.g. flaws that have been reported + but not yet investigated, flaws that are under + investigation, security flaws for which a solution has + been found but not yet implemented) be included. + + + + + The evaluator shall check the flaw remediation + procedures to determine that the application of these + procedures would identify the corrective action for each + security flaw. + + Corrective action may consist of a + repair to the hardware, firmware, or software portions + of the TOE, a modification of TOE guidance, or + both. Corrective action that constitutes modifications + to TOE guidance (e.g. details of procedural measures to + be taken to obviate the security flaw) includes both + those measures serving as only an interim solution + (until the repair is issued) as well as those serving as + a permanent solution (where it is determined that the + procedural measure is the best solution). + + If the source of the security flaw is a documentation + error, the corrective action consists of an update of + the affected TOE guidance. If the corrective action is a + procedural measure, this measure will include an update + made to the affected TOE guidance to reflect these + corrective procedures. + + + + + The evaluator shall examine the flaw remediation + procedures documentation to determine that it describes + a means of providing the TOE users with the necessary + information on each security flaw. + + The necessary information about each + security flaw consists of its description (not + necessarily at the same level of detail as that provided + as part of work unit ), the prescribed corrective action, + and any associated guidance on implementing the + correction. + + TOE users may be provided with such information, + correction, and documentation updates in any of several + ways, such as their posting to a website, their being + sent to TOE users, or arrangements made for the + developer to install the correction. In cases where the + means of providing this information requires action to + be initiated by the TOE user, the evaluator examines any + TOE guidance to ensure that it contains instructions for + retrieving the information. + + The only metric for assessing the adequacy of the method + used for providing the information, corrections and + guidance is that there be a reasonable expectation that + TOE users can obtain or receive it. For example, + consider the method of dissemination where the requisite + data is posted to a website for one month, and the TOE + users know that this will happen and when this will + happen. This may not be especially reasonable or + effective (as, say, a permanent posting to the website), + yet it is feasible that the TOE user could obtain the + necessary information. On the other hand, if the + information were posted to the website for only one + hour, yet TOE users had no way of knowing this or when + it would be posted, it is infeasible that they would + ever get the necessary information. + + + + + + + + In order for the developer to be able to act appropriately + upon security flaw reports from TOE users, and to know to + whom to send corrective fixes, TOE users need to + understand how to submit security flaw reports to the + developer. Flaw remediation guidance from the developer to + the TOE user ensures that TOE users are aware of this + important information. + + + + The objective of this sub-activity is to determine whether + the developer has established flaw remediation procedures + that describe the tracking of security flaws, the + identification of corrective actions, and the distribution + of corrective action information to TOE + users. Additionally, this sub-activity determines whether + the developer's procedures provide for the corrections of + security flaws, for the receipt of flaw reports from TOE + users, and for assurance that the corrections introduce no + new security flaws. + + In order for the developer to be able to act appropriately + upon security flaw reports from TOE users, TOE users need + to understand how to submit security flaw reports to the + developer, and developers need to know how to receive + these reports. Flaw remediation guidance addressed to the + TOE user ensures that TOE users are aware of how to + communicate with the developer; flaw remediation + procedures describe the developer's role is such + communication + + + + The evaluation evidence for this sub-activity is: + + + the flaw remediation procedures documentation; + + + flaw remediation guidance documentation. + + + + + The developer shall document and provide flaw remediation procedures + addressed to TOE developers. + + + The developer shall establish a procedure for accepting and + acting upon all reports of security flaws and requests for + corrections to those flaws. + + + The developer shall provide flaw remediation guidance + addressed to TOE users. + + + The flaw remediation procedures documentation shall describe + the procedures used to track all reported security flaws in + each release of the TOE. + + + The flaw remediation procedures shall require that a + description of the nature and effect of each security flaw + be provided, as well as the status of finding a correction + to that flaw. + + + The flaw remediation procedures shall require that + corrective actions be identified for each of the security + flaws. + + + The flaw remediation procedures documentation shall describe + the methods used to provide flaw information, corrections + and guidance on corrective actions to TOE users. + + + The flaw remediation procedures shall describe a means by + which the developer receives from TOE users reports and + enquiries of suspected security flaws in the TOE. + + + The procedures for processing reported security flaws shall + ensure that any reported flaws are remediated and the + remediation procedures issued to TOE users. + + + The procedures for processing reported security flaws shall + provide safeguards that any corrections to these security + flaws do not introduce any new flaws. + + + The flaw remediation guidance shall describe a means by + which TOE users report to the developer any suspected + security flaws in the TOE. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the flaw remediation + procedures documentation to determine that it describes + the procedures used to track all reported security flaws + in each release of the TOE. + + The procedures describe the actions that are taken by + the developer from the time each suspected security flaw + is reported to the time that it is resolved. This + includes the flaw's entire time frame, from initial + detection through ascertaining that the flaw is a + security flaw, to resolution of the security + flaw. + + If a flaw is discovered not to be security-relevant, + there is no need (for the purposes of the requirements) for the flaw + remediation procedures to track it further; only that + there be an explanation of why the flaw is not + security-relevant. + + + + + The evaluator shall examine the flaw remediation + procedures to determine that the application of these + procedures would produce a description of each security + flaw in terms of its nature and effects. + + The procedures identify the actions that are taken by + the developer to describe the nature and effects of each + security flaw in sufficient detail to be able to + reproduce it. The description of the nature of a + security flaw addresses whether it is an error in the + documentation, a flaw in the design of the TSF, a flaw + in the implementation of the TSF, etc. The description + of the security flaw's effects identifies the portions + of the TSF that are affected and how those portions are + affected. For example, a security flaw in the + implementation might be found that affects the + identification and authentication enforced by the TSF by + permitting authentication with the password + ``BACKDOOR''. + + + + + The evaluator shall examine the flaw remediation + procedures to determine that the application of these + procedures would identify the status of finding a + correction to each security flaw. + + The flaw remediation procedures identify the different + stages of security flaws. This differentiation includes + at least: suspected security flaws that have been + reported, suspected security flaws that have been + confirmed to be security flaws, and security flaws whose + solutions have been implemented. It is permissible that + additional stages (e.g. flaws that have been reported + but not yet investigated, flaws that are under + investigation, security flaws for which a solution has + been found but not yet implemented) be included. + + + + + The evaluator shall check the flaw remediation + procedures to determine that the application of these + procedures would identify the corrective action for each + security flaw. + + Corrective action may consist of a + repair to the hardware, firmware, or software portions + of the TOE, a modification of TOE guidance, or + both. Corrective action that constitutes modifications + to TOE guidance (e.g. details of procedural measures to + be taken to obviate the security flaw) includes both + those measures serving as only an interim solution + (until the repair is issued) as well as those serving as + a permanent solution (where it is determined that the + procedural measure is the best solution). + + If the source of the security flaw is a documentation + error, the corrective action consists of an update of + the affected TOE guidance. If the corrective action is a + procedural measure, this measure will include an update + made to the affected TOE guidance to reflect these + corrective procedures. + + + + + The evaluator shall examine the flaw remediation + procedures documentation to determine that it describes + a means of providing the TOE users with the necessary + information on each security flaw. + + The necessary information about each + security flaw consists of its description (not + necessarily at the same level of detail as that provided + as part of work unit ), the prescribed corrective action, + and any associated guidance on implementing the + correction. + + TOE users may be provided with such information, + correction, and documentation updates in any of several + ways, such as their posting to a website, their being + sent to TOE users, or arrangements made for the + developer to install the correction. In cases where the + means of providing this information requires action to + be initiated by the TOE user, the evaluator examines any + TOE guidance to ensure that it contains instructions for + retrieving the information. + + The only metric for assessing the adequacy of the method + used for providing the information, corrections and + guidance is that there be a reasonable expectation that + TOE users can obtain or receive it. For example, + consider the method of dissemination where the requisite + data is posted to a website for one month, and the TOE + users know that this will happen and when this will + happen. This may not be especially reasonable or + effective (as, say, a permanent posting to the website), + yet it is feasible that the TOE user could obtain the + necessary information. On the other hand, if the + information were posted to the website for only one + hour, yet TOE users had no way of knowing this or when + it would be posted, it is infeasible that they would + ever get the necessary information. + + + + + The evaluator shall examine the flaw remediation + procedures to determine that they describe procedures + for the developer to accept reports of security flaws or + requests for corrections to such flaws. + + The procedures ensure that TOE users have a means by + which they can communicate with the TOE developer. By + having a means of contact with the developer, the user + can report security flaws, enquire about the status of + security flaws, or request corrections to flaws. This + means of contact may be part of a more general contact + facility for reporting non-security related + problems. + + The use of these procedures is not restricted to TOE + users; however, only the TOE users are actively supplied + with the details of these procedures. Others who might + have access to or familiarity with the TOE can use the + same procedures to submit reports to the developer, who + is then expected to process them. Any means of + submitting reports to the developer, other than those + identified by the developer, are beyond the scope of + this work unit; reports generated by other means need + not be addressed. + + + + + The evaluator shall examine the flaw remediation + procedures to determine that the application of these + procedures would help to ensure every reported flaw is + corrected. + + The flaw remediation procedures cover not only those + security flaws discovered and reported by developer + personnel, but also those reported by TOE users. The + procedures are sufficiently detailed so that they + describe how it is ensured that each reported security + flaw is corrected. The procedures contain reasonable + steps that show progress leading to the eventual, + inevitable resolution. + + The procedures describe the process that is taken from + the point at which the suspected security flaw is + determined to be a security flaw to the point at which + it is resolved. + + + + The evaluator shall examine the flaw remediation + procedures to determine that the application of these + procedures would help to ensure that the TOE users are + issued remediation procedures for each security + flaw. + + The procedures describe the process that is taken from + the point at which a security flaw is resolved to the + point at which the remediation procedures are + provided. The procedures for delivering corrective + actions should be consistent with the security + objectives; they need not necessarily be identical to + the procedures used for delivering the TOE, as + documented to meet , if + included in the assurance requirements. For example, if + the hardware portion of a TOE were originally delivered + by bonded courier, updates to hardware resulting from + flaw remediation would likewise be expected to be + distributed by bonded courier. Updates unrelated to flaw + remediation would follow the procedures set forth in the + documentation meeting the requirements. + + + + The evaluator shall examine the flaw remediation + procedures to determine that the application of these + procedures would result in safeguards that the potential + correction contains no adverse effects. + + Through analysis, testing, or a combination of the two, + the developer may reduce the likelihood that adverse + effects will be introduced when a security flaw is + corrected. The evaluator assesses whether the procedures + provide detail in how the necessary mix of analysis and + testing actions is to be determined for a given + correction. + + The evaluator also determines that, for instances where + the source of the security flaw is a documentation + problem, the procedures include the means of + safeguarding against the introduction of contradictions + with other documentation. + + + + + The evaluator shall examine the flaw remediation + guidance to determine that the application of these + procedures would result in a means for the TOE user to + provide reports of suspected security flaws or requests + for corrections to such flaws. + + The guidance ensures that TOE users have a means by + which they can communicate with the TOE developer. By + having a means of contact with the developer, the user + can report security flaws, enquire about the status of + security flaws, or request corrections to flaws. + + + + + + + + In order for the developer to be able to act appropriately + upon security flaw reports from TOE users, and to know to + whom to send corrective fixes, TOE users need to + understand how to submit security flaw reports to the + developer, and how to register themselves with the + developer so that they may receive these corrective + fixes. Flaw remediation guidance from the developer to the + TOE user ensures that TOE users are aware of this + important information. + + + + The objective of this sub-activity is to determine whether + the developer has established flaw remediation procedures + that describe the tracking of security flaws, the + identification of corrective actions, and the distribution + of corrective action information to TOE + users. Additionally, this sub-activity determines whether + the developer's procedures provide for the corrections of + security flaws, for the receipt of flaw reports from TOE + users, for assurance that the corrections introduce no new + security flaws, for the establishment of a point of + contact for each TOE user, and for the timely issue of + corrective actions to TOE users. + + In order for the developer to be able to act appropriately + upon security flaw reports from TOE users, TOE users need + to understand how to submit security flaw reports to the + developer, and developers need to know how to receive + these reports. Flaw remediation guidance addressed to the + TOE user ensures that TOE users are aware of how to + communicate with the developer; flaw remediation + procedures describe the developer's role is such + communication. + + + + The evaluation evidence for this sub-activity is: + + + the flaw remediation procedures documentation; + + + flaw remediation guidance documentation. + + + + + The developer shall document and provide flaw remediation procedures + addressed to TOE developers. + + + The developer shall establish a procedure for accepting and + acting upon all reports of security flaws and requests for + corrections to those flaws. + + + The developer shall provide flaw remediation guidance + addressed to TOE users. + + + The flaw remediation procedures documentation shall describe + the procedures used to track all reported security flaws in + each release of the TOE. + + + The flaw remediation procedures shall require that a + description of the nature and effect of each security flaw + be provided, as well as the status of finding a correction + to that flaw. + + + The flaw remediation procedures shall require that + corrective actions be identified for each of the security + flaws. + + + The flaw remediation procedures documentation shall describe + the methods used to provide flaw information, corrections + and guidance on corrective actions to TOE users. + + + The flaw remediation procedures shall describe a means by + which the developer receives from TOE users reports and + enquiries of suspected security flaws in the TOE. + + + The flaw remediation procedures shall include a procedure + requiring timely response and the automatic distribution of + security flaw reports and the associated corrections to + registered users who might be affected by the security flaw. + + + The procedures for processing reported security flaws shall + ensure that any reported flaws are remediated and the + remediation procedures issued to TOE users. + + + The procedures for processing reported security flaws shall + provide safeguards that any corrections to these security + flaws do not introduce any new flaws. + + + The flaw remediation guidance shall describe a means by + which TOE users report to the developer any suspected + security flaws in the TOE. + + + The flaw remediation guidance shall describe a means by + which TOE users may register with the developer, to be + eligible to receive security flaw reports and corrections. + + + The flaw remediation guidance shall identify the specific + points of contact for all reports and enquiries about + security issues involving the TOE. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the flaw remediation + procedures documentation to determine that it describes + the procedures used to track all reported security flaws + in each release of the TOE. + + The procedures describe the actions that are taken by + the developer from the time each suspected security flaw + is reported to the time that it is resolved. This + includes the flaw's entire time frame, from initial + detection through ascertaining that the flaw is a + security flaw, to resolution of the security + flaw. + + If a flaw is discovered not to be security-relevant, + there is no need (for the purposes of the requirements) for the flaw + remediation procedures to track it further; only that + there be an explanation of why the flaw is not + security-relevant. + + + + + The evaluator shall examine the flaw remediation + procedures to determine that the application of these + procedures would produce a description of each security + flaw in terms of its nature and effects. + + The procedures identify the actions that are taken by + the developer to describe the nature and effects of each + security flaw in sufficient detail to be able to + reproduce it. The description of the nature of a + security flaw addresses whether it is an error in the + documentation, a flaw in the design of the TSF, a flaw + in the implementation of the TSF, etc. The description + of the security flaw's effects identifies the portions + of the TSF that are affected and how those portions are + affected. For example, a security flaw in the + implementation might be found that affects the + identification and authentication enforced by the TSF by + permitting authentication with the password + ``BACKDOOR''. + + + + + The evaluator shall examine the flaw remediation + procedures to determine that the application of these + procedures would identify the status of finding a + correction to each security flaw. + + The flaw remediation procedures identify the different + stages of security flaws. This differentiation includes + at least: suspected security flaws that have been + reported, suspected security flaws that have been + confirmed to be security flaws, and security flaws whose + solutions have been implemented. It is permissible that + additional stages (e.g. flaws that have been reported + but not yet investigated, flaws that are under + investigation, security flaws for which a solution has + been found but not yet implemented) be included. + + + + + The evaluator shall check the flaw remediation + procedures to determine that the application of these + procedures would identify the corrective action for each + security flaw. + + Corrective action may consist of a + repair to the hardware, firmware, or software portions + of the TOE, a modification of TOE guidance, or + both. Corrective action that constitutes modifications + to TOE guidance (e.g. details of procedural measures to + be taken to obviate the security flaw) includes both + those measures serving as only an interim solution + (until the repair is issued) as well as those serving as + a permanent solution (where it is determined that the + procedural measure is the best solution). + + If the source of the security flaw is a documentation + error, the corrective action consists of an update of + the affected TOE guidance. If the corrective action is a + procedural measure, this measure will include an update + made to the affected TOE guidance to reflect these + corrective procedures. + + + + + The evaluator shall examine the flaw remediation + procedures documentation to determine that it describes + a means of providing the TOE users with the necessary + information on each security flaw. + + The necessary information about each + security flaw consists of its description (not + necessarily at the same level of detail as that provided + as part of work unit ), the prescribed corrective action, + and any associated guidance on implementing the + correction. + + TOE users may be provided with such information, + correction, and documentation updates in any of several + ways, such as their posting to a website, their being + sent to TOE users, or arrangements made for the + developer to install the correction. In cases where the + means of providing this information requires action to + be initiated by the TOE user, the evaluator examines any + TOE guidance to ensure that it contains instructions for + retrieving the information. + + The only metric for assessing the adequacy of the method + used for providing the information, corrections and + guidance is that there be a reasonable expectation that + TOE users can obtain or receive it. For example, + consider the method of dissemination where the requisite + data is posted to a website for one month, and the TOE + users know that this will happen and when this will + happen. This may not be especially reasonable or + effective (as, say, a permanent posting to the website), + yet it is feasible that the TOE user could obtain the + necessary information. On the other hand, if the + information were posted to the website for only one + hour, yet TOE users had no way of knowing this or when + it would be posted, it is infeasible that they would + ever get the necessary information. + + For TOE users who register with the developer (see work + unit ), the + passive availability of this information is not + sufficient. Developers must actively send the + information (or a notification of its availability) to + registered TOE users. + + + + + The evaluator shall examine the flaw remediation + procedures to determine that the application of these + procedures would result in a means for the developer to + receive from TOE user reports of suspected security + flaws or requests for corrections to such flaws. + + The procedures ensure that TOE users have a means by + which they can communicate with the TOE developer. By + having a means of contact with the developer, the user + can report security flaws, enquire about the status of + security flaws, or request corrections to flaws. This + means of contact may be part of a more general contact + facility for reporting non-security related + problems. + + The use of these procedures is not restricted to TOE + users; however, only the TOE users are actively supplied + with the details of these procedures. Others who might + have access to or familiarity with the TOE can use the + same procedures to submit reports to the developer, who + is then expected to process them. Any means of + submitting reports to the developer, other than those + identified by the developer, are beyond the scope of + this work unit; reports generated by other means need + not be addressed. + + + + + The evaluator shall examine the flaw remediation + procedures to determine that the application of these + procedures would result in a timely means of providing + the registered TOE users who might be affected with + reports about, and associated corrections to, each + security flaw. + + The issue of timeliness applies to the issuance of both + security flaw reports and the associated + corrections. However, these need not be issued at the + same time. It is recognised that flaw reports should be + generated and issued as soon as an interim solution is + found, even if that solution is as drastic as turn off + the TOE. Likewise, when a more permanent (and less + drastic) solution is found, it should be issued without + undue delay. + + It is unnecessary to restrict the recipients of the + reports and associated corrections to only those TOE + users who might be affected by the security flaw; it is + permissible that all TOE users be given such reports and + corrections for all security flaws, provided such is + done in a timely manner. + + + + The evaluator shall examine the flaw remediation + procedures to determine that the application of these + procedures would result in automatic distribution of the + reports and associated corrections to the registered TOE + users who might be affected. + + Automatic distribution does not mean + that human interaction with the distribution method is + not permitted. In fact, the distribution method could + consist entirely of manual procedures, perhaps through a + closely monitored procedure with prescribed escalation + upon the lack of issue of reports or corrections. + + It is unnecessary to restrict the recipients of the + reports and associated corrections to only those TOE + users who might be affected by the security flaw; it is + permissible that all TOE users be given such reports and + corrections for all security flaws, provided such is + done automatically. + + + + + The evaluator shall examine the flaw remediation procedures to + determine that the application of these procedures would help to + ensure that every reported flaw is corrected. + + The flaw remediation procedures cover not only those + security flaws discovered and reported by developer + personnel, but also those reported by TOE users. The + procedures are sufficiently detailed so that they + describe how it is ensured that each reported security + flaw is remediated. The procedures contain reasonable + steps that show progress leading to the eventual, + inevitable resolution. + + The procedures describe the process that is taken from + the point at which the suspected security flaw is + determined to be a security flaw to the point at which + it is resolved. + + + + + The evaluator shall examine the flaw remediation + procedures to determine that the application of these + procedures would help to ensure that the TOE users are + issued remediation procedures for each security + flaw. + The procedures describe the process that is taken + from the point at which a security flaw is resolved to + the point at which the remediation procedures are + provided. The procedures for delivering remediation + procedures should be consistent with the security + objectives; they need not necessarily be identical to + the procedures used for delivering the TOE, as + documented to meet , if + included in the assurance requirements. For example, if + the hardware portion of a TOE were originally delivered + by bonded courier, updates to hardware resulting from + flaw remediation would likewise be expected to be + distributed by bonded courier. Updates unrelated to flaw + remediation would follow the procedures set forth in the + documentation meeting the requirements. + + + + The evaluator shall examine the flaw remediation + procedures to determine that the application of these + procedures would result in safeguards that the potential + correction contains no adverse effects. + + Through analysis, testing, or a combination of the two, + the developer may reduce the likelihood that adverse + effects will be introduced when a security flaw is + corrected. The evaluator assesses whether the procedures + provide detail in how the necessary mix of analysis and + testing actions is to be determined for a given + correction. + + The evaluator also determines that, for instances where + the source of the security flaw is a documentation + problem, the procedures include the means of + safeguarding against the introduction of contradictions + with other documentation. + + + + + The evaluator shall examine the flaw remediation + guidance to determine that the application of these + procedures would result in a means for the TOE user to + provide reports of suspected security flaws or requests + for corrections to such flaws. + + The guidance ensures that TOE users have a means by + which they can communicate with the TOE developer. By + having a means of contact with the developer, the user + can report security flaws, enquire about the status of + security flaws, or request corrections to flaws. + + + + + The evaluator shall examine the flaw remediation + guidance to determine that it describes a means of + enabling the TOE users to register with the + developer. + + Enabling the TOE users to register with the + developer simply means having a way for each + TOE user to provide the developer with a point of + contact; this point of contact is to be used to + provide the TOE user with information related to + security flaws that might affect that TOE user, along + with any corrections to the security flaw. Registering + the TOE user may be accomplished as part of the + standard procedures that TOE users undergo to identify + themselves to the developer, for the purposes of + registering a software licence, or for obtaining + update and other useful information. + + There need not be one registered TOE user per + installation of the TOE; it would be sufficient if there + were one registered TOE user for an organisation. For + example, a corporate TOE user might have a centralised + acquisition office for all of its sites. In this case, + the acquisition office would be a sufficient point of + contact for all of that TOE user's sites, so that all of + the TOE user's installations of the TOE have a + registered point of contact. + + In either case, it must be possible to associate each + TOE that is delivered with an organisation in order to + ensure that there is a registered user for each TOE. For + organisations that have many different addresses, this + assures that there will be no user who is erroneously + presumed to be covered by a registered TOE user. + It should be noted that TOE users need not + register; they must only be provided with a means of + doing so. However, users who choose to register must be + directly sent the information (or a notification of its + availability). + + + + The evaluator shall examine the flaw remediation + guidance to determine that it identifies specific points + of contact for user reports and enquiries about security + issues involving the TOE. + + The guidance includes a means whereby registered TOE + users can interact with the developer to report + discovered security flaws in the TOE or to make + enquiries regarding discovered security flaws in the + TOE. + + + + + + + + Poorly controlled development and maintenance of the TOE can + result in a TOE that does not meet all of its + SFRs. Therefore, it is important that a model for the + development and maintenance of a TOE be established as early + as possible in the TOE's life-cycle. + + Using a model for the development and maintenance of a TOE + does not guarantee that the TOE meets all of its SFRs. It is + possible that the model chosen will be insufficient or + inadequate and therefore no benefits in the quality of the + TOE can be observed. Using a life-cycle model that has been + approved by a group of experts (e.g. academic experts, + standards bodies) improves the chances that the development + and maintenance models will contribute to the TOE meeting + its SFRs. The use of a life-cycle model including some + quantitative valuation adds further assurance in the overall + quality of the TOE development process. + + + + Life-cycle definition establishes that the engineering + practises used by a developer to produce the TOE include the + considerations and activities identified in the development + process and operational support requirements. Confidence in + the correspondence between the requirements and the TOE is + greater when quality control and the production of evidence + are done on a regular basis as an integral part of the + development process and operational support activities. It + is not the intent of this component to dictate any specific + development process. + + + + The components in this family are levelled on the basis of + increasing requirements for measurability of the life-cycle + model, and for compliance with that model. + + + + A life-cycle model encompasses the procedures, tools and + techniques used to develop and maintain the TOE. Aspects of + the process that may be covered by such a model include + design methods, review procedures, project management + controls, change control procedures, test methods and + acceptance procedures. An effective life-cycle model will + address these aspects of the development and maintenance + process within an overall management structure that assigns + responsibilities and monitors progress. + + There are different types of acceptance situations that are + dealt with at different locations in the criteria: + acceptance of parts delivered by subcontractors + (``integration'') should be treated in this family , acceptance subsequent to + internal transportations in , acceptance of parts into the CM system in + , and acceptance of the + delivered TOE by the consumer in . The first three types may overlap. + + Although life-cycle definition deals with the maintenance of + the TOE and hence with aspects becoming relevant after the + completion of the evaluation, its evaluation adds assurance + through an analysis of the life-cycle information for the + TOE provided at the time of the evaluation. + + A life-cycle model provides for the necessary control over + the development and maintenance of the TOE, if the model + enables sufficient minimisation of the danger that the TOE + will not meet its security requirement. + + A measurable life-cycle model is a model using some + quantitative valuation (arithmetic parameters and/or + metrics) of the managed product in order to measure + development properties of the product. Typical metrics are + source code complexity metrics, defect density (errors per + size of code) or mean time to failure. For the security + evaluation all those metrics are of relevance, which are + used to increase quality by decreasing the probability of + faults and thereby in turn increasing assurance in the + security of the TOE. + + One should take into account that there exist standardised + life cycle models on the one hand (like the waterfall model) + and standardised metrics on the other hand (like error + density), which may be combined. The CC does not require the + life cycle to follow exactly one standard defining both + aspects. + + + + The objective of this sub-activity is to determine + whether the developer has used a documented model of the + TOE life-cycle. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the life-cycle definition documentation. + + + + + The developer shall establish a life-cycle model to be used + in the development and maintenance of the TOE. + + + The developer shall provide life-cycle definition + documentation. + + + The life-cycle definition documentation shall describe the + model used to develop and maintain the TOE. + + + The life-cycle model shall provide for the necessary control + over the development and maintenance of the TOE. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the documented description + of the life-cycle model used to determine that it covers + the development and maintenance process. + + The description of the life-cycle model should include: + + + information on the life-cycle phases of the TOE and + the boundaries between the subsequent phases; + + + information on the procedures, tools and techniques + used by the developer (e.g. for design, coding, + testing, bug-fixing); + + + overall management structure governing the + application of the procedures (e.g. an + identification and description of the individual + responsibilities for each of the procedures required + by the development and maintenance process covered + by the life-cycle model); + + + information on which parts of the TOE are delivered + by subcontractors, if subcontractors are involved. + + + + does not require the + model used to conform to any standard life-cycle + model. + + + + + The evaluator shall examine the life-cycle model to + determine that use of the procedures, tools and + techniques described by the life-cycle model will make + the necessary positive contribution to the development + and maintenance of the TOE. + + The information provided in the life-cycle model gives + the evaluator assurance that the development and + maintenance procedures adopted would minimise the + likelihood of security flaws. For example, if the + life-cycle model described the review process, but did + not make provision for recording changes to components, + then the evaluator may be less confident that errors + will not be introduced into the TOE. The evaluator may + gain further assurance by comparing the description of + the model against an understanding of the development + process gleaned from performing other evaluator actions + relating to the TOE development (e.g. those covered + under the ). + Identified deficiencies in the life-cycle model will be + of concern if they might reasonably be expected to give + rise to the introduction of flaws into the TOE, either + accidentally or deliberately. + + The CC does not mandate any particular development + approach, and each should be judged on merit. For + example, spiral, rapid-prototyping and waterfall + approaches to design can all be used to produce a + quality TOE if applied in a controlled + environment. + + + + + + + The objective of this sub-activity is to determine + whether the developer has used a documented and measurable + model of the TOE life-cycle. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the life-cycle definition documentation; + + + information about the standard used; + + + the life-cycle output documentation. + + + + + The developer shall establish a life-cycle model to be used + in the development and maintenance of the TOE, that is based + on a measurable life-cycle model. + + + The developer shall provide life-cycle definition + documentation. + + + The developer shall measure the TOE development using the + measurable life-cycle model. + + + The developer shall provide life-cycle output documentation. + + + The life-cycle definition documentation shall describe the + model used to develop and maintain the TOE, including the + details of its arithmetic parameters and/or metrics used to + measure the quality of the TOE and/or its development. + + + The life-cycle model shall provide for the necessary control + over the development and maintenance of the TOE. + + + The life-cycle output documentation shall provide the + results of the measurements of the TOE development using the + measurable life-cycle model. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the documented description + of the life-cycle model used to determine that it covers + the development and maintenance process, including the + details of its arithmetic parameters and/or metrics used + to measure the TOE development. + + The description of the life-cycle model includes: + + information on the life-cycle phases of the TOE and the + boundaries between the subsequent phases; + + information on the procedures, tools and techniques used by + the developer (e.g. for design, coding, testing, + bug-fixing); + + overall management structure governing the application of + the procedures (e.g. an identification and description of + the individual responsibilities for each of the procedures + required by the development and maintenance process covered + by the life-cycle model); + + information on which parts of the TOE are delivered by + subcontractors, if subcontractors are involved; + + information on the parameters/metrics that are used to + measure the TOE development. Metrics standards typically + include guides for measuring and producing reliable products + and cover the aspects reliability, quality, performance, + complexity and cost. For the evaluation all those metrics + are of relevance, which are used to increase quality by + decreasing the probability of faults and thereby in turn + increase assurance in the security of the TOE. + + + + + + The evaluator shall examine the life-cycle model to + determine that use of the procedures, tools and + techniques described by the life-cycle model will make + the necessary positive contribution to the development + and maintenance of the TOE. + + The information provided in the life-cycle model gives + the evaluator assurance that the development and + maintenance procedures adopted would minimise the + likelihood of security flaws. For example, if the + life-cycle model described the review process, but did + not make provision for recording changes to components, + then the evaluator may be less confident that errors + will not be introduced into the TOE. The evaluator may + gain further assurance by comparing the description of + the model against an understanding of the development + process gleaned from performing other evaluator actions + relating to the TOE development (e.g. those covered + under the ). + Identified deficiencies in the life-cycle model will be + of concern if they might reasonably be expected to give + rise to the introduction of flaws into the TOE, either + accidentally or deliberately. + + The CC does not mandate any particular development + approach, and each should be judged on merit. For + example, spiral, rapid-prototyping and waterfall + approaches to design can all be used to produce a + quality TOE if applied in a controlled + environment. + + For the metrics/measurements used in the life-cycle + model, evidence has to be provided that shows how those + metrics/measurements usefully contribute to the + minimisation of the likelihood of flaws. This can be + viewed as the overall goal for measurement in an context. As a consequence the + metrics/measurements have to be selected based on their + capability to achieve that overall goal or contribute to + that. In the first place a metric/measure is suitable + with respect to if a + correlation between the metric/measure and the number of + flaws can be stated with a certain degree of + reliability. But also a metric/measure useful for + management purposes as for planning and monitoring the + TOE development are helpful since badly managed projects + are endangered to produce bad quality and to introduce + flaws. + + It may be possible to use metrics for quality + improvement, for which this use is not obvious. For + example a metric to estimate the expected cost of a + product development may help quality, if the developer + can show that this is used to provide an adequate budget + for development projects and that this helps to avoid + quality problems arising from resource shortages. + + It is not required that every single step in the life + cycle of the TOE is measurable. However the evaluator + should see from the description of the measures and + procedures that the metrics are appropriate to control + the overall quality of the TOE and to minimise possible + security flaws by this. + + + + + The evaluator shall examine the life-cycle output + documentation to determine that it provides the results + of the measurements of the TOE development using the + measurable life-cycle model. + + The results of the measurements and the life-cycle + progress of the TOE should be in accordance with the + life-cycle model. + + The output documentation not only includes numeric values of the + metrics but also documents actions taken as a result of the + measurements and in accordance with the model. For example there + may be a requirement that a certain design phase needs to be + repeated, if some error rates measured during testing are + outside of a defined threshold. In this case the documentation + should show that such action was taken, if indeed the thresholds + were not met. + + If the evaluation is conducted in parallel with the + development of the TOE it may be possible that quality + measurements have not been used in the past. In this + case the evaluator should use the documentation of the + planned procedures in order to gain confidence that + corrective actions are defined if results of quality + measurements deviate from some threshold. + + + + + + + + Tools and techniques is an aspect of selecting tools that + are used to develop, analyse and implement the TOE. It + includes requirements to prevent ill-defined, inconsistent + or incorrect development tools from being used to develop + the TOE. This includes, but is not limited to, programming + languages, documentation, implementation standards, and + other parts of the TOE such as supporting runtime + libraries. + + + + Tools and techniques addresses the need to define the + development tools being used to analyse and implement the + TOE. It includes requirements concerning the development + tools and implementation dependent options of those + tools. + + + + The components in this family are levelled on the basis of + increasing requirements on the description and scope of the + implementation standards and the documentation of + implementation-dependent options. + + + + There is a requirement for well-defined development + tools. These are tools that are clearly and completely + described. For example, programming languages and computer + aided design (CAD) systems that are based on a standard + published by standards bodies are considered to be + well-defined. Self-made tools would need further + investigation to clarify whether they are + well-defined. + + The requirement in is + especially applicable to programming languages so as to + ensure that all statements in the source code have an + unambiguous meaning. + + In and , implementation guidelines may be accepted + as an implementation standard if they have been approved by + some group of experts (e.g. academic experts, standards + bodies). Implementation standards are normally public, well + accepted and common practise in a specific industry, but + developer-specific implementation guidelines may also be + accepted as a standard; the emphasis is on the + expertise. + Tools and techniques distinguishes between the + implementation standards applied by the developer () and the implementation + standards for ``all parts of the TOE'' () which include third party software, + hardware, or firmware. The configuration list introduced in + requires that for each TSF + relevant configuration item to indicate if it has been + generated by the TOE developer or by third party + developers. + + + + + + The objective of this sub-activity is to determine whether + the developer has used well-defined development tools + (e.g. programming languages or computer-aided design (CAD) + systems) that yield consistent and predictable + results. + + + + This work may be performed in parallel with the evaluation + activities under , + specifically with regard to determining the use of + features in the tools that will affect the object code + (e.g. compilation options). + + + + The evaluation evidence for this sub-activity is: + + + the development tool documentation; + + + the subset of the implementation representation. + + + + + The developer shall provide the documentation identifying each development tool being + used for the TOE. + + + The developer shall document and provide the selected + implementation-dependent options of each development tool. + + + Each development tool used for implementation shall be + well-defined. + + + The documentation of each development tool shall + unambiguously define the meaning of all statements as well + as all conventions and directives used in the + implementation. + + + The documentation of each development tool shall + unambiguously define the meaning of all + implementation-dependent options. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the development tool + documentation provided to determine that each + development tools is well-defined. + + For example, a well-defined language, compiler or CAD + system may be considered to be one that conforms to a + recognised standard, such as the ISO standards. A + well-defined language is one that has a clear and + complete description of its syntax, and a detailed + description of the semantics of each construct. + + + + + The evaluator shall examine the documentation of each + development tool to determine that it unambiguously + defines the meaning of all statements as well as all + conventions and directives used in the + implementation. + + The development tool documentation (e.g. programming + language specifications and user manuals) should cover + all statements used in the implementation representation + of the TOE, and for each such statement should provide a + clear and unambiguous definition of the purpose and + effect of that statement. This work may be performed in + parallel with the evaluator's examination of the + implementation representation performed during the sub-activity. The key test the + evaluator should apply is whether or not the + documentation is sufficiently clear for the evaluator to + be able to understand the implementation + representation. The documentation should not assume (for + example) that the reader is an expert in the programming + language used. + + Reference to the use of a documented standard is an + acceptable approach to meet this requirement, provided + that the standard is available to the evaluator. Any + differences from the standard should be + documented. + + The critical test is whether the evaluator can + understand the TOE source code when performing source + code analysis covered in the sub-activity. However, the following + checklist can additionally be used in searching for + problem areas: + + + In the language definition, phrases such as ``the + effect of this construct is undefined'' and terms + such as ``implementation dependent'' or + ``erroneous'' may indicate ill-defined areas. + + + Aliasing (allowing the same piece of memory to be + referenced in different ways) is a common source of + ambiguity problems. + + + Exception handling (e.g. what happens after memory + exhaustion or stack overflow) is often poorly + defined. + + + + Most languages in common use, however well designed, + will have some problematic constructs. If the + implementation language is mostly well defined, but some + problematic constructs exist, then an inconclusive + verdict should be assigned, pending examination of the + source code. + + The evaluator should verify, during the examination of + source code, that any use of the problematic constructs + does not introduce vulnerabilities. The evaluator should + also ensure that constructs precluded by the documented + standard are not used. + + The development tool documentation should define all + conventions and directives used in the + implementation. + + + + + The evaluator shall examine the development tool + documentation to determine that it unambiguously defines + the meaning of all implementation-dependent + options. + + The documentation of software development tools should + include definitions of implementation-dependent options + that may affect the meaning of the executable code, and + those that are different from the standard language as + documented. Where source code is provided to the + evaluator, information should also be provided on + compilation and linking options used. + + The documentation for hardware design and development + tools should describe the use of all options that affect + the output from the tools (e.g. detailed hardware + specifications, or actual hardware). + + + + + + + + The objective of this sub-activity is to determine whether + the developer has used well-defined development tools + (e.g. programming languages or computer-aided design (CAD) + systems) that yield consistent and predictable results, + and whether implementation standards have been + applied. + + + + This work may be performed in parallel with the evaluation + activities under , + specifically with regard to determining the use of + features in the tools that will affect the object code + (e.g. compilation options). + + + + The evaluation evidence for this sub-activity is: + + + the development tool documentation; + + + the implementation standards description; + + + the provided implementation representation of the TSF. + + + + + The developer shall provide the documentation identifying each development tool being + used for the TOE. + + + The developer shall document and provide the selected + implementation-dependent options of each development tool. + + + The developer shall describe and provide the implementation standards + that are being applied by the developer. + + + Each development tool used for implementation shall be + well-defined. + + + The documentation of each development tool shall + unambiguously define the meaning of all statements as well + as all conventions and directives used in the + implementation. + + + The documentation of each development tool shall + unambiguously define the meaning of all + implementation-dependent options. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the development tool + documentation provided to determine that each + development tool is well-defined. + + For example, a well-defined language, compiler or CAD + system may be considered to be one that conforms to a + recognised standard, such as the ISO standards. A + well-defined language is one that has a clear and + complete description of its syntax, and a detailed + description of the semantics of each construct. + + + + + The evaluator shall examine the documentation of each + development tool to determine that it unambiguously + defines the meaning of all statements as well as all + conventions and directives used in the + implementation. + + The development tool documentation (e.g. programming + language specifications and user manuals) should cover + all statements used in the implementation representation + of the TOE, and for each such statement should provide a + clear and unambiguous definition of the purpose and + effect of that statement. This work may be performed in + parallel with the evaluator's examination of the + implementation representation performed during the sub-activity. The key test the + evaluator should apply is whether or not the + documentation is sufficiently clear for the evaluator to + be able to understand the implementation + representation. The documentation should not assume (for + example) that the reader is an expert in the programming + language used. + + Reference to the use of a documented standard is an + acceptable approach to meet this requirement, provided + that the standard is available to the evaluator. Any + differences from the standard should be + documented. + + The critical test is whether the evaluator can + understand the TOE source code when performing source + code analysis covered in the sub-activity. However, the following + checklist can additionally be used in searching for + problem areas: + + + In the language definition, phrases such as ``the + effect of this construct is undefined'' and terms + such as ``implementation dependent'' or + ``erroneous'' may indicate ill-defined areas. + + + Aliasing (allowing the same piece of memory to be + referenced in different ways) is a common source of + ambiguity problems. + + + Exception handling (e.g. what happens after memory + exhaustion or stack overflow) is often poorly + defined. + + + + Most languages in common use, however well designed, + will have some problematic constructs. If the + implementation language is mostly well defined, but some + problematic constructs exist, then an inconclusive + verdict should be assigned, pending examination of the + source code. + + The evaluator should verify, during the examination of + source code, that any use of the problematic constructs + does not introduce vulnerabilities. The evaluator should + also ensure that constructs precluded by the documented + standard are not used. + + The development tool documentation should define all + conventions and directives used in the + implementation. + + + + + The evaluator shall examine the development tool + documentation to determine that it unambiguously defines + the meaning of all implementation-dependent + options. + + The documentation of software development tools should + include definitions of implementation-dependent options + that may affect the meaning of the executable code, and + those that are different from the standard language as + documented. Where source code is provided to the + evaluator, information should also be provided on + compilation and linking options used. + + The documentation for hardware design and development + tools should describe the use of all options that affect + the output from the tools (e.g. detailed hardware + specifications, or actual hardware). + + + + The evaluator shall confirm that the implementation + standards have been applied. + + + The evaluator shall examine aspects of the + implementation process to determine that documented + implementation standards have been applied. + + This work unit requires the evaluator to analyse the + provided implementation representation of the TOE to + determine whether the documented implementation + standards have been applied. + + The evaluator should verify that constructs excluded by + the documented standard are not used. + + Additionally, the evaluator should verify the + developer's procedures which ensure the application of + the defined standards within the design and + implementation process of the TOE. Therefore, + documentary evidence should be supplemented by visiting + the development environment. A visit to the development + environment will allow the evaluator to: + + + observe the application of defined standards; + + examine documentary evidence of application of + procedures describing the use of defined + standards; + + interview development staff to check awareness of + the application of defined standards and + procedures. + + A development site visit is a useful means of gaining + confidence in the procedures being used. Any decision + not to make such a visit should be determined in + consultation with the evaluation authority. + + The evaluator compares the provided implementation + representation with the description of the applied + implementation standards and verifies their use. + At this level it is not required that the complete + provided implementation representation of the TSF is + based on implementation standards, but only those parts + that are developed by the TOE developer himself. The + evaluator may consult the configuration list required by + the to get the + information which parts are developed by the TOE + developer, and which by third party developers. + + If the referenced implementation standards are not + applied for at least parts of the provided implementation representation, + the evaluator action related to this work unit is assigned a fail verdict. + + Note that parts of the TOE which are not TSF relevant do + not need to be examined. + + This work unit may be performed in conjunction with the + evaluation activities under . + + + + + + + The objective of this sub-activity is to determine whether + the developer and his subcontractors have used + well-defined development tools (e.g. programming languages + or computer-aided design (CAD) systems) that yield + consistent and predictable results, and whether + implementation standards have been applied. + + + + This work may be performed in parallel with the evaluation + activities under , + specifically with regard to determining the use of + features in the tools that will affect the object code + (e.g. compilation options). + + + + The evaluation evidence for this sub-activity is: + + + the development tool documentation; + + + the implementation standards description; + + + the provided implementation representation of the TSF. + + + + + The developer shall provide the documentation identifying each development tool being + used for the TOE. + + + The developer shall document and provide the selected + implementation-dependent options of each development tool. + + + The developer shall describe and provide the implementation standards + that are being applied by the developer and by any + third-party providers for all parts of the TOE. + + + Each development tool used for implementation shall be + well-defined. + + + The documentation of each development tool shall + unambiguously define the meaning of all statements as well + as all conventions and directives used in the + implementation. + + + The documentation of each development tool shall + unambiguously define the meaning of all + implementation-dependent options. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the development tool + documentation provided to determine that each + development tool is well-defined. + + For example, a well-defined language, compiler or CAD + system may be considered to be one that conforms to a + recognised standard, such as the ISO standards. A + well-defined language is one that has a clear and + complete description of its syntax, and a detailed + description of the semantics of each construct. + + At this level, the documentation of development tools + used by third party contributors to the TOE has to be + included in the evaluator's examination. + + + + + The evaluator shall examine the documentation of each + development tool to determine that it unambiguously + defines the meaning of all statements as well as all + conventions and directives used in the + implementation. + + The development tool documentation (e.g. programming + language specifications and user manuals) should cover + all statements used in the implementation representation + of the TOE, and for each such statement should provide a + clear and unambiguous definition of the purpose and + effect of that statement. This work may be performed in + parallel with the evaluator's examination of the + implementation representation performed during the sub-activity. The key test the + evaluator should apply is whether or not the + documentation is sufficiently clear for the evaluator to + be able to understand the implementation + representation. The documentation should not assume (for + example) that the reader is an expert in the programming + language used. + + Reference to the use of a documented standard is an + acceptable approach to meet this requirement, provided + that the standard is available to the evaluator. Any + differences from the standard should be + documented. + + The critical test is whether the evaluator can + understand the TOE source code when performing source + code analysis covered in the sub-activity. However, the following + checklist can additionally be used in searching for + problem areas: + + + In the language definition, phrases such as ``the + effect of this construct is undefined'' and terms + such as ``implementation dependent'' or + ``erroneous'' may indicate ill-defined areas. + + + Aliasing (allowing the same piece of memory to be + referenced in different ways) is a common source of + ambiguity problems. + + + Exception handling (e.g. what happens after memory + exhaustion or stack overflow) is often poorly + defined. + + + + Most languages in common use, however well designed, + will have some problematic constructs. If the + implementation language is mostly well defined, but some + problematic constructs exist, then an inconclusive + verdict should be assigned, pending examination of the + source code. + + The evaluator should verify, during the examination of + source code, that any use of the problematic constructs + does not introduce vulnerabilities. The evaluator should + also ensure that constructs precluded by the documented + standard are not used. + + The development tool documentation should define all + conventions and directives used in the + implementation. + + At this level, the documentation of development tools + used by third party contributors to the TOE has to be + included in the evaluator's examination. + + + + + The evaluator shall examine the development tool + documentation to determine that it unambiguously defines + the meaning of all implementation-dependent + options. + + The documentation of software development tools should + include definitions of implementation-dependent options + that may affect the meaning of the executable code, and + those that are different from the standard language as + documented. Where source code is provided to the + evaluator, information should also be provided on + compilation and linking options used. + + The documentation for hardware design and development + tools should describe the use of all options that affect + the output from the tools (e.g. detailed hardware + specifications, or actual hardware). + + At this level, the documentation of development tools + used by third party contributors to the TOE has to be + included in the evaluator's examination. + + + + The evaluator shall confirm that the implementation + standards have been applied. + + + The evaluator shall examine aspects of the + implementation process to determine that documented + implementation standards have been applied. + + This work unit requires the evaluator to analyse the + provided implementation representation of the TOE to + determine whether the documented implementation + standards have been applied. + + The evaluator should verify that constructs excluded by + the documented standard are not used. + + Additionally, the evaluator should verify the + developer's procedures which ensure the application of + the defined standards within the design and + implementation process of the TOE. Therefore, + documentary evidence should be supplemented by visiting + the development environment. A visit to the development + environment will allow the evaluator to: + + + observe the application of defined standards; + + examine documentary evidence of application of + procedures describing the use of defined + standards; + + interview development staff to check awareness of + the application of defined standards and + procedures. + + A development site visit is a useful means of gaining + confidence in the procedures being used. Any decision + not to make such a visit should be determined in + consultation with the evaluation authority. + + The evaluator compares the provided implementation + representation with the description of the applied + implementation standards and verifies their use. + At this level it is required that the complete + provided implementation representation of the TSF is + based on implementation standards, including third party + contributions. This may require the evaluator to visit + the sites of contributors. The evaluator may consult the + configuration list required by the to see who has developed which part of + the TOE. + + Note that parts of the TOE which are not TSF relevant do + not need to be examined. + + This work unit may be performed in conjunction with the + evaluation activities under . + + + + + + + + + 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. + + This Clause should be used in conjunction with Annexes , and + in CC + Part 1, as these Annexes clarify the concepts here and provide + many examples. + This standard defines two assurance packages for PP evaluation as follows: + Low assurance PP evaluation package;(Standard) PP evaluation package. + The assurance components for these packages are defined by table + .Assurance classAssurance familyAssurance componentLow Assurance PPPPProtection Profile evaluation11111112121PP assurance packages
+ + + + Assurance class defines + requirements for the evaluation of an PP to demonstrate that + the PP is sound and internally consistent, and, if the PP is + based on one or more PPs or packages, that the PP is a correct + instantiation of these PPs and packages. + + + + This Clause describes the evaluation of a PP. The + requirements and methodology for PP evaluation are identical + for each PP evaluation, regardless of the EAL (or other set of + assurance requirements) that is claimed in the PP. The + evaluation methodology in this Clause is based on the + requirements on the PP as specified in CC Part 3 class . + + This Clause should be used in conjunction with Annexes , and + in CC + Part 1, as these Annexes clarify the concepts here and provide + many examples. + + + + The PP is the description of a TOE type. As such it is + expected to identify the security requirements that enforce + the defined OSPs and counter the defined threats under the + defined assumptions. + + 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 PPs or packages, that the PP is a correct + instantiation of these PPs or packages. These properties are + necessary for the PP to be suitable for use as the basis for + an ST or another PP. + + + + + While evaluating a PP that is based on one or more certified + PPs, it may be possible to re-use the fact that these PPs were + certified. The potential for re-use of the result of a certified + PP is greater if the PP under evaluation does not add threats, + OSPs, security objectives and/or security requirements to those + of the PP that conformance is being claimed to. If the PP under + evaluation contains much more than the certified PP, re-use may + not be useful at all. + + The evaluator is allowed to re-use the PP evaluation results + by doing certain analyses only partially or not at all if + these analyses or parts thereof were already done as part of + the PP evaluation. While doing this, the evaluator should + assume that the analyses in the PP were performed + correctly. + + An example would be where the PP that conformance is being + claimed to contains a set of security requirements, and these + were determined to be internally consistent during its + evaluation. If the PP under evaluation uses the exact same + requirements, the consistency analysis does not have to be + repeated during the PP evaluation. If the PP under evaluation + adds one or more requirements, or performs operations on these + requirements, the analysis will have to be repeated. However, it + may be possible to save work in this consistency analysis by + using the fact that the original requirements are internally + consistent. If the original requirements are internally + consistent, the evaluator only has to determine that: + + the set of all new and/or changed requirements is internally + consistent, and + + the set of all new and/or changed requirements is consistent + with the original requirements. + + The evaluator notes in the ETR each case where analyses + are not done or only partially done for this reason. + + + + + + The objective of this family is to describe the TOE in a + narrative way. + + Evaluation of the PP introduction is required to demonstrate + that the PP is correctly identified, and that the PP + reference and TOE overview are consistent with each + other. + + + + The PP introduction describes the TOE in a narrative + way. + + + + + The objective of this sub-activity is to determine whether + the PP is correctly identified, and whether the PP + reference and TOE overview are consistent with each + other. + + + + The evaluation evidence for this sub-activity is: + + + the PP. + + + + + The developer shall provide a PP introduction. + + + The PP introduction shall contain a PP reference and a TOE + overview. + + + The PP reference shall uniquely identify the PP. + + + The TOE overview shall summarise the usage and major + security features of the TOE. + + + The TOE overview shall identify the TOE type. + + + The TOE overview shall identify any non-TOE + hardware/software/firmware available to the TOE. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the PP introduction + contains a PP reference and a TOE overview. + + + + + The evaluator shall examine the PP reference to + determine that it uniquely identifies the PP. + + The evaluator determines that the PP reference + identifies the PP itself, so that it may be easily + distinguished from other PPs, and that it also uniquely + identifies each version of the PP, e.g. by including a + version number and/or a date of publication. + + The PP should have some referencing system that is + capable of supporting unique references (e.g. use of + numbers, letters or dates). + + + + + The evaluator shall examine the TOE overview to + determine that it describes the usage and major security + features of the TOE. + + The TOE overview should briefly (i.e. several + paragraphs) describe the usage and major security + features expected of the TOE. The TOE overview should + enable consumers and potential TOE developers to quickly + determine whether the PP is of interest to them. + + The evaluator determines that the overview is clear + enough for TOE developers and consumers, and sufficient + to give them a general understanding of the intended + usage and major security features of the TOE. + + + + + The evaluator shall check that the TOE overview + identifies the TOE type. + + + + + The evaluator shall examine the TOE overview to + determine that it identifies any non-TOE + hardware/software/firmware available to the TOE. + + While some TOEs may run stand-alone, other TOEs (notably + software TOEs) need additional hardware, software or + firmware to operate. In this subclause of the PP, the PP + author lists all hardware, software, and/or firmware + that will be available for the TOE to run on. + + This identification should be detailed enough for + potential consumers and TOE developers to determine + whether their TOE may operate with the listed hardware, + software and firmware. + + + + + + + + The objective of this family is to determine the validity of + the conformance claim. In addition, this family specifies + how STs and other PPs are to claim conformance with the + PP. + + + + Conformance claims describes how the Protection Profile + conforms to CC Part 2 and CC Part 3, to Protection Profiles + and to packages. + + + + + + + + The objective of this sub-activity is to determine the + validity of various conformance claims. These describe how + the PP conforms to the CC, other PPs and packages. + + + + The evaluation evidence for this sub-activity is: + + + the PP; + + + the PP(s) that the PP claims conformance to; + + + the package(s) that the PP claims conformance to. + + + + + The developer shall provide a conformance claim. + + + The developer shall provide a conformance claim rationale. + + + The developer shall provide a conformance statement. + + + The conformance claim shall contain a CC conformance claim + that identifies the version of the CC to which the PP claims + conformance. + + + The CC conformance claim shall describe the conformance of + the PP to CC Part 2 as either CC Part 2 conformant or CC + Part 2 extended. + + + The CC conformance claim shall describe the conformance of + the PP to CC Part 3 as either CC Part 3 conformant or CC + Part 3 extended. + + + The CC conformance claim shall be consistent with the + extended components definition. + + + The conformance claim shall identify all PPs and security + requirement packages to which the PP claims conformance. + + + The conformance claim shall describe any conformance of the + PP to a package as either package-conformant or + package-augmented. + + + The conformance claim rationale shall demonstrate that the + TOE type is consistent with the TOE type in the PPs for + which conformance is being claimed. + + + The conformance claim rationale shall demonstrate that the + statement of the security problem definition is consistent + with the statement of the security problem definition in the + PPs for which conformance is being claimed. + + + The conformance claim rationale shall demonstrate that the + statement of security objectives is consistent with the + statement of security objectives in the PPs for which + conformance is being claimed. + + + The conformance claim rationale shall demonstrate that the + statement of security requirements is consistent with the + statement of security requirements in the PPs for which + conformance is being claimed. + + + The conformance statement shall describe the conformance + required of any PPs/STs to the PP as strict-PP or + demonstrable-PP conformance. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the conformance claim + contains a CC conformance claim that identifies the + version of the CC to which the PP claims + conformance. + + The evaluator determines that the CC conformance claim + identifies the version of the CC that was used to + develop this PP. This should include the version number + of the CC and, unless the International English version + of the CC was used, the language of the version of the + CC that was used. + + + + + The evaluator shall check that the CC conformance claim + states a claim of either CC Part 2 conformant or CC Part + 2 extended for the PP. + + + + + The evaluator shall check that the CC conformance claim + states a claim of either CC Part 3 conformant or CC Part + 3 extended for the PP. + + + + + The evaluator shall examine the CC conformance claim for + CC Part 2 to determine that it is consistent with the + extended components definition. + + If the CC conformance claim contains CC Part 2 + conformant, the evaluator determines that the extended + components definition does not define functional + components. + + If the CC conformance claim contains CC Part 2 extended, + the evaluator determines that the extended components + definition defines at least one extended functional + component. + + + + + The evaluator shall examine the CC conformance claim for + CC Part 3 to determine that it is consistent with the + extended components definition. + + If the CC conformance claim contains CC Part 3 + conformant, the evaluator determines that the extended + components definition does not define assurance + components. + + If the CC conformance claim contains CC Part 3 extended, + the evaluator determines that the extended components + definition defines at least one extended assurance + component. + + + + + The evaluator shall check that the conformance claim + contains a PP claim that identifies all PPs for which + the PP claims conformance. + + If the PP does not claim conformance to another PP, this + work unit is not applicable and therefore considered to + be satisfied. + The evaluator determines that any referenced PPs + are unambiguously identified (e.g. by title and version + number, or by the identification included in the + introduction of that PP). + + The evaluator is reminded that claims of partial + conformance to a PP are not permitted. + + + + + The evaluator shall check that the conformance claim + contains a package claim that identifies all packages to + which the PP claims conformance. + + If the PP does not claim conformance to a package, this + work unit is not applicable and therefore considered to + be satisfied. + + The evaluator determines that any referenced packages + are unambiguously identified (e.g. by title and version + number, or by the identification included in the + introduction of that package). + + The evaluator is reminded that claims of partial + conformance to a package are not permitted. + + + + + The evaluator shall check that, for each identified + package, the conformance claim states a claim of either + package-name conformant or package-name + augmented. + + If the PP does not claim conformance to a package, this + work unit is not applicable and therefore considered to + be satisfied. + + If the package conformance claim contains package-name + conformant, the evaluator determines that: + + + If the package is an assurance package, then the PP + contains all SARs included in the package, but no + additional SARs. + + + If the package is a functional package, then the PP + contains all SFRs included in the package, but no + additional SFRs. + + + + If the package conformance claim contains package-name + augmented, the evaluator determines that: + + + If the package is an assurance package, then the PP + contains all SARs included in the package, and at + least one additional SAR or at least one SAR that is + hierarchical to a SAR in the package. + + + If the package is a functional package, then the PP + contains all SFRs included in the package, and at + least one additional SFR or at least one SFR that is + hierarchical to a SFR in the package. + + + + + + + The evaluator shall examine the conformance claim + rationale to determine that the TOE type of the TOE is + consistent with all TOE types of the PPs. + + If the PP does not claim conformance to another PP, this + work unit is not applicable and therefore considered to + be satisfied. + + The relation between the types may be simple: a firewall + PP claiming conformance to another firewall PP, or more + complex: a smart card PP claiming conformance to a number + of other PPs at the same time: a PP for the integrated + circuit, a PP for the smart card OS, and two PPs for two + applications on the smart card. + + + + + The evaluator shall examine the conformance claim + rationale to determine that it demonstrates that the + statement of security problem definition is consistent, + as defined by the conformance statement of the PP, with + the statements of security problem definition stated in + the PPs to which conformance is being claimed. + + If the PP under evaluation does not claim conformance + with another PP, this work unit is not applicable and + therefore considered to be satisfied. + + If the PP to which conformance is being claimed does not + have a statement of security problem definition, this + work unit is not applicable and therefore considered to + be satisfied. + + If strict conformance is required by the PP to which + conformance is being claimed, no conformance claim + rationale is required. Instead, the evaluator determines + whether + + + the threats in the PP under evaluation are a + superset of or identical to the threats in the PP to + which conformance is being claimed; + + + the OSPs in the PP under evaluation are a superset + of or identical to the OSPs in the PP to which + conformance is being claimed; + + + the assumptions in the PP under evaluation are + identical to the assumptions in the PP to which conformance + is being claimed; + + + If demonstrable conformance is required by the PP to + which conformance is being claimed, the evaluator + examines the conformance claim rationale to determine + that it demonstrates that the statement of security + problem definition of the PP under evaluation is + equivalent or more restrictive than the statement of + security problem definition in the PP to which + conformance is being claimed. + For guidance on ``equivalent or more restrictive'' + see CC Part 1 . + + + + + The evaluator shall examine the conformance claim + rationale to determine that the statement of security + objectives is consistent, as defined by the conformance + statement of the PPs, with the statement of security + objectives in the PPs. + + If the PP does not claim conformance to another PP, this + work unit is not applicable and therefore considered to + be satisfied. + + If strict conformance is required by the PP to which + conformance is being claimed, no conformance claim + rationale is required. Instead, the evaluator determines + whether: + + The PP under evaluation contains all security + objectives for the TOE of the PP to which + conformance is being claimed. Note that it is + allowed for the PP under evaluation to have + additional security objectives for the TOE; + The PP under evaluation contains exactly all + security objectives for the operational environment + (with one exception in the next bullet). Note that + it is not allowed for the PP under evaluation to + have additional security objectives for the + operational environment; + The PP under evaluation may specify that certain + objectives for the operational environment in the PP + that conformance is being claimed to are security + objectives for the TOE in the PP under + evaluation. This is a valid exception to the + previous bullet. + + If demonstrable conformance is required by the PP to + which conformance is being claimed, the evaluator + examines the conformance claim rationale to determine + that it demonstrates that the statement of security + objectives of the PP under evaluation is equivalent or + more restrictive than the statement of security + objectives in the PP to which conformance is being + claimed. + For guidance on ``equivalent or more restrictive'' + see CC Part 1 . + + + + + The evaluator shall examine the PP to determine that it + is consistent, as defined by the conformance statement + of the PP, with all security requirements in the PPs for + which conformance is being claimed. + + If the PP does not claim conformance to another PP, this + work unit is not applicable and therefore considered to + be satisfied. + + If strict conformance is required by the PP to which + conformance is being claimed, no conformance claim + rationale is required. Instead, the evaluator determines + whether the statement of security requirements in the PP + under evaluation is a superset of or identical to the + statement of security requirements in the PP to which + conformance is being claimed (for strict + conformance). + + If demonstrable conformance is required by the PP to + which conformance is being claimed, the evaluator + examines the conformance claim rationale to determine + that it demonstrates that the statement of security + requirements of the PP under evaluation is equivalent or + more restrictive than the statement of security + requirements in the PP to which conformance is being + claimed. + For guidance on ``equivalent or more restrictive'' + see CC Part 1 . + + + + + + The evaluator shall check that the PP conformance + statement states a claim of strict-PP or demonstrable-PP + conformance. + + + + + + + + This part of the PP defines the security problem to be + addressed by the TOE and the operational environment of the + TOE. + + Evaluation of the security problem definition is required to + demonstrate that the security problem intended to be + addressed by the TOE and its operational environment, is + clearly defined. + + + + The security problem definition defines the problem + addressed by the TOE and the operational environment of the + TOE. + + + + + The objective of this sub-activity is to determine that + the security problem intended to be addressed by the TOE + and its operational environment is clearly defined. + + + + The evaluation evidence for this sub-activity is: + + + the PP. + + + + + The developer shall provide a security problem definition. + + + The security problem definition shall describe the threats. + + + All threats shall be described in terms of a threat agent, + an asset, and an adverse action. + + + The security problem definition shall describe the OSPs. + + + The security problem definition shall describe the + assumptions about the operational environment of the TOE. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the security problem + definition describes the threats. + + If all security objectives are derived from assumptions + and/or OSPs only, the statement of threats need not be + present in the PP. In this case, this work unit is not + applicable and therefore considered to be + satisfied. + + The evaluator determines that the security problem + definition describes the threats that must be countered + by the TOE and/or its operational environment. + + + + + The evaluator shall examine the security problem + definition to determine that all threats are described + in terms of a threat agent, an asset, and an adverse + action. + + If all security objectives are derived from assumptions + and OSPs only, the statement of threats need not be + present in the PP. In this case, this work unit is not + applicable and therefore considered to be + satisfied. + + Threat agents may be further described by aspects such + as expertise, resource, opportunity, and + motivation. + + + + + The evaluator shall examine that the security problem + definition describes the OSPs. + + If all security objectives are derived from assumptions + and/or threats only, OSPs need not be present in the + PP. In this case, this work unit is not applicable and + therefore considered to be satisfied. + + The evaluator determines that OSP statements are made in + terms of rules or guidelines that must be followed by + the TOE and/or its operational environment. + + The evaluator determines that each OSP is explained + and/or interpreted in sufficient detail to make it + clearly understandable; a clear presentation of policy + statements is necessary to permit tracing security + objectives to them. + + + + + The evaluator shall examine the security problem + definition to determine that it describes the + assumptions about the operational environment of the + TOE. + + If there are no assumptions, this work unit is not + applicable and is therefore considered to be + satisfied. + + The evaluator determines that each assumption about the + operational environment of the TOE is explained in + sufficient detail to enable consumers to determine that + their operational environment matches the assumption. If + the assumptions are not clearly understood, the end + result may be that the TOE is used in an operational + environment in which it will not function in a secure + manner. + + + + + + + + The security objectives are a concise statement of the + intended response to the security problem defined through + the family. + + Evaluation of the security objectives is required to + demonstrate that the security objectives adequately and + completely address the security problem definition and that + the division of this problem between the TOE and its + operational environment is clearly defined. + + + + The security objectives are a concise statement of the + intended response to the security problem. + + + + The components in this family are levelled on whether they + prescribe only security objectives for the operational + environment, or also security objectives for the TOE. + + + + + The objective of this sub-activity is to determine whether + the security objectives for the operational environment + are clearly defined. + + + + The evaluation evidence for this sub-activity is: + + + the PP. + + + + + The developer shall provide a statement of security + objectives. + + + The statement of security objectives shall describe the + security objectives for the operational environment. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the statement of security + objectives defines the security objectives for the + operational environment. + + The evaluator checks that the security objectives for + the operational environment are identified. + + + + + + + + + The objective of this sub-activity is to determine whether + the security objectives adequately and completely address + the security problem definition and that the division of + this problem between the TOE and its operational + environment is clearly defined. + + + + The evaluation evidence for this sub-activity is: + + + the PP. + + + + + The developer shall provide a statement of security + objectives. + + + The developer shall provide a security objectives rationale. + + + The statement of security objectives shall describe the + security objectives for the TOE and the security objectives + for the operational environment. + + + The security objectives rationale shall trace each security + objective for the TOE back to threats countered by that + security objective and OSPs enforced by that security + objective. + + + The security objectives rationale shall trace each security + objective for the operational environment back to threats + countered by that security objective, OSPs enforced by that + security objective, and assumptions upheld by that security + objective. + + + The security objectives rationale shall demonstrate that the + security objectives counter all threats. + + + The security objectives rationale shall demonstrate that the + security objectives enforce all OSPs. + + + The security objectives rationale shall demonstrate that the + security objectives for the operational environment uphold + all assumptions. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the statement of security + objectives defines the security objectives for the TOE + and the security objectives for the operational + environment. + + The evaluator checks that both categories of security + objectives are clearly identified and separated from the + other category. + + + + + The evaluator shall check that the security objectives + rationale traces all security objectives for the TOE + back to threats countered by the objectives and/or OSPs + enforced by the objectives. + + Each security objective for the TOE may trace back to + threats or OSPs, or a combination of threats and OSPs, + but it must trace back to at least one threat or + OSP. + + Failure to trace implies that either the security + objectives rationale is incomplete, the security problem + definition is incomplete, or the security objective for + the TOE has no useful purpose. + + + + + The evaluator shall check that the security objectives + rationale traces the security objectives for the + operational environment back to threats countered by + that security objective, to OSPs enforced by that + security objective, and to assumptions upheld by that + security objective. + + Each security objective for the operational environment + may trace back to threats, OSPs, assumptions, or a + combination of threats, OSPs and/or assumptions, but it + must trace back to at least one threat, OSP or + assumption. + + Failure to trace implies that either the security + objectives rationale is incomplete, the security problem + definition is incomplete, or the security objective for + the operational environment has no useful + purpose. + + + + + The evaluator shall examine the security objectives + rationale to determine that it justifies for each threat + that the security objectives are suitable to counter + that threat. + + If no security objectives trace back to the threat, the evaluator action + related to this work unit is assigned a fail verdict. + + The evaluator determines that the justification for a + threat shows whether the threat is removed, diminished + or mitigated. + + The evaluator determines that the justification for a + threat demonstrates that the security objectives are + sufficient: if all security objectives that trace back + to the threat are achieved, the threat is removed, + sufficiently diminished, or the effects of the threat + are sufficiently mitigated. + + Note that the tracings from security objectives to + threats provided in the security objectives rationale + may be part of a justification, but do not constitute a + justification by themselves. Even in the case that a + security objective is merely a statement reflecting the + intent to prevent a particular threat from being + realised, a justification is required, but this + justification may be as minimal as ``Security Objective + X directly counters Threat Y''. + + The evaluator also determines that each security + objective that traces back to a threat is necessary: + when the security objective is achieved it actually + contributes to the removal, diminishing or mitigation of + that threat. + + + + + The evaluator shall examine the security objectives + rationale to determine that for each OSP it justifies + that the security objectives are suitable to enforce + that OSP. + + If no security objectives trace back to the OSP, the evaluator action + related to this work unit is assigned a fail verdict. + + The evaluator determines that the justification for an + OSP demonstrates that the security objectives are + sufficient: if all security objectives that trace back + to that OSP are achieved, the OSP is enforced. + + The evaluator also determines that each security + objective that traces back to an OSP is necessary: when + the security objective is achieved it actually + contributes to the enforcement of the OSP. + + Note that the tracings from security objectives to OSPs + provided in the security objectives rationale may be + part of a justification, but do not constitute a + justification by themselves. In the case that a security + objective is merely a statement reflecting the intent to + enforce a particular OSP, a justification is required, + but this justification may be as minimal as ``Security + Objective X directly enforces OSP Y''. + + + + + The evaluator shall examine the security objectives + rationale to determine that for each assumption for the + operational environment it contains an appropriate + justification that the security objectives for the + operational environment are suitable to uphold that + assumption. + + If no security objectives for the operational environment trace back to the assumption, + the evaluator action related to this work unit is assigned a fail verdict. + + The evaluator determines that the justification for an + assumption about the operational environment of the TOE + demonstrates that the security objectives are + sufficient: if all security objectives for the + operational environment that trace back to that + assumption are achieved, the operational environment + upholds the assumption. + + The evaluator also determines that each security + objective for the operational environment that traces + back to an assumption about the operational environment + of the TOE is necessary: when the security objective is + achieved it actually contributes to the operational + environment upholding the assumption. + + Note that the tracings from security objectives for the + operational environment to assumptions provided in the + security objectives rationale may be a part of a + justification, but do not constitute a justification by + themselves. Even in the case that a security objective + of the operational environment is merely a restatement + of an assumption, a justification is required, but this + justification may be as minimal as ``Security Objective + X directly upholds Assumption Y''. + + + + + + + + Extended security requirements are requirements that are not + based on components from CC Part 2 or CC Part 3, but are + based on extended components: components defined by the PP + author. + + Evaluation of the definition of extended components is + necessary to determine that they are clear and unambiguous, + and that they are necessary, i.e. they may not be clearly + expressed using existing CC Part 2 or CC Part 3 + components. + + + + Extended security requirements are requirements that are not + based on components from CC Part 2 or CC Part 3, but are + based on extended components: components defined by the PP + author. This family is used to determine that these extended + components are defined similarly to the existing CC Part 2 + or CC Part 3 components. + + Evaluation of the definition of extended components is + necessary to determine that they are clear and unambiguous, + and that they are necessary, i.e. they may not be clearly + expressed using existing CC Part 2 or CC Part 3 + components. + + + + + The objective of this sub-activity is to determine whether + extended components have been clearly and unambiguously + defined, and whether they are necessary, i.e. they may not + be clearly expressed using existing CC Part 2 or CC Part 3 + components. + + + + The evaluation evidence for this sub-activity is: + + + the PP. + + + + + The developer shall provide a statement of security + requirements. + + + The developer shall provide an extended components + definition. + + + The statement of security requirements shall identify all + extended security requirements. + + + The extended components definition shall define an extended + component for each extended security requirement. + + + The extended components definition shall describe how each + extended component is related to the existing CC components, + families, and classes. + + + The extended components definition shall use the existing CC + components, families, classes, and methodology as a model + for presentation. + + + The extended components shall consist of measurable and + objective elements such that conformance or nonconformance + to these elements can be demonstrated. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that all security requirements + in the statement of security requirements that are not + identified as extended requirements are present in CC + Part 2 or in CC Part 3. + + + + + The evaluator shall check that the extended components + definition defines an extended component for each + extended security requirement. + + If the PP does not contain extended security + requirements, this work unit is not applicable and + therefore considered to be satisfied. + + A single extended component may be used to define + multiple iterations of an extended security requirement, + it is not necessary to repeat this definition for each + iteration. + + + + + The evaluator shall examine the extended components + definition to determine that it describes how each + extended component fits into the existing CC components, + families, and classes. + + If the PP does not contain extended security + requirements, this work unit is not applicable and + therefore considered to be satisfied. + + The evaluator determines that each extended component is + either: + + + a member of an existing CC Part 2 or CC Part 3 + family, or + + a member of a new family defined in the PP. + + + + If the extended component is a member of an existing CC + Part 2 or CC Part 3 family, the evaluator determines + that the extended components definition adequately + describes why the extended component should be a member + of that family and how it relates to other components of + that family. + + If the extended component is a member of a new family + defined in the PP, the evaluator confirms that the + extended component is not appropriate for an existing + family. + + If the PP defines new families, the evaluator determines + that each new family is either: + + + a member of an existing CC Part 2 or CC Part 3 + class, or + + + a member of a new class defined in the PP. + + + + If the family is a member of an existing CC Part 2 or CC + Part 3 class, the evaluator determines that the extended + components definition adequately describes why the + family should be a member of that class and how it + relates to other families in that class. + + If the family is a member of a new class defined in the + PP, the evaluator confirms that the family is not + appropriate for an existing class. + + + + + The evaluator shall examine the extended components + definition to determine that each definition of an + extended component identifies all applicable + dependencies of that component. + + If the PP does not contain extended security + requirements, this work unit is not applicable and + therefore considered to be satisfied. + + The evaluator confirms that no applicable dependencies + have been overlooked by the PP author. + + + + + The evaluator shall examine the extended components + definition to determine that each extended functional + component uses the existing CC Part 2 components as a + model for presentation. + + If the PP does not contain extended SFRs, this work unit + is not applicable and therefore considered to be + satisfied. + + The evaluator determines that the extended functional + component is consistent with CC Part 2 Subclause . + + If the extended functional component uses operations, the + evaluator determines that the extended functional component is + consistent with CC Part 1 Subclause . + + If the extended functional component is hierarchical to + an existing functional component, the evaluator + determines that the extended functional component is + consistent with CC Part 2 Subclause . + + + + + The evaluator shall examine the extended components + definition to determine that each definition of a new + functional family uses the existing CC functional + families as a model for presentation. + + If the PP does not define new functional families, this + work unit is not applicable and therefore considered to + be satisfied. + + The evaluator determines that all new functional + families are defined consistent with CC Part 2 Subclause + . + + + + + The evaluator shall examine the extended components + definition to determine that each definition of a new + functional class uses the existing CC functional classes + as a model for presentation. + + If the PP does not define new functional classes, this + work unit is not applicable and therefore considered to + be satisfied. + + The evaluator determines that all new functional classes + are defined consistent with CC Part 2 Subclause + + + + + The evaluator shall examine the extended components + definition to determine that each definition of an + extended assurance component uses the existing CC Part 3 + components as a model for presentation. + + If the PP does not contain extended SARs, this work unit + is not applicable and therefore considered to be + satisfied. + + The evaluator determines that the extended assurance + component definition is consistent with CC Part 3 + Subclause . + + If the extended assurance component uses operations, the + evaluator determines that the extended assurance component is + consistent with CC Part 1 Subclause . + + If the extended assurance component is hierarchical to + an existing assurance component, the evaluator + determines that the extended assurance component is + consistent with CC Part 3 Subclause . + + + + + The evaluator shall examine the extended components + definition to determine that, for each defined extended + assurance component, applicable methodology has been + provided. + + If the PP does not contain extended SARs, this work unit + is not applicable and therefore considered to be + satisfied. + + The evaluator determines that, for each evaluator action + element of each extended SAR, one or more work units are + provided and that successfully performing all work units + for a given evaluator action element will demonstrate + that the element has been achieved. + + + + + The evaluator shall examine the extended components + definition to determine that each definition of a new + assurance family uses the existing CC assurance families + as a model for presentation. + + If the PP does not define new assurance families, this + work unit is not applicable and therefore considered to + be satisfied. + + The evaluator determines that all new assurance families + are defined consistent with CC Part 3 Subclause . + + + + + The evaluator shall examine the extended components + definition to determine that each definition of a new + assurance class uses the existing CC assurance classes + as a model for presentation. + + If the PP does not define new assurance classes, this + work unit is not applicable and therefore considered to + be satisfied. + + The evaluator determines that all new assurance classes + are defined consistent with CC Part 3 Subclause . + + + + + The evaluator shall examine the extended components + definition to determine that each element in each + extended component is measurable and states objective + evaluation requirements, such that conformance or + nonconformance can be demonstrated. + + If the PP does not contain extended security + requirements, this work unit is not applicable and + therefore considered to be satisfied. + + The evaluator determines that elements of extended + functional components are stated in such a way that they + are testable, and traceable through the appropriate TSF + representations. + + The evaluator also determines that elements of extended + assurance components avoid the need for subjective + evaluator judgement. + + The evaluator is reminded that whilst being measurable + and objective is appropriate for all evaluation + criteria, it is acknowledged that no formal method + exists to prove such properties. Therefore the existing + CC functional and assurance components are to be used as + a model for determining what constitutes conformance to + this requirement. + + + + The evaluator shall confirm that no extended component may + be clearly expressed using existing components. + + + The evaluator shall examine the extended components + definition to determine that each extended component may + not be clearly expressed using existing + components. + + If the PP does not contain extended security + requirements, this work unit is not applicable and + therefore considered to be satisfied. + + The evaluator should take components from CC Part 2 and + CC Part 3, other extended components that have been + defined in the PP, combinations of these components, and + possible operations on these components into account + when making this determination. + + The evaluator is reminded that the role of this work + unit is to preclude unnecessary duplication of + components, that is, components that may be clearly + expressed by using other components. The evaluator + should not undertake an exhaustive search of all + possible combinations of components including operations + in an attempt to find a way to express the extended + component by using existing components. + + + + + + + + The SFRs form a clear, unambiguous and well-defined + description of the expected security behaviour of the + TOE. The SARs form a clear, unambiguous and well-defined + description of the expected activities that will be + undertaken to gain assurance in the TOE. + + Evaluation of the security requirements is required to + ensure that they are clear, unambiguous and + well-defined. + + + + The SFRs form a clear, unambiguous and well-defined + description of the expected security behaviour of the + TOE. The SARs form a clear, unambiguous and well-defined + description of the expected activities that will be + undertaken to gain assurance in the TOE. + + + + The components in this family are levelled on whether they + are stated as is, or whether the SFRs are derived from + security objectives for the TOE. + + + + + + The objective of this sub-activity is to determine whether + the SFRs and SARs are clear, unambiguous and well-defined + and whether they are internally consistent. + + + + The evaluation evidence for this sub-activity is: + + + the PP. + + + + + The developer shall provide a statement of security requirements. + + + The developer shall provide a security requirements + rationale. + + + The statement of security requirements shall describe the + SFRs and the SARs. + + + All subjects, objects, operations, security attributes, + external entities and other terms that are used in the SFRs + and the SARs shall be defined. + + + The statement of security requirements shall identify all + operations on the security requirements. + + + All operations shall be performed correctly. + + + Each dependency of the security requirements shall either be + satisfied, or the security requirements rationale shall + justify the dependency not being satisfied. + + + The statement of security requirements shall be internally + consistent. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the statement of security + requirements describes the SFRs. + + The evaluator determines that each SFR is identified by + one of the following means: + + + by reference to an individual component in CC Part + 2; + + + by reference to an extended component in the + extended components definition of the PP; + + + by reference to a PP that the PP claims to be + conformant with; + + + by reference to a security requirements package that + the PP claims to be conformant with; + + + by reproduction in the PP. + + It is not required to use the same means of + identification for all SFRs. + + + + + The evaluator shall check that the statement of security + requirements describes the SARs. + + The evaluator determines that each SAR is identified by + one of the following means: + + + by reference to an individual component in CC Part + 3; + + + by reference to an extended component in the + extended components definition of the PP; + + + by reference to a PP that the PP claims to be + conformant with; + + + by reference to a security requirements package that + the PP claims to be conformant with; + + + by reproduction in the PP. + + It is not required to use the same means of + identification for all SARs. + + + + + The evaluator shall examine the PP to determine that all + subjects, objects, operations, security attributes, + external entities and other terms that are used in the + SFRs and the SARs are defined. + + The evaluator determines that the PP defines all: + + (types of) subjects and objects that are used in + the SFRs; + (types of) security attributes of subjects, users, + objects, information, sessions and/or resources, possible + values that these attributes may take and any relations + between these values (e.g. top_secret is ``higher'' than secret); + (types of) operations that are used in the SFRs, + including the effects of these operations; + (types of) external entities in the SFRs; + other terms that are introduced in the SFRs + and/or SARs by completing operations, if these terms + are not immediately clear, or are used outside their + dictionary definition. + + The goal of this work unit is to ensure that the SFRs + and SARs are well-defined and that no misunderstanding + may occur due to the introduction of vague terms. This + work unit should not be taken into extremes, by forcing + the PP writer to define every single word. The general + audience of a set of security requirements should be + assumed to have a reasonable knowledge of IT, security + and Common Criteria. + + All of the above may be presented in groups, classes, + roles, types or other groupings or characterisations + that allow easy understanding. + + The evaluator is reminded that these lists and + definitions do not have to be part of the statement of + security requirements, but may be placed (in part or in + whole) in different subclauses. This may be especially + applicable if the same terms are used in the rest of the + PP. + + + + + The evaluator shall check that the statement of security + requirements identifies all operations on the security + requirements. + + The evaluator determines that all operations are + identified in each SFR or SAR where such an operation is + used. This includes both completed operations and + uncompleted operations. Identification may be achieved + by typographical distinctions, or by explicit + identification in the surrounding text, or by any other + distinctive means. + + + + + The evaluator shall examine the statement of security + requirements to determine that all assignment operations + are performed correctly. + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that all iteration operations + are performed correctly. + + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that all selection operations + are performed correctly. + + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that all refinement operations + are performed correctly. + + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that each dependency of the + security requirements is either satisfied, or that the + security requirements rationale justifies the dependency + not being satisfied. + + A dependency is satisfied by the inclusion of the + relevant component (or one that is hierarchical to it) + within the statement of security requirements. The + component used to satisfy the dependency should, if + necessary, be modified by operations to ensure that it + actually satisfies that dependency. + + A justification that a dependency is not met should + address either: + + + why the dependency is not necessary or useful, in + which case no further information is required; or + + + that the dependency has been addressed by the + operational environment of the TOE, in which case + the justification should describe how the security + objectives for the operational environment address + this dependency. + + + + + + + The evaluator shall examine the statement of security + requirements to determine that it is internally + consistent. + + The evaluator determines that the combined set of all + SFRs and SARs is internally consistent. + + The evaluator determines that on all occasions where + different security requirements apply to the same types + of developer evidence, events, operations, data, tests + to be performed etc. or to ``all objects'', ``all + subjects'' etc., that these requirements do not + conflict. + + Some possible conflicts are: + + + an extended SAR specifying that the design of a + certain cryptographic algorithm is to be kept + secret, and another extended SAR specifying an open + source review; + + specifying + that subject identity is to be logged, specifying who has + access to these logs, and specifying that some actions of + subjects should be unobservable to other + subjects. If the subject that should not be able to + see an activity may access logs of this activity, + these SFRs conflict; + + specifying + deletion of information no longer needed, and specifying that a TOE + may return to a previous state. If the information + that is needed for the rollback to the previous + state has been deleted, these requirements conflict; + + + Multiple iterations of especially where some iterations cover + the same subjects, objects, or operations. If one + access control SFR allows a subject to perform an + operation on an object, while another access control + SFR does not allow this, these requirements + conflict. + + + + + + + + + + + + The objective of this sub-activity is to determine whether + the SFRs and SARs are clear, unambiguous and well-defined, + whether they are internally consistent, and whether the + SFRs meet the security objectives of the TOE. + + + + The evaluation evidence for this sub-activity is: + + + the PP. + + + + + The developer shall provide a statement of security requirements. + + + The developer shall provide a security requirements + rationale. + + + The statement of security requirements shall describe the + SFRs and the SARs. + + + All subjects, objects, operations, security attributes, + external entities and other terms that are used in the SFRs + and the SARs shall be defined. + + + The statement of security requirements shall identify all + operations on the security requirements. + + + All operations shall be performed correctly. + + + Each dependency of the security requirements shall either be + satisfied, or the security requirements rationale shall + justify the dependency not being satisfied. + + + The security requirements rationale shall trace each SFR + back to the security objectives for the TOE. + + + The security requirements rationale shall demonstrate that + the SFRs meet all security objectives for the TOE. + + + The security requirements rationale shall explain why the + SARs were chosen. + + + The statement of security requirements shall be internally + consistent. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the statement of security + requirements describes the SFRs. + + The evaluator determines that each SFR is identified by + one of the following means: + + + by reference to an individual component in CC Part + 2; + + + by reference to an extended component in the + extended components definition of the PP; + + + by reference to an individual component in a PP that + the PP claims to be conformant with; + + + by reference to an individual component in a + security requirements package that the PP claims to + be conformant with; + + + by reproduction in the PP. + + It is not required to use the same means of + identification for all SFRs. + + + + + The evaluator shall check that the statement of security + requirements describes the SARs. + + The evaluator determines that each SAR is identified by + one of the following means: + + + by reference to an individual component in CC Part + 3; + + + by reference to an extended component in the + extended components definition of the PP; + + + by reference to an individual component in a PP that + the PP claims to be conformant with; + + + by reference to an individual component in a + security requirements package that the PP claims to + be conformant with; + + + by reproduction in the PP. + + It is not required to use the same means of + identification for all SARs. + + + + + The evaluator shall examine the PP to determine that all + subjects, objects, operations, security attributes, + external entities and other terms that are used in the + SFRs and the SARs are defined. + + The evaluator determines that the PP defines all: + + (types of) subjects and objects that are used in + the SFRs; + (types of) security attributes of subjects, users, + objects, information, sessions and/or resources, possible + values that these attributes may take and any relations + between these values (e.g. top_secret is ``higher'' than secret); + (types of) operations that are used in the SFRs, + including the effects of these operations; + (types of) external entities in the SFRs; + other terms that are introduced in the SFRs + and/or SARs by completing operations, if these terms + are not immediately clear, or are used outside their + dictionary definition. + + The goal of this work unit is to ensure that the SFRs + and SARs are well-defined and that no misunderstanding + may occur due to the introduction of vague terms. This + work unit should not be taken into extremes, by forcing + the PP writer to define every single word. The general + audience of a set of security requirements should be + assumed to have a reasonable knowledge of IT, security + and Common Criteria. + + All of the above may be presented in groups, classes, + roles, types or other groupings or characterisations + that allow easy understanding. + + The evaluator is reminded that these lists and + definitions do not have to be part of the statement of + security requirements, but may be placed (in part or in + whole) in different subclauses. This may be especially + applicable if the same terms are used in the rest of the + PP. + + + + + The evaluator shall check that the statement of security + requirements identifies all operations on the security + requirements. + + The evaluator determines that all operations are + identified in each SFR or SAR where such an operation is + used. This includes both completed operations and + uncompleted operations. Identification may be achieved + by typographical distinctions, or by explicit + identification in the surrounding text, or by any other + distinctive means. + + + + + The evaluator shall examine the statement of security + requirements to determine that all assignment operations + are performed correctly. + + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that all iteration operations + are performed correctly. + + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that all selection operations + are performed correctly. + + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that all refinement operations + are performed correctly. + + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that each dependency of the + security requirements is either satisfied, or that the + security requirements rationale justifies the dependency + not being satisfied. + + A dependency is satisfied by the inclusion of the + relevant component (or one that is hierarchical to it) + within the statement of security requirements. The + component used to satisfy the dependency should, if + necessary, be modified by operations to ensure that it + actually satisfies that dependency. + + A justification that a dependency is not met should + address either: + + + why the dependency is not necessary or useful, in + which case no further information is required; or + + + that the dependency has been addressed by the + operational environment of the TOE, in which case + the justification should describe how the security + objectives for the operational environment address + this dependency. + + + + + + + The evaluator shall check that the security requirements + rationale traces each SFR back to the security + objectives for the TOE. + + The evaluator determines that each SFR is traced back to + at least one security objective for the TOE. + + Failure to trace implies that either the security + requirements rationale is incomplete, the security + objectives for the TOE are incomplete, or the SFR has no + useful purpose. + + + + + The evaluator shall examine the security requirements + rationale to determine that for each security objective + for the TOE it justifies that the SFRs are suitable to + meet that security objective for the TOE. + + If no SFRs trace back to the security objective for the TOE, + the evaluator action related to this work unit is assigned a fail verdict. + + The evaluator determines that the justification for a + security objective for the TOE demonstrates that the + SFRs are sufficient: if all SFRs that trace back to the + objective are satisfied, the security objective for the + TOE is achieved. + + If the SFRs that trace back to a security objective for + the TOE have any uncompleted assignments, or uncompleted + or restricted selections, the evaluator determines that + for every conceivable completion or combination of + completions of these operations, the security objective + is still met. + + The evaluator also determines that each SFR that traces + back to a security objective for the TOE is necessary: + when the SFR is satisfied, it actually contributes to + achieving the security objective. + + Note that the tracings from SFRs to security objectives + for the TOE provided in the security requirements + rationale may be a part of the justification, but do not + constitute a justification by themselves. + + + + + The evaluator shall check that the security requirements + rationale explains why the SARs were chosen. + The evaluator is reminded that any explanation is + correct, as long as it is coherent and neither the SARs + nor the explanation have obvious inconsistencies with + the remainder of the PP. + An example of an obvious inconsistency between the + SARs and the remainder of the PP would be to have threat + agents that are very capable, but an SAR that does not protect against these + threat agents. + + + + + The evaluator shall examine the statement of security + requirements to determine that it is internally + consistent. + + The evaluator determines that the combined set of all + SFRs and SARs is internally consistent. + + The evaluator determines that on all occasions where + different security requirements apply to the same types + of developer evidence, events, operations, data, tests + to be performed etc. or to ``all objects'', ``all + subjects'' etc., that these requirements do not + conflict. + + Some possible conflicts are: + + + an extended SAR specifying that the design of a + certain cryptographic algorithm is to be kept + secret, and another extended SAR specifying an open + source review; + + specifying + that subject identity is to be logged, specifying who has + access to these logs, and specifying that some actions of + subjects should be unobservable to other + subjects. If the subject that should not be able to + see an activity may access logs of this activity, + these SFRs conflict; + + specifying + deletion of information no longer needed, and specifying that a TOE + may return to a previous state. If the information + that is needed for the rollback to the previous + state has been deleted, these requirements conflict; + + + Multiple iterations of especially where some iterations cover + the same subjects, objects, or operations. If one + access control SFR allows a subject to perform an + operation on an object, while another access control + SFR does not allow this, these requirements + conflict. + + + + + + + + + + + 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. + + This Clause should be used in conjunction with Annexes , and + in CC + Part 1, as these Annexes clarify the concepts here and provide + many examples. + + + + Assurance class defines + requirements for the evaluation of an ST, 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. + + + + This Clause describes the evaluation of an ST. The ST + evaluation should be started prior to any TOE evaluation + sub-activities since the ST provides the basis and context to + perform these sub-activities. The evaluation methodology in + this subclause is based on the requirements on the ST as + specified in CC Part 3 class . + + This Clause should be used in conjunction with Annexes , and + in CC + Part 1, as these Annexes clarify the concepts here and provide + many examples. + + + + The ST describes the security features of a TOE. As such it is + expected to identify the security requirements that enforce + the defined OSPs and counter the defined threats under the + defined assumptions. + + 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 or packages. These properties are + necessary for the ST to be suitable for use as the basis for a + TOE evaluation. + + + + + While evaluating an ST that is based on one or more + certified PPs, it may be possible to re-use the fact that + these PPs were certified. The potential for re-use of the + result of a certified PP is greater if the ST does not add + threats, OSPs, assumptions, security objectives and/or + security requirements to those of the PP. If the ST + contains much more than the certified PP, re-use may not be + useful at all. + + The evaluator is allowed to re-use the PP evaluation results + by doing certain analyses only partially or not at all if + these analyses or parts thereof were already done as part of + the PP evaluation. While doing this, the evaluator should + assume that the analyses in the PP were performed + correctly. + + An example would be where the PP contains a set of security + requirements, and these were determined to be internally + consistent during the PP evaluation. If the ST uses the + exact same requirements, the consistency analysis does not + have to be repeated during the ST evaluation. If the ST adds + one or more requirements, or performs operations on these + requirements, the analysis will have to be + repeated. However, it may be possible to save work in this + consistency analysis by using the fact that the original + requirements are internally consistent. If the original + requirements are internally consistent, the evaluator only + has to determine that: + + + the set of all new and/or changed requirements is + internally consistent, and + + + the set of all new and/or changed requirements is + consistent with the original requirements. + + + The evaluator notes in the ETR each case where analyses are + not done or only partially done for this reason. + + + + + + The objective of this family is to describe the TOE in a + narrative way on three levels of abstraction: TOE reference, + TOE overview and TOE description. + + Evaluation of the ST introduction is required to demonstrate + that the ST and the TOE are correctly identified, that the + TOE is correctly described at three levels of abstraction + and that these three descriptions are consistent with each + other. + + + + The ST introduction describes the TOE in a narrative way on + three levels of abstraction: TOE reference, TOE overview and + TOE description. + + + + + The objective of this sub-activity is to determine whether + the ST and the TOE are correctly identified, whether the + TOE is correctly described in a narrative way at three + levels of abstraction (TOE reference, TOE overview and TOE + description), and whether these three descriptions are + consistent with each other. + + + + The evaluation evidence for this sub-activity is: + + + the ST. + + + + + The developer shall provide an ST introduction. + + + The ST introduction shall contain an ST reference, a TOE + reference, a TOE overview and a TOE description. + + + The ST reference shall uniquely identify the ST. + + + The TOE reference shall identify the TOE. + + + The TOE overview shall summarise the usage and major + security features of the TOE. + + + The TOE overview shall identify the TOE type. + + + The TOE overview shall identify any non-TOE + hardware/software/firmware required by the TOE. + + + The TOE description shall describe the physical scope of the + TOE. + + + The TOE description shall describe the logical scope of the + TOE. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the ST introduction + contains an ST reference, a TOE reference, a TOE + overview and a TOE description. + + + + + The evaluator shall examine the ST reference to + determine that it uniquely identifies the ST. + + The evaluator determines that the ST reference + identifies the ST itself, so that it may be easily + distinguished from other STs, and that it also uniquely + identifies each version of the ST, e.g. by including a + version number and/or a date of publication. + + In evaluations where a CM system is provided, the + evaluator may validate the uniqueness of the reference + by checking the configuration list. In the other cases, + the ST should have some referencing system that is + capable of supporting unique references (e.g. use of + numbers, letters or dates). + + + + + The evaluator shall examine the TOE reference to + determine that it identifies the TOE. + + The evaluator determines that the TOE reference + identifies the TOE, so that it is clear to which TOE the + ST refers, and that it also identifies the version of + the TOE, e.g. by including a version/release/build + number, or a date of release. + + + + + The evaluator shall examine the TOE reference to + determine that it is not misleading. + + If the TOE is related to one or more well-known + products, it is allowed to reflect this in the TOE + reference. However, this should not be used to mislead + consumers: situations where only a small part of a + product is evaluated, yet the TOE reference does not + reflect this, are not allowed. + + + + + The evaluator shall examine the TOE overview to + determine that it describes the usage and major security + features of the TOE. + + The TOE overview should briefly (i.e. several + paragraphs) describe the usage and major security + features of the TOE. The TOE overview should enable + potential consumers to quickly determine whether the TOE + may be suitable for their security needs. + + The TOE overview in an ST for a composed TOE should + describe the usage and major security feature of the + composed TOE, rather than those of the individual + component TOEs. + + The evaluator determines that the overview is clear + enough for consumers, and sufficient to give them a + general understanding of the intended usage and major + security features of the TOE. + + + + + The evaluator shall check that the TOE overview + identifies the TOE type. + + + + + The evaluator shall examine the TOE overview to + determine that the TOE type is not misleading. + + There are situations where the general consumer would + expect certain functionality of the TOE because of its + TOE type. If this functionality is absent in the TOE, + the evaluator determines that the TOE overview + adequately discusses this absence. + + There are also TOEs where the general consumer would + expect that the TOE should be able to operate in a + certain operational environment because of its TOE + type. If the TOE is unable to operate in such an + operational environment, the evaluator determines that + the TOE overview adequately discusses this. + + + + + The evaluator shall examine the TOE overview to + determine that it identifies any non-TOE + hardware/software/firmware required by the TOE. + + While some TOEs are able to run stand-alone, other TOEs + (notably software TOEs) need additional hardware, + software or firmware to operate. If the TOE does not + require any hardware, software or firmware, this work + unit is not applicable and therefore considered to be + satisfied. + + The evaluator determines that the TOE overview + identifies any additional hardware, software and + firmware needed by the TOE to operate. This + identification does not have to be exhaustive, but + detailed enough for potential consumers of the TOE to + determine whether their current hardware, software and + firmware support use of the TOE, and, if this is not the + case, which additional hardware, software and/or + firmware is needed. + + + + + The evaluator shall examine the TOE description to + determine that it describes the physical scope of the + TOE. + + The evaluator determines that the TOE description lists + the hardware, firmware, software and guidance parts that + constitute the TOE and describes them at a level of + detail that is sufficient to give the reader a general + understanding of those parts. + + The evaluator also determines that there is no possible + misunderstanding as to whether any hardware, firmware, + software or guidance part is part of the TOE or + not. + + + + + The evaluator shall examine the TOE description to + determine that it describes the logical scope of the + TOE. + + The evaluator determines that the TOE description + discusses the logical security features offered by the + TOE at a level of detail that is sufficient to give the + reader a general understanding of those features. + + The evaluator also determines that there is no possible + misunderstanding as to whether any logical security + feature is offered by the TOE or not. + + An ST for a composed TOE may refer out to the + description of the logical scope of the component TOEs, + provided in the component TOE STs to provide the + majority of this description for the composed TOE. + However, the evaluator determines that the composed TOE + ST clearly discusses which features of the individual + components are not within the composed TOE, and + therefore not a feature of the composed TOE. + + + + The evaluator shall confirm that the TOE reference, the TOE + overview, and the TOE description are consistent with each + other. + + + The evaluator shall examine the TOE reference, TOE + overview and TOE description to determine that they are + consistent with each other. + + + + + + + + The objective of this family is to determine the validity of + the conformance claim. In addition, this family specifies + how STs are to claim conformance with the PP. + + + + Conformance claims describes how the Security Target + conforms to CC Part 2 and CC Part 3, to Protection Profiles + and to packages. + + + + + + + + The objective of this sub-activity is to determine the + validity of various conformance claims. These describe how + the ST and the TOE conform to the CC and how the ST + conforms to PPs and packages. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the PP(s) that the ST claims conformance to; + + + the package(s) that the ST claims conformance to. + + + + + The developer shall provide a conformance claim. + + + The developer shall provide a conformance claim rationale. + + + The conformance claim shall contain a CC conformance claim + that identifies the version of the CC to which the ST and + the TOE claim conformance. + + + The CC conformance claim shall describe the conformance of + the ST to CC Part 2 as either CC Part 2 conformant or CC + Part 2 extended. + + + The CC conformance claim shall describe the conformance of + the ST to CC Part 3 as either CC Part 3 conformant or CC + Part 3 extended. + + + The CC conformance claim shall be consistent with the + extended components definition. + + + The conformance claim shall identify all PPs and security + requirement packages to which the ST claims conformance. + + + The conformance claim shall describe any conformance of the + ST to a package as either package-conformant or + package-augmented. + + + The conformance claim rationale shall demonstrate that the + TOE type is consistent with the TOE type in the PPs for + which conformance is being claimed. + + + The conformance claim rationale shall demonstrate that the + statement of the security problem definition is consistent + with the statement of the security problem definition in the + PPs for which conformance is being claimed. + + + The conformance claim rationale shall demonstrate that the + statement of security objectives is consistent with the + statement of security objectives in the PPs for which + conformance is being claimed. + + + The conformance claim rationale shall demonstrate that the + statement of security requirements is consistent with the + statement of security requirements in the PPs for which + conformance is being claimed. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the conformance claim + contains a CC conformance claim that identifies the + version of the CC to which the ST and the TOE claim + conformance. + + The evaluator determines that the CC conformance claim + identifies the version of the CC that was used to + develop this ST. This should include the version number + of the CC and, unless the International English version + of the CC was used, the language of the version of the + CC that was used. + + For a composed TOE, the evaluator will consider any + differences between the version of the CC claimed for a + component and the version of the CC claimed for the + composed TOE. If the versions differ the evaluator will + assess whether the differences between the versions will + lead to conflicting claims. + + For instances where the CC conformance claims for the + base TOE and dependent TOE are for different major + releases of the CC (e.g. one component TOE conformance + claim is CC v2.x and the other component TOE conformance + claim is CC v3.x), the conformance claim for the + composed TOE will be the earlier release of the CC, as + the CC is developed with an aim to provide backwards + compatibility (although this may not be achieved in the + strictest sense, it is understood to be achieved in + principle). + + + + + The evaluator shall check that the CC conformance claim + states a claim of either CC Part 2 conformant or CC Part + 2 extended for the ST. + + For a composed TOE, the evaluator will consider whether + this claim is consistent not only with the CC Part 2, + but also with the claims of conformance to CC Part 2 by + each of the component TOEs. I.e. if one or more + component TOEs claims to be CC Part 2 extended, then the + composed TOE should also claim to be CC Part 2 + extended. + + The CC conformance claim for the composed TOE may be CC + Part 2 extended, even though the component TOEs are Part + 2 conformant, in the event that additional SFRs are + claimed for the base TOE (see composed TOE guidance for + ) + + + + + The evaluator shall check that the CC conformance claim + states a claim of either CC Part 3 conformant or CC Part + 3 extended for the ST. + + + + + The evaluator shall examine the CC conformance claim for + CC Part 2 to determine that it is consistent with the + extended components definition. + + If the CC conformance claim contains CC Part 2 + conformant, the evaluator determines that the extended + components definition does not define functional + components. + + If the CC conformance claim contains CC Part 2 extended, + the evaluator determines that the extended components + definition defines at least one extended functional + component. + + + + + The evaluator shall examine the CC conformance claim for + CC Part 3 to determine that it is consistent with the + extended components definition. + + If the CC conformance claim contains CC Part 3 + conformant, the evaluator determines that the extended + components definition does not define assurance + components. + + If the CC conformance claim contains CC Part 3 extended, + the evaluator determines that the extended components + definition defines at least one extended assurance + component. + + + + + The evaluator shall check that the conformance claim + contains a PP claim that identifies all PPs for which + the ST claims conformance. + + If the ST does not claim conformance to a PP, this work + unit is not applicable and therefore considered to be + satisfied. + + The evaluator determines that any referenced PPs are + unambiguously identified (e.g. by title and version + number, or by the identification included in the + introduction of that PP). + + The evaluator is reminded that claims of partial + conformance to a PP are not permitted. Therefore, + conformance to a PP requiring a composite solution may + be claimed in an ST for a composed TOE. Conformance to + such a PP would not have been possible during the + evaluation of the component TOEs, as these components + would not have satisfied the composed solution. This is + only possible in the instances where the ``composite'' PP + permits use of the composition evaluation approach (use + of components). + + The ST for a composed TOE will identify the STs of the + component TOEs from which the composed ST is comprised. + The composed TOE is essentially claiming conformance to + the STs of the component TOEs. + + + + + The evaluator shall check that the conformance claim + contains a package claim that identifies all packages to + which the ST claims conformance. + + If the ST does not claim conformance to a package, this + work unit is not applicable and therefore considered to + be satisfied. + + The evaluator determines that any referenced packages + are unambiguously identified (e.g. by title and version + number, or by the identification included in the + introduction of that package). + + The evaluator determines that the component TOE STs from + which the composed TOE is derived are also unambiguously + identified. + + The evaluator is reminded that claims of partial + conformance to a package are not permitted. + + + + + The evaluator shall check that, for each identified + package, the conformance claim states a claim of either + package-name conformant or package-name + augmented. + + If the ST does not claim conformance to a package, this + work unit is not applicable and therefore considered to + be satisfied. + + If the package conformance claim contains package-name + conformant, the evaluator determines that: + + + If the package is an assurance package, then the ST + contains all SARs included in the package, but no + additional SARs. + + + If the package is a functional package, then the ST + contains all SFRs included in the package, but no + additional SFRs. + + + + If the package conformance claim contains package-name + augmented, the evaluator determines that: + + + If the package is an assurance package then the ST + contains all SARs included in the package, and at + least one additional SAR or at least one SAR that is + hierarchical to a SAR in the package. + + + If the package is a functional package, then the ST + contains all SFRs included in the package, and at + least one additional SFR or at least one SFR that is + hierarchical to a SFR in the package. + + + + + + + The evaluator shall examine the conformance claim + rationale to determine that the TOE type of the TOE is + consistent with all TOE types of the PPs. + + If the ST does not claim conformance to a PP, this work + unit is not applicable and therefore considered to be + satisfied. + + The relation between the types may be simple: a firewall + ST claiming conformance to a firewall PP, or more + complex: a smart card ST claiming conformance to a number + of PPs at the same time (a PP for the integrated + circuit, a PP for the smart card OS, and two PPs for two + applications on the smart card). + + For a composed TOE, the evaluator will determine whether + the conformance claim rationale demonstrates that the + TOE types of the component TOEs are consistent with the + composed TOE type. This does not mean that both the + component and the composed TOE types have to be the + same, but rather that the component TOEs are suitable + for integration to provide the composed TOE. It should be made clear in the composed TOE ST which SFRs are only included as a result of composition, and were not examined as SFRs in the base and dependent TOE (e.g. EALx) evaluation. + + + + + The evaluator shall examine the conformance claim + rationale to determine that it demonstrates that the + statement of security problem definition is consistent, + as defined by the conformance statement of the PP, with + the statements of security problem definition stated in + the PPs to which conformance is being claimed. + + If the ST does not claim conformance with a PP, this + work unit is not applicable and therefore considered to + be satisfied. + + If the PP does not have a statement of security problem + definition, this work unit is not applicable and + therefore considered to be satisfied. + + If strict conformance is required by the PP to which + conformance is being claimed no conformance claim + rationale is required. Instead, the evaluator determines + whether: + + + the threats in the ST are a superset of or identical + to the threats in the PP to which conformance is + being claimed; + + + the OSPs in the ST are a superset of or identical to + the OSPs in the PP to which conformance is being + claimed; + + the assumptions in the ST are identical to the + assumptions in the PP to which conformance is being + claimed; + + If demonstrable conformance is required by the PP, the + evaluator examines the conformance claim rationale to + determine that it demonstrates that the statement of + security problem definition of the ST is equivalent or + more restrictive than the statement of security problem + definition in the PP to which conformance is being + claimed. + For guidance on ``equivalent or more restrictive'' + see CC Part 1 . + + For a composed TOE, the evaluator will consider whether + the security problem definition of the composed TOE is + consistent with that specified in the STs for the + component TOEs. This is determined in terms of + demonstrable conformance. In particular, the evaluator + examines the conformance claim rationale to determine + that: + + + Threat statements and OSPs in the composed TOE ST do + not contradict those from the component STs. + + Any assumptions made in the component STs are upheld + in the composed TOE ST. That is, either the + assumption should also be present in the composed + ST, or the assumption should be positively addressed + in the composed ST. The assumption may be + positively addressed through specification of + requirements in the composed TOE to provide + functionality fulfilling the concern captured in the + assumption. + + + + + The evaluator shall examine the conformance claim + rationale to determine that the statement of security + objectives is consistent, as defined by the conformance + statement of the PP, with the statement of security + objectives in the PPs to which conformance is being claimed. + + If the ST does not claim conformance to a PP, this work + unit is not applicable and therefore considered to be + satisfied. + + If strict conformance is required by the PP, no + conformance claim rationale is required. Instead, the + evaluator determines whether: + + The ST contains all security objectives for the + TOE of the PP to which conformance is being + claimed. Note that it is allowed for the ST under + evaluation to have additional security objectives + for the TOE; + The ST contains exactly all security objectives + for the operational environment (with one exception + in the next bullet). Note that it is not allowed for + the ST under evaluation to have additional security + objectives for the operational environment; + The ST may specify that certain objectives for + the operational environment in the PP that + conformance is being claimed to are security + objectives for the TOE in the ST. This is a valid + exception to the previous bullet. + + + If demonstrable conformance is required by the PP to + which conformance is being claimed, the evaluator + examines the conformance claim rationale to determine + that it demonstrates that the statement of security + objectives of the ST is equivalent or more restrictive + than the statement of security objectives in the PP to + which conformance is being claimed. + For guidance on ``equivalent or more restrictive'' + see CC Part 1 . + + For a composed TOE, the evaluator will consider whether + the security objectives of the composed TOE are + consistent with that specified in the STs for the + component TOEs. This is determined in terms of + demonstrable conformance. In particular, the evaluator + examines the conformance claim rationale to determine + that: + + + The statement of security objectives in the + dependent TOE ST relevant to any IT in the + operational environment are consistent with the + statement of security objectives for the TOE in the + base TOE ST. It is not expected that the statement + of security objectives for the environment within in + the dependent TOE ST will cover all aspects of the + statement of security objectives for the TOE in the + base TOE ST. + + The statement of security objectives in the composed + ST is consistent with the statements of security + objectives in the STs for the component TOEs. + + + If demonstrable conformance is required by the PP, the + evaluator examines the conformance claim rationale to + determine that it demonstrates that the statement of + security objectives of the ST is at least equivalent to + the statement of security objectives in the PP, or + component TOE ST in the case of a composed TOE + ST. + + + + + The evaluator shall examine the ST to determine that it + is consistent, as defined by the conformance statement + of the PP, with all security requirements in the PPs for + which conformance is being claimed. + + If the ST does not claim conformance to a PP, this work + unit is not applicable and therefore considered to be + satisfied. + + If strict conformance is required by the PP to which + conformance is being claimed, no conformance claim + rationale is required. Instead, the evaluator determines + whether the statement of security requirements in the ST + is a superset of or identical to the statement of + security requirements in the PP to which conformance is + being claimed (for strict conformance). + + If demonstrable conformance is required by the PP to + which conformance is being claimed, the evaluator + examines the conformance claim rationale to determine + that it demonstrates that the statement of security + requirements of the ST is equivalent or more restrictive + than the statement of security requirements in the PP to + which conformance is being claimed. + For guidance on ``equivalent or more restrictive'' + see CC Part 1 . + + + For a composed TOE, the evaluator will consider whether + the security requirements of the composed TOE are + consistent with that specified in the STs for the + component TOEs. This is determined in terms of + demonstrable conformance. In particular, the evaluator + examines the conformance rationale to determine that: + + + The statement of security requirements in the + dependent TOE ST relevant to any IT in the + operational environment is consistent with the + statement of security requirements for the TOE in + the base TOE ST. It is not expected that the + statement of security requirements for the + environment within in the dependent TOE ST will + cover all aspects of the statement of security + requirements for the TOE in the base TOE ST, as + some SFRs may need to be added to the statement of + security requirements in the composed TOE ST. + However, the statement of security requirements in + the base should support the operation of the dependent + component. + + The statement of security objectives in the + dependent TOE ST relevant to any IT in the + operational environment is consistent with the + statement of security requirements for the TOE in + the base TOE ST. It is not expected that the + statement of security objectives for the environment + within in the dependent TOE ST will cover all + aspects of the statement of security requirements + for the TOE in the base TOE ST. + + The statement of security requirements in the + composed is consistent with the statements of + security requirements in the STs for the component + TOEs. + + If demonstrable conformance is required by the PP to + which conformance is being claimed, the evaluator + examines the conformance claim rationale to determine + that it demonstrates that the statement of security + requirements of the ST is at least equivalent to the + statement of security requirements in the PP, or + component TOE ST in the case of a composed TOE + ST. + + + + + + + + This part of the ST defines the security problem to be + addressed by the TOE and the operational environment of the + TOE. + + Evaluation of the security problem definition is required to + demonstrate that the security problem intended to be + addressed by the TOE and its operational environment, is + clearly defined. + + + + The security problem definition defines the problem + addressed by the TOE and the operational environment of the + TOE. + + + + + The objective of this sub-activity is to determine that + the security problem intended to be addressed by the TOE + and its operational environment is clearly defined. + + + + The evaluation evidence for this sub-activity is: + + + the ST. + + + + + The developer shall provide a security problem definition. + + + The security problem definition shall describe the threats. + + + All threats shall be described in terms of a threat agent, + an asset, and an adverse action. + + + The security problem definition shall describe the OSPs. + + + The security problem definition shall describe the + assumptions about the operational environment of the TOE. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the security problem + definition describes the threats. + + If all security objectives are derived from assumptions + and/or OSPs only, the statement of threats need not be + present in the ST. In this case, this work unit is not + applicable and therefore considered to be + satisfied. + + The evaluator determines that the security problem + definition describes the threats that must be countered + by the TOE and/or operational environment. + + + + + The evaluator shall examine the security problem + definition to determine that all threats are described + in terms of a threat agent, an asset, and an adverse + action. + + If all security objectives are derived from assumptions + and/or OSPs only, the statement of threats need not be + present in the ST. In this case, this work unit is not + applicable and therefore considered to be + satisfied. + + Threat agents may be further described by aspects such + as expertise, resource, opportunity, and + motivation. + + + + + The evaluator shall examine that the security problem + definition describes the OSPs. + + If all security objectives are derived from assumptions + and threats only, OSPs need not be present in the ST. In + this case, this work unit is not applicable and + therefore considered to be satisfied. + + The evaluator determines that OSP statements are made in + terms of rules or guidelines that must be followed by + the TOE and/or its operational environment. + + The evaluator determines that each OSP is explained + and/or interpreted in sufficient detail to make it + clearly understandable; a clear presentation of policy + statements is necessary to permit tracing security + objectives to them. + + + + + The evaluator shall examine the security problem + definition to determine that it describes the + assumptions about the operational environment of the + TOE. + + If there are no assumptions, this work unit is not + applicable and is therefore considered to be + satisfied. + + The evaluator determines that each assumption about the + operational environment of the TOE is explained in + sufficient detail to enable consumers to determine that + their operational environment matches the assumption. If + the assumptions are not clearly understood, the end + result may be that the TOE is used in an operational + environment in which it will not function in a secure + manner. + + + + + + + + The security objectives are a concise statement of the + intended response to the security problem defined through + the family. + + Evaluation of the security objectives is required to + demonstrate that the security objectives adequately and + completely address the security problem definition, that the + division of this problem between the TOE and its operational + environment is clearly defined. + + + + The security objectives are a concise statement of the + intended response to the security problem. + + + + The components in this family are levelled on whether they + prescribe only security objectives for the operational + environment, or also security objectives for the TOE. + + + + + The objective of this sub-activity is to determine whether + the security objectives for the operational environment + are clearly defined. + + + + The evaluation evidence for this sub-activity is: + + + the ST. + + + + + The developer shall provide a statement of security + objectives. + + + The statement of security objectives shall describe the + security objectives for the operational environment. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the statement of security + objectives defines the security objectives for the + operational environment. + + The evaluator checks that the security objectives for + the operational environment are identified. + + + + + + + + + The objective of this sub-activity is to determine whether + the security objectives adequately and completely address + the security problem definition and that the division of + this problem between the TOE and its operational + environment is clearly defined. + + + + The evaluation evidence for this sub-activity is: + + + the ST. + + + + + The developer shall provide a statement of security + objectives. + + + The developer shall provide a security objectives rationale. + + + The statement of security objectives shall describe the + security objectives for the TOE and the security objectives + for the operational environment. + + + The security objectives rationale shall trace each security + objective for the TOE back to threats countered by that + security objective and OSPs enforced by that security + objective. + + + The security objectives rationale shall trace each security + objective for the operational environment back to threats + countered by that security objective, OSPs enforced by that + security objective, and assumptions upheld by that security + objective. + + + The security objectives rationale shall demonstrate that the + security objectives counter all threats. + + + The security objectives rationale shall demonstrate that the + security objectives enforce all OSPs. + + + The security objectives rationale shall demonstrate that the + security objectives for the operational environment uphold + all assumptions. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the statement of security + objectives defines the security objectives for the TOE + and the security objectives for the operational + environment. + + The evaluator checks that both categories of security + objectives are clearly identified and separated from the + other category. + + + + + The evaluator shall check that the security objectives + rationale traces all security objectives for the TOE + back to threats countered by the objectives and/or OSPs + enforced by the objectives. + + Each security objective for the TOE may trace back to + threats or OSPs, or a combination of threats and OSPs, + but it must trace back to at least one threat or + OSP. + + Failure to trace implies that either the security + objectives rationale is incomplete, the security problem + definition is incomplete, or the security objective for + the TOE has no useful purpose. + + + + + The evaluator shall check that the security objectives + rationale traces the security objectives for the + operational environment back to threats countered by + that security objective, to OSPs enforced by that + security objective, and to assumptions upheld by that + security objective. + + Each security objective for the operational environment + may trace back to threats, OSPs, assumptions, or a + combination of threats, OSPs and/or assumptions, but it + must trace back to at least one threat, OSP or + assumption. + + Failure to trace implies that either the security + objectives rationale is incomplete, the security problem + definition is incomplete, or the security objective for + the operational environment has no useful + purpose. + + + + + The evaluator shall examine the security objectives + rationale to determine that it justifies for each threat + that the security objectives are suitable to counter + that threat. + + If no security objectives trace back to the threat, + the evaluator action related to this work unit is assigned a fail verdict. + + The evaluator determines that the justification for a + threat shows whether the threat is removed, diminished + or mitigated. + + The evaluator determines that the justification for a + threat demonstrates that the security objectives are + sufficient: if all security objectives that trace back + to the threat are achieved, the threat is removed, + sufficiently diminished, or the effects of the threat + are sufficiently mitigated. + + Note that the tracings from security objectives to + threats provided in the security objectives rationale + may be part of a justification, but do not constitute a + justification by themselves. Even in the case that a + security objective is merely a statement reflecting the + intent to prevent a particular threat from being + realised, a justification is required, but this + justification may be as minimal as ``Security Objective + X directly counters Threat Y''. + + The evaluator also determines that each security + objective that traces back to a threat is necessary: + when the security objective is achieved it actually + contributes to the removal, diminishing or mitigation of + that threat. + + + + + The evaluator shall examine the security objectives + rationale to determine that for each OSP it justifies + that the security objectives are suitable to enforce + that OSP. + + If no security objectives trace back to the OSP, + the evaluator action related to this work unit is assigned a fail verdict. + + The evaluator determines that the justification for an + OSP demonstrates that the security objectives are + sufficient: if all security objectives that trace back + to that OSP are achieved, the OSP is enforced. + + The evaluator also determines that each security + objective that traces back to an OSP is necessary: when + the security objective is achieved it actually + contributes to the enforcement of the OSP. + + Note that the tracings from security objectives to OSPs + provided in the security objectives rationale may be + part of a justification, but do not constitute a + justification by themselves. In the case that a security + objective is merely a statement reflecting the intent to + enforce a particular OSP, a justification is required, + but this justification may be as minimal as ``Security + Objective X directly enforces OSP Y''. + + + + + The evaluator shall examine the security objectives + rationale to determine that for each assumption for the + operational environment it contains an appropriate + justification that the security objectives for the + operational environment are suitable to uphold that + assumption. + + If no security objectives for the operational environment trace back to the assumption, + the evaluator action related to this work unit is assigned a fail verdict. + + The evaluator determines that the justification for an + assumption about the operational environment of the TOE + demonstrates that the security objectives are + sufficient: if all security objectives for the + operational environment that trace back to that + assumption are achieved, the operational environment + upholds the assumption. + + The evaluator also determines that each security + objective for the operational environment that traces + back to an assumption about the operational environment + of the TOE is necessary: when the security objective is + achieved it actually contributes to the operational + environment upholding the assumption. + + Note that the tracings from security objectives for the + operational environment to assumptions provided in the + security objectives rationale may be a part of a + justification, but do not constitute a justification by + themselves. Even in the case that a security objective + of the operational environment is merely a restatement + of an assumption, a justification is required, but this + justification may be as minimal as ``Security Objective + X directly upholds Assumption Y''. + + + + + + + + Extended security requirements are requirements that are not + based on components from CC Part 2 or CC Part 3, but are + based on extended components: components defined by the ST + author. + + Evaluation of the definition of extended components is + necessary to determine that they are clear and unambiguous, + and that they are necessary, i.e. they may not be clearly + expressed using existing CC Part 2 or CC Part 3 + components. + + + + Extended components are defined wherever it is impossible to + clearly express requirements using only components from CC + Part 2 and/or CC Part 3. + + + + + The objective of this sub-activity is to determine whether + extended components have been clearly and unambiguously + defined, and whether they are necessary, i.e. they may not + be clearly expressed using existing CC Part 2 or CC Part 3 + components. + + + + The evaluation evidence for this sub-activity is: + + + the ST. + + + + + The developer shall provide a statement of security + requirements. + + + The developer shall provide an extended components + definition. + + + The statement of security requirements shall identify all + extended security requirements. + + + The extended components definition shall define an extended + component for each extended security requirement. + + + The extended components definition shall describe how each + extended component is related to the existing CC components, + families, and classes. + + + The extended components definition shall use the existing CC + components, families, classes, and methodology as a model + for presentation. + + + The extended components shall consist of measurable and + objective elements such that conformance or nonconformance + to these elements can be demonstrated. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that all security requirements + in the statement of security requirements that are not + identified as extended requirements are present in CC + Part 2 or in CC Part 3. + + + + + The evaluator shall check that the extended components + definition defines an extended component for each + extended security requirement. + + If the ST does not contain extended security + requirements, this work unit is not applicable and + therefore considered to be satisfied. + + A single extended component may be used to define + multiple iterations of an extended security requirement, + it is not necessary to repeat this definition for each + iteration. + + + + + The evaluator shall examine the extended components + definition to determine that it describes how each + extended component fits into the existing CC components, + families, and classes. + + If the ST does not contain extended security + requirements, this work unit is not applicable and + therefore considered to be satisfied. + + The evaluator determines that each extended component is + either: + + + a member of an existing CC Part 2 or CC Part 3 + family, or + + a member of a new family defined in the ST. + + + If the extended component is a member of an existing CC + Part 2 or CC Part 3 family, the evaluator determines + that the extended components definition adequately + describes why the extended component should be a member + of that family and how it relates to other components of + that family. + + If the extended component is a member of a new family + defined in the ST, the evaluator confirms that the + extended component is not appropriate for an existing + family. + + If the ST defines new families, the evaluator determines + that each new family is either: + + + a member of an existing CC Part 2 or CC Part 3 + class, or + + a member of a new class defined in the ST. + + + If the family is a member of an existing CC Part 2 or CC + Part 3 class, the evaluator determines that the extended + components definition adequately describes why the + family should be a member of that class and how it + relates to other families in that class. + + If the family is a member of a new class defined in the + ST, the evaluator confirms that the family is not + appropriate for an existing class. + + + + + The evaluator shall examine the extended components + definition to determine that each definition of an + extended component identifies all applicable + dependencies of that component. + + If the ST does not contain extended security + requirements, this work unit is not applicable and + therefore considered to be satisfied. + + The evaluator confirms that no applicable dependencies + have been overlooked by the ST author. + + + + + The evaluator shall examine the extended components + definition to determine that each extended functional + component uses the existing CC Part 2 components as a + model for presentation. + + If the ST does not contain extended SFRs, this work unit + is not applicable and therefore considered to be + satisfied. + + The evaluator determines that the extended functional + component is consistent with CC Part 2 Subclause . + + If the extended functional component uses operations, the + evaluator determines that the extended functional component is + consistent with CC Part 1 Subclause . + + If the extended functional component is hierarchical to + an existing functional component, the evaluator + determines that the extended functional component is + consistent with CC Part 2 Subclause . + + + + + The evaluator shall examine the extended components + definition to determine that each definition of a new + functional family uses the existing CC functional + families as a model for presentation. + + If the ST does not define new functional families, this + work unit is not applicable and therefore considered to + be satisfied. + + The evaluator determines that all new functional + families are defined consistent with CC Part 2 Subclause + . + + + + + The evaluator shall examine the extended components + definition to determine that each definition of a new + functional class uses the existing CC functional classes + as a model for presentation. + + If the ST does not define new functional classes, this + work unit is not applicable and therefore considered to + be satisfied. + + The evaluator determines that all new functional classes + are defined consistent with CC Part 2 Subclause . + + + + + The evaluator shall examine the extended components + definition to determine that each definition of an + extended assurance component uses the existing CC Part 3 + components as a model for presentation. + + If the ST does not contain extended SARs, this work unit + is not applicable and therefore considered to be + satisfied. + + The evaluator determines that the extended assurance + component definition is consistent with CC Part 3 + Subclause . + + If the extended assurance component uses operations, the + evaluator determines that the extended assurance component is + consistent with CC Part 1 Subclause . + + If the extended assurance component is hierarchical to + an existing assurance component, the evaluator + determines that the extended assurance component is + consistent with CC Part 3 Subclause . + + + + + The evaluator shall examine the extended components + definition to determine that, for each defined extended + assurance component, applicable methodology has been + provided. + + If the ST does not contain extended SARs, this work unit + is not applicable and therefore considered to be + satisfied. + + The evaluator determines that, for each evaluator action + element of each extended SAR, one or more work units are + provided and that successfully performing all work units + for a given evaluator action element will demonstrate + that the element has been achieved. + + + + + The evaluator shall examine the extended components + definition to determine that each definition of a new + assurance family uses the existing CC assurance families + as a model for presentation. + + If the ST does not define new assurance families, this + work unit is not applicable and therefore considered to + be satisfied. + + The evaluator determines that all new assurance families + are defined consistent with CC Part 3 Subclause . + + + + + The evaluator shall examine the extended components + definition to determine that each definition of a new + assurance class uses the existing CC assurance classes + as a model for presentation. + + If the ST does not define new assurance classes, this + work unit is not applicable and therefore considered to + be satisfied. + + The evaluator determines that all new assurance classes + are defined consistent with CC Part 3 Subclause . + + + + + The evaluator shall examine the extended components + definition to determine that each element in each + extended component is measurable and states objective + evaluation requirements, such that conformance or + nonconformance can be demonstrated. + + If the ST does not contain extended security + requirements, this work unit is not applicable and + therefore considered to be satisfied. + + The evaluator determines that elements of extended + functional components are stated in such a way that they + are testable, and traceable through the appropriate TSF + representations. + + The evaluator also determines that elements of extended + assurance components avoid the need for subjective + evaluator judgement. + + The evaluator is reminded that whilst being measurable + and objective is appropriate for all evaluation + criteria, it is acknowledged that no formal method + exists to prove such properties. Therefore the existing + CC functional and assurance components are to be used as + a model for determining what constitutes conformance + with this requirement. + + + + The evaluator shall confirm that no extended component can + be clearly expressed using existing components. + + + The evaluator shall examine the extended components + definition to determine that each extended component can + not be clearly expressed using existing + components. + + If the ST does not contain extended security + requirements, this work unit is not applicable and + therefore considered to be satisfied. + + The evaluator should take components from CC Part 2 and + CC Part 3, other extended components that have been + defined in the ST, combinations of these components, and + possible operations on these components into account + when making this determination. + + The evaluator is reminded that the role of this work + unit is to preclude unnecessary duplication of + components, that is, components that may be clearly + expressed by using other components. The evaluator + should not undertake an exhaustive search of all + possible combinations of components including operations + in an attempt to find a way to express the extended + component by using existing components. + + + + + + + + The SFRs form a clear, unambiguous and well-defined + description of the expected security behaviour of the + TOE. The SARs form a clear, unambiguous and canonical + description of the expected activities that will be + undertaken to gain assurance in the TOE. + + Evaluation of the security requirements is required to + ensure that they are clear, unambiguous and + well-defined. + + + + The SFRs form a clear, unambiguous and well-defined + description of the expected security behaviour of the + TOE. The SARs form a clear, unambiguous and well-defined + description of the expected activities that will be + undertaken to gain assurance in the TOE. + + + + The components in this family are levelled on whether they + are stated as is. + + + + + + The objective of this sub-activity is to determine whether + the SFRs and SARs are clear, unambiguous and well-defined + and whether they are internally consistent. + + + + The evaluation evidence for this sub-activity is: + + + the ST. + + + + + The developer shall provide a statement of security requirements. + + + The developer shall provide a security requirements + rationale. + + + The statement of security requirements shall describe the + SFRs and the SARs. + + + All subjects, objects, operations, security attributes, + external entities and other terms that are used in the SFRs + and the SARs shall be defined. + + + The statement of security requirements shall identify all + operations on the security requirements. + + + All operations shall be performed correctly. + + + Each dependency of the security requirements shall either be + satisfied, or the security requirements rationale shall + justify the dependency not being satisfied. + + + The statement of security requirements shall be internally + consistent. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the statement of security + requirements describes the SFRs. + + The evaluator determines that each SFR is identified by + one of the following means: + + + by reference to an individual component in CC Part + 2; + + + by reference to an extended component in the + extended components definition of the ST; + + + by reference to a PP that the ST claims to be + conformant with; + + + by reference to a security requirements package that + the ST claims to be conformant with; + + + by reproduction in the ST. + + It is not required to use the same means of + identification for all SFRs. + + + + + The evaluator shall check that the statement of security + requirements describes the SARs. + + The evaluator determines that each SAR is identified by + one of the following means: + + + by reference to an individual component in CC Part + 3; + + + by reference to an extended component in the + extended components definition of the ST; + + + by reference to a PP that the ST claims to be + conformant with; + + + by reference to a security requirements package that + the ST claims to be conformant with; + + + by reproduction in the ST. + + It is not required to use the same means of + identification for all SARs. + + + + + The evaluator shall examine the ST to determine that all + subjects, objects, operations, security attributes, + external entities and other terms that are used in the + SFRs and the SARs are defined. + + The evaluator determines that the ST defines all: + + (types of) subjects and objects that are used in + the SFRs; + (types of) security attributes of subjects, users, + objects, information, sessions and/or resources, possible + values that these attributes may take and any relations + between these values (e.g. top_secret is ``higher'' than secret); + (types of) operations that are used in the SFRs, + including the effects of these operations; + (types of) external entities in the SFRs; + other terms that are introduced in the SFRs + and/or SARs by completing operations, if these terms + are not immediately clear, or are used outside their + dictionary definition. + + The goal of this work unit is to ensure that the SFRs + and SARs are well-defined and that no misunderstanding + may occur due to the introduction of vague terms. This + work unit should not be taken into extremes, by forcing + the ST writer to define every single word. The general + audience of a set of security requirements should be + assumed to have a reasonable knowledge of IT, security + and Common Criteria. + + All of the above may be presented in groups, classes, + roles, types or other groupings or characterisations + that allow easy understanding. + + The evaluator is reminded that these lists and + definitions do not have to be part of the statement of + security requirements, but may be placed (in part or in + whole) in different subclauses. This may be especially + applicable if the same terms are used in the rest of the + ST. + + + + + The evaluator shall check that the statement of security + requirements identifies all operations on the security + requirements. + + The evaluator determines that all operations are + identified in each SFR or SAR where such an operation is + used. Identification may be achieved by typographical + distinctions, or by explicit identification in the + surrounding text, or by any other distinctive + means. + + + + + The evaluator shall examine the statement of security + requirements to determine that all assignment operations + are performed correctly. + + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that all iteration operations + are performed correctly. + + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that all selection operations + are performed correctly. + + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that all refinement operations + are performed correctly. + + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that each dependency of the + security requirements is either satisfied, or that a + security requirements rationale is provided which justifies the dependency + not being satisfied. + + A dependency is satisfied by the inclusion of the + relevant component (or one that is hierarchical to it) + within the statement of security requirements. The + component used to satisfy the dependency should, if + necessary, be modified by operations to ensure that it + actually satisfies that dependency. + + A justification that a dependency is not met should + address either: + + + why the dependency is not necessary or useful, in + which case no further information is required; or + + + that the dependency has been addressed by the + operational environment of the TOE, in which case + the justification should describe how the security + objectives for the operational environment address + this dependency. + + + + + + + The evaluator shall examine the statement of security + requirements to determine that it is internally + consistent. + + The evaluator determines that the combined set of all + SFRs and SARs is internally consistent. + + The evaluator determines that on all occasions where + different security requirements apply to the same types + of developer evidence, events, operations, data, tests + to be performed etc. or to ``all objects'', ``all + subjects'' etc., that these requirements do not + conflict. + Some possible conflicts are: + + + an extended SAR specifying that the design of a + certain cryptographic algorithm is to be kept + secret, and another extended SAR specifying an open + source review; + + specifying + that subject identity is to be logged, specifying who has + access to these logs, and specifying that some actions of + subjects should be unobservable to other + subjects. If the subject that should not be able to + see an activity may access logs of this activity, + these SFRs conflict; + + specifying + deletion of information no longer needed, and specifying that a TOE + may return to a previous state. If the information + that is needed for the rollback to the previous + state has been deleted, these requirements conflict; + + + Multiple iterations of especially where some iterations cover + the same subjects, objects, or operations. If one + access control SFR allows a subject to perform an + operation on an object, while another access control + SFR does not allow this, these requirements + conflict. + + + + + + + + + + + + The objective of this sub-activity is to determine whether + the SFRs and SARs are clear, unambiguous and well-defined, + whether they are internally consistent, and whether the + SFRs meet the security objectives of the TOE. + + + + The evaluation evidence for this sub-activity is: + + + the ST. + + + + + The developer shall provide a statement of security requirements. + + + The developer shall provide a security requirements + rationale. + + + The statement of security requirements shall describe the + SFRs and the SARs. + + All subjects, objects, + operations, security attributes, external entities and other + terms that are used in the SFRs and the SARs shall be + defined. + + + The statement of security requirements shall identify all + operations on the security requirements. + + + All operations shall be performed correctly. + + + Each dependency of the security requirements shall either be + satisfied, or the security requirements rationale shall + justify the dependency not being satisfied. + + + The security requirements rationale shall trace each SFR + back to the security objectives for the TOE. + + + The security requirements rationale shall demonstrate that + the SFRs meet all security objectives for the TOE. + + + The security requirements rationale shall explain why the + SARs were chosen. + + + The statement of security requirements shall be internally + consistent. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the statement of security + requirements describes the SFRs. + + The evaluator determines that each SFRs is identified by + one of the following means: + + + by reference to an individual component in CC Part + 2; + + + by reference to an extended component in the + extended components definition of the ST; + + + by reference to an individual component in a PP that + the ST claims to be conformant with; + + + by reference to an individual component in a + security requirements package that the ST claims to + be conformant with; + + + by reproduction in the ST. + + It is not required to use the same means of + identification for all SFRs. + + + + + The evaluator shall check that the statement of security + requirements describes the SARs. + + The evaluator determines that all SARs are identified by + one of the following means: + + + by reference to an individual component in CC Part + 3; + + + by reference to an extended component in the + extended components definition of the ST; + + + by reference to an individual component in a PP that + the ST claims to be conformant with; + + + by reference to an individual component in a + security requirements package that the ST claims to + be conformant with; + + + by reproduction in the ST. + + It is not required to use the same means of + identification for all SARs. + + + + + The evaluator shall examine the ST to determine that all + subjects, objects, operations, security attributes, + external entities and other terms that are used in the + SFRs and the SARs are defined. + + The evaluator determines that the ST defines all: + + (types of) subjects and objects that are used in + the SFRs; + (types of) security attributes of subjects, users, + objects, information, sessions and/or resources, possible + values that these attributes may take and any relations + between these values (e.g. top_secret is ``higher'' than secret); + (types of) operations that are used in the SFRs, + including the effects of these operations; + (types of) external entities in the SFRs; + other terms that are introduced in the SFRs + and/or SARs by completing operations, if these terms + are not immediately clear, or are used outside their + dictionary definition. + + The goal of this work unit is to ensure that the SFRs + and SARs are well-defined and that no misunderstanding + may occur due to the introduction of vague terms. This + work unit should not be taken into extremes, by forcing + the ST writer to define every single word. The general + audience of a set of security requirements should be + assumed to have a reasonable knowledge of IT, security + and Common Criteria. + + All of the above may be presented in groups, classes, + roles, types or other groupings or characterisations + that allow easy understanding. + + The evaluator is reminded that these lists and + definitions do not have to be part of the statement of + security requirements, but may be placed (in part or in + whole) in different subclauses. This may be especially + applicable if the same terms are used in the rest of the + ST. + + + + + The evaluator shall check that the statement of security + requirements identifies all operations on the security + requirements. + + The evaluator determines that all operations are + identified in each SFR or SAR where such an operation is + used. Identification may be achieved by typographical + distinctions, or by explicit identification in the + surrounding text, or by any other distinctive + means. + + + + + The evaluator shall examine the statement of security + requirements to determine that all assignment operations + are performed correctly. + + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that all iteration operations + are performed correctly. + + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that all selection operations + are performed correctly. + + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that all refinement operations + are performed correctly. + + Guidance on the correct performance of operations may be found + in CC Part 1 Annex . + + + + + The evaluator shall examine the statement of security + requirements to determine that each dependency of the + security requirements is either satisfied, or that the + security requirements rationale justifies the dependency + not being satisfied. + + A dependency is satisfied by the inclusion of the + relevant component (or one that is hierarchical to it) + within the statement of security requirements. The + component used to satisfy the dependency should, if + necessary, be modified by operations to ensure that it + actually satisfies that dependency. + + A justification that a dependency is not met should + address either: + + + why the dependency is not necessary or useful, in + which case no further information is required; or + + + that the dependency has been addressed by the + operational environment of the TOE, in which case + the justification should describe how the security + objectives for the operational environment address + this dependency. + + + + + + + The evaluator shall check that the security requirements + rationale traces each SFR back to the security + objectives for the TOE. + + The evaluator determines that each SFR is traced back to + at least one security objective for the TOE. + + Failure to trace implies that either the security + requirements rationale is incomplete, the security + objectives for the TOE are incomplete, or the SFR has no + useful purpose. + + + + + The evaluator shall examine the security requirements + rationale to determine that for each security objective + for the TOE it demonstrates that the SFRs are suitable + to meet that security objective for the TOE. + + If no SFRs trace back to the security objective for the TOE, + the evaluator action related to this work unit is assigned a fail verdict. + + The evaluator determines that the justification for a + security objective for the TOE demonstrates that the + SFRs are sufficient: if all SFRs that trace back to the + objective are satisfied, the security objective for the + TOE is achieved. + + The evaluator also determines that each SFR that traces + back to a security objective for the TOE is necessary: + when the SFR is satisfied, it actually contributes to + achieving the security objective. + + Note that the tracings from SFRs to security objectives + for the TOE provided in the security requirements + rationale may be a part of the justification, but do not + constitute a justification by themselves. + + + + + The evaluator shall check that the security requirements + rationale explains why the SARs were chosen. + + The evaluator is reminded that any explanation is correct, as + long as it is coherent and neither the SARs nor the explanation + have obvious inconsistencies with the remainder of the ST. + + An example of an obvious inconsistency between the SARs and the + remainder of the ST would be to have threat agents that are very + capable, but an SAR that does not + protect against these threat agents. + + + + + The evaluator shall examine the statement of security + requirements to determine that it is internally + consistent. + + The evaluator determines that the combined set of all + SFRs and SARs is internally consistent. + + The evaluator determines that on all occasions where + different security requirements apply to the same types + of developer evidence, events, operations, data, tests + to be performed etc. or to ``all objects'', ``all + subjects'' etc., that these requirements do not + conflict. + + Some possible conflicts are: + + + an extended SAR specifying that the design of a + certain cryptographic algorithm is to be kept + secret, and another extended assurance requirement + specifying an open source review; + + specifying + that subject identity is to be logged, specifying who has + access to these logs, and specifying that some actions of + subjects should be unobservable to other + subjects. If the subject that should not be able to + see an activity may access logs of this activity, + these SFRs conflict; + + specifying + deletion of information no longer needed, and specifying that a TOE + may return to a previous state. If the information + that is needed for the rollback to the previous + state has been deleted, these requirements conflict; + + + Multiple iterations of especially where some iterations cover + the same subjects, objects, or operations. If one + access control SFR allows a subject to perform an + operation on an object, while another access control + SFR does not allow this, these requirements + conflict. + + + + + + + + + + The TOE summary specification enables evaluators and + potential consumers to gain a general understanding of how + the TOE is implemented. + + Evaluation of the TOE summary specification is necessary to + determine whether it is adequately described how the TOE: + + meets its SFRs; + protects itself against interference, logical + tampering and bypass. and whether the TOE + summary specification is consistent with other narrative + descriptions of the TOE. + + + + The TOE Summary specification allows evaluators and + potential consumers of the TOE to gain a general + understanding of how the TOE: + + meets its SFRs; + protects itself against interference, logical + tampering and bypass. + + + + The components in this family are levelled on whether the + TOE summary specification only needs to describe how the TOE + meets the SFRs, or whether the TOE summary specification + also needs to describe how the TOE protects itself against + logical tampering and bypass. This additional description + may be used in special circumstances where there might be a + specific concern regarding the TOE security architecture. + + + + + + + The objective of this sub-activity is to determine whether + the TOE summary specification addresses all SFRs, and + whether the TOE summary specification is consistent with + other narrative descriptions of the TOE. + + + + The evaluation evidence for this sub-activity is: + + + the ST. + + + + + The developer shall provide a TOE summary specification. + + + The TOE summary specification shall describe how the TOE + meets each SFR. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the TOE summary + specification to determine that it describes how the TOE + meets each SFR. + + The evaluator determines that the TOE summary + specification provides, for each SFR from the statement + of security requirements, a description on how that SFR + is met. + + The evaluator is reminded that the objective of each description is to provide + potential consumers of the TOE with a high-level view of how the developer intends + to satisfy each SFR and that the descriptions therefore should not be overly detailed. + Often several SFRs will be implemented in one context; for instance a password + authentication mechanism may implement , + and . + Therefore usually the TSS will not consist of a long list with texts for each single + SFR, but complete groups of SFRs may be covered by one text passage. + + For a composed TOE, the evaluator also determines that + it is clear which component provides each SFR or how the + components combine to meet each SFR. + + + + The evaluator shall confirm that the TOE summary + specification is consistent with the TOE overview and the + TOE description. + + + The evaluator shall examine the TOE summary + specification to determine that it is consistent with + the TOE overview and the TOE description. + + The TOE overview, TOE description, and TOE summary + specification describe the TOE in a narrative form at + increasing levels of detail. These descriptions + therefore need to be consistent. + + + + + + + + + + The objective of this sub-activity is to determine whether + the TOE summary specification addresses all SFRs, whether + the TOE summary specification addresses interference, + logical tampering and bypass, and whether the TOE summary + specification is consistent with other narrative + descriptions of the TOE. + + + + The evaluation evidence for this sub-activity is: + + + the ST. + + + + + The developer shall provide a TOE summary specification. + + + The TOE summary specification shall describe how the TOE + meets each SFR. + + + The TOE summary specification shall describe how the TOE + protects itself against interference and logical tampering. + + + The TOE summary specification shall describe how the TOE + protects itself against bypass. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the TOE summary + specification to determine that it describes how the TOE + meets each SFR. + + The evaluator determines that the TOE summary + specification provides, for each SFR from the statement + of security requirements, a description on how that SFR + is met. + + The evaluator is reminded that the objective of each description is to provide + potential consumers of the TOE with a high-level view of how the developer intends + to satisfy each SFR and that the descriptions therefore should not be overly detailed. + Often several SFRs will be implemented in one context; for instance a password + authentication mechanism may implement , + and . + Therefore usually the TSS will not consist of a long list with texts for each single + SFR, but complete groups of SFRs may be covered by one text passage. + + For a composed TOE, the evaluator also determines that + it is clear which component provides each SFR or how the + components combine to meet each SFR. + + + + + The evaluator shall examine the TOE summary + specification to determine that it describes how the TOE + protects itself against interference and logical + tampering. + + The evaluator is reminded that the objective of each + description is to provide potential consumers of the TOE + with a high-level view of how the developer intends to + provide protection against interference and logical + tampering and that the descriptions therefore should not + be overly detailed. + + For a composed TOE, the evaluator also determines that + it is clear which component provides the protection or + how the components combine to provide protection. + + + + + The evaluator shall examine the TOE summary + specification to determine that it describes how the TOE + protects itself against bypass. + + The evaluator is reminded that the objective of each + description is to provide potential consumers of the TOE + with a high-level view of how the developer intends to + provide protection against bypass and that the + descriptions therefore should not be overly + detailed. + + For a composed TOE, the evaluator also determines that + it is clear which component provides the protection or + how the components combine to provide protection. + + + + The evaluator shall confirm that the TOE summary + specification is consistent with the TOE overview and the + TOE description. + + + The evaluator shall examine the TOE summary + specification to determine that it is consistent with + the TOE overview and the TOE description. + + The TOE overview, TOE description, and TOE summary + specification describe the TOE in a narrative form at + increasing levels of detail. These descriptions + therefore need to be consistent. + + + + + + + + + The class ``Tests'' encompasses four families: , , + (i.e. functional testing + performed by evaluators), and . Testing provides assurance that the TSF + behaves as described (in the functional specification, TOE + design, and implementation representation). + + The emphasis in this class is on confirmation that the TSF + operates according to its design descriptions. This class does + not address penetration testing, which is based upon an + analysis of the TSF that specifically seeks to identify + vulnerabilities in the design and implementation of the + TSF. Penetration testing is addressed separately as an aspect + of vulnerability assessment in the class. + + The class separates testing into + developer testing and evaluator testing. The and families address the completeness of developer + testing. addresses the rigour + with which the functional specification is tested; addresses whether testing against + other design descriptions (security architecture, TOE design, + implementation representation) is required. + + addresses the performing of + the tests by the developer and how this testing should be + documented. Finally, then + addresses evaluator testing: whether the evaluator should + repeat part or all of the developer testing and how much + independent testing the evaluator should do. + + + + Assurance class states testing + requirements that demonstrate that the TOE matches its design + descriptions as provided in the + class. + + + + The goal of this activity is to determine whether the TOE + behaves as described in the ST and as specified in the + evaluation evidence (described in the class). This determination is achieved through + some combination of the developer's own functional testing of + the TSF () and independent + testing the TSF by the evaluator (). At the lowest level of assurance, there is no + requirement for developer involvement, so the only testing is + conducted by the evaluator, using the limited available + information about the TOE. Additional assurance is gained as + the developer becomes increasingly involved both in testing + and in providing additional information about the TOE, and as + the evaluator increases the independent testing + activities. + + + + Testing of the TSF is conducted by the evaluator and, in most + cases, by the developer. The evaluator's testing efforts + consist not only of creating and running original tests, but + also of assessing the adequacy of the developer's tests and + re-running a subset of them. + + The evaluator analyses the developer's tests to determine the + extent to which they are sufficient to demonstrate that TSFI + (see ) perform as specified, + and to understand the developer's approach to + testing. Similarly, the evaluator analyses the developer's + tests to determine the extent to which they are sufficient to + demonstrate the internal behaviour and properties of the + TSF. + The evaluator also executes a subset of the developer's + tests as documented to gain confidence in the developer's test + results: the evaluator will use the results of this analysis + as an input to independently testing a subset of the TSF. With + respect to this subset, the evaluator takes a testing approach + that is different from that of the developer, particularly if + the developer's tests have shortcomings. + + To determine the adequacy of developer's test documentation or + to create new tests, the evaluator needs to understand the + desired expected behaviour of the TSF, both internally and as + seen at the TSFI, in the context of the SFRs it is to + satisfy. The evaluator may choose to divide the TSF and TSFI + into subsets according to functional areas of the ST (audit + subsystem, audit-related TSFI, authentication module, + authentication-related TSFI, etc.) if they were not already + divided in the ST, and focus on one subset of the TSF and TSFI + at a time, examining the ST requirement and the relevant parts + of the development and guidance documentation to gain an + understanding of the way the TOE is expected to behave. This + reliance upon the development documentation underscores the need + for the dependencies on by and . + + The CC has separated coverage and depth from functional tests + to increase the flexibility when applying the components of + the families. However, the requirements of the families are + intended to be applied together to confirm that the TSF + operates according to its specification. This tight coupling + of families has led to some duplication of evaluator work + units across sub-activities. These application notes are used + to minimise duplication of text between sub-activities. + + + Before the adequacy of test documentation can be accurately + evaluated, or before new tests can be created, the evaluator + has to understand the desired expected behaviour of a + security function in the context of the requirements it is + to satisfy. + + As mentioned earlier, the evaluator may choose to subset the + TSF and TSFI according to SFRs (audit, authentication, etc.) + in the ST and focus on one subset at a time. The evaluator + examines each ST requirement and the relevant parts of the + functional specification and guidance documentation to gain + an understanding of the way the related TSFI is expected to + behave. Similarly, the evaluator examines the relevant parts + of the TOE design and security architecture documentation to + gain an understanding of the way the related modules or + subsystems of the TSF are expected to behave. + + With an understanding of the expected behaviour, the + evaluator examines the test plan to gain an understanding of + the testing approach. In most cases, the testing approach + will entail a TSFI being stimulated and its responses + observed. Externally-visible functionality can be tested + directly; however, in cases where functionality is not + visible external to the TOE (for example, testing the + residual information protection functionality), other means + will need to be employed. + + + + In cases where it is impractical or inadequate to test + specific functionality (where it provides no + externally-visible TSFI), the test plan should identify the + alternate approach to verify expected behaviour. It is the + evaluator's responsibility to determine the suitability of + the alternate approach. However, the following should be + considered when assessing the suitability of alternate + approaches: + + + an analysis of the implementation representation to + determine that the required behaviour should be + exhibited by the TOE is an acceptable alternate + approach. This could mean a code inspection for a + software TOE or perhaps a chip mask inspection for a + hardware TOE. + + + it is acceptable to use evidence of developer + integration or module testing, even if the claimed + assurance requirements do not include availability of + lower level descriptions of the TOE modules (e.g. ) or implementation (). If evidence of developer + integration or module testing is used in verifying the + expected behaviour of a security functionality, care + should be given to confirm that the testing evidence + reflects the current implementation of the TOE. If the + subsystems or modules have been changed since testing + occurred, evidence that the changes were tracked and + addressed by analysis or further testing will usually be + required. + + + + It should be emphasised that supplementing the testing + effort with alternate approaches should only be undertaken + when both the developer and evaluator determine that there + exists no other practical means to test the expected + behaviour. + + + + Test pre-requisites are necessary to establish the required + initial conditions for the test. They may be expressed in + terms of parameters that must be set or in terms of test + ordering in cases where the completion of one test + establishes the necessary pre-requisites for another + test. The evaluator must determine that the pre-requisites + are complete and appropriate in that they will not bias the + observed test results towards the expected test + results. + + The test steps and expected results specify the actions and + parameters to be applied to the TSFI as well as how the + expected results should be verified and what they are. The + evaluator must determine that the test steps and expected + results are consistent with the descriptions of the TSFI in + the functional specification. This means that each + characteristic of the TSFI behaviour explicitly described in + the functional specification should have tests and expected + results to verify that behaviour. + + The overall aim of this testing activity is to determine + that each subsystem, module, and TSFI has been sufficiently + tested against the behavioural claims in the functional + specification, TOE design, and architecture description. At + the higher assurance levels, testing also includes bounds + testing and negative testing. The test procedures will + provide insight as to how the TSFIs, modules, and subsystems + have been exercised by the developer during testing. The + evaluator uses this information when developing additional + tests to independently test the TSF. + + + + + + This family establishes that the TSF has been tested against + its functional specification. This is achieved through an + examination of developer evidence of correspondence. + + + + Coverage deals with the completeness of the functional tests + performed by the developer on the TOE. It addresses the + extent to which the TSF is tested. + + + + The components in this family are levelled on the basis of + specification. + + + + + + + + + + The objective of this component is to establish that some + of the TSFIs have been tested. + + + + In this component the developer shows how tests in the + test documentation correspond to TSFIs in the functional + specification. This can be achieved by a statement of + correspondence, perhaps using a table. + + + + The objective of this sub-activity is to determine whether + the developer has tested the TSFIs, and that the + developer's test coverage evidence shows correspondence + between the tests identified in the test documentation and + the TSFIs described in the functional + specification. + + + + The coverage analysis provided by the developer is + required to show the correspondence between the tests + provided as evaluation evidence and the functional + specification. However, the coverage analysis need not + demonstrate that all TSFI have been tested, or that all + externally-visible interfaces to the TOE have been + tested. Such shortcomings are considered by the evaluator + during the independent testing () sub-activity. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the functional specification; + + + the test documentation; + + + the test coverage evidence. + + + + + The developer shall provide evidence of the test coverage. + + + The evidence of the test coverage shall show the + correspondence between the tests in the test documentation + and the TSFIs in the functional specification. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the test coverage evidence + to determine that the correspondence between the tests + identified in the test documentation and the TSFIs + described in the functional specification is + accurate. + + Correspondence may take the form of a table or + matrix. The coverage evidence required for this + component will reveal the extent of coverage, rather + than to show complete coverage. In cases where coverage + is shown to be poor the evaluator should increase the + level of independent testing to compensate. + + + + + + + + + + The objective of this component is to confirm that all of + the TSFIs have been tested. + + + + In this component the developer confirms that tests in the + test documentation correspond to all of the TSFIs in the + functional specification. This can be achieved by a + statement of correspondence, perhaps using a table, but + the developer also provides an analysis of the test + coverage. + + + + The objective of this sub-activity is to determine whether + the developer has tested all of the TSFIs, and that the + developer's test coverage evidence shows correspondence + between the tests identified in the test documentation and + the TSFIs described in the functional + specification. + + + + + + the ST; + + + the functional specification; + + + the test documentation; + + + the test coverage analysis. + + + + + The developer shall provide an analysis of the test + coverage. + + + The analysis of the test coverage shall demonstrate the + correspondence between the tests in the test documentation + and the TSFIs in the functional specification. + + + The analysis of the test coverage shall demonstrate that all + TSFIs in the functional specification have been tested. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the test coverage analysis + to determine that the correspondence between the tests + in the test documentation and the interfaces in the + functional specification is accurate. + + A simple cross-table may be sufficient to show test + correspondence. The identification of the tests and the + interfaces presented in the test coverage analysis has + to be unambiguous. + + The evaluator is reminded that this does not imply that + all tests in the test documentation must map to + interfaces in the functional specification. + + + + + The evaluator shall examine the test plan to determine + that the testing approach for each interface + demonstrates the expected behaviour of that + interface. + + Guidance on this work unit can be found in: + + + + + + + + + + + + + The evaluator shall examine the test procedures to + determine that the test prerequisites, test steps and + expected result(s) adequately test each + interface. + + Guidance on this work units, as it pertains to the + functional specification, can be found in: + + + + + + + + + + The evaluator shall examine the test coverage analysis + to determine that the correspondence between the + interfaces in the functional specification and the tests + in the test documentation is complete. + + All TSFIs that are described in the functional + specification have to be present in the test coverage + analysis and mapped to tests in order for completeness + to be claimed, although exhaustive specification testing + of interfaces is not required. Incomplete coverage would + be evident if an interface was identified in the + functional specification and no test was mapped to + it. + + The evaluator is reminded that this does not imply that + all tests in the test documentation must map to + interfaces in the functional specification. + + + + + + + + + + In this component, the objective is to confirm that the + developer performed exhaustive tests of all interfaces in + the functional specification. + + The objective of this component is to confirm that all + parameters of all of the TSFIs have been tested. + + + + In this component the developer is required to show how + tests in the test documentation correspond to all of the + TSFIs in the functional specification. This can be + achieved by a statement of correspondence, perhaps using a + table, but in addition the developer is required to + demonstrate that the tests exercise all of the parameters + of all TSFIs. This additional requirement includes bounds + testing (i.e. verifying that errors are generated when + stated limits are exceeded) and negative testing + (e.g. when access is given to User A, verifying not only + that User A now has access, but also that User B did not + suddenly gain access). This kind of testing is not, + strictly speaking, exhaustive because not + every possible value of the parameters is expected to be + checked. + + + The developer shall provide an analysis of the test + coverage. + + + The analysis of the test coverage shall demonstrate the + correspondence between the tests in the test documentation + and the TSFIs in the functional specification. + + + The analysis of the test coverage shall demonstrate that all + TSFIs in the functional specification have been completely + tested. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + + + + The components in this family deal with the level of detail + to which the TSF is tested by the developer. Testing of the + TSF is based upon increasing depth of information derived + from additional design representations and descriptions (TOE + design, implementation representation, and security + architecture description). + + The objective is to counter the risk of missing an error in + the development of the TOE. Testing that exercises specific + internal interfaces can provide assurance not only that the + TSF exhibits the desired external security behaviour, but + also that this behaviour stems from correctly operating + internal functionality. + + + + Depth deals with the level of detail to which the developer + tests the TSF. Testing is based upon increasing depth of + information derived from analysis of the TSF + representations. + + + + The components in this family are levelled on the basis of + increasing detail provided in the TSF representations, from + the TOE design to the implementation representation. This + levelling reflects the TSF representations presented in the + class. + + + + The TOE design describes the internal components + (e.g. subsystems) and, perhaps, modules of the TSF, together + with a description of the interfaces among these components and + modules. Evidence of testing of this TOE design must show that + the internal interfaces have been exercised and seen to behave + as described. This may be achieved through testing via the + external interfaces of the TSF, or by testing of the TOE + subsystem or module interfaces in isolation, perhaps employing a + test harness. In cases where some aspects of an internal + interface cannot be tested via the external interfaces, there + should either be justification that these aspects need not be + tested, or the internal interface needs to be tested + directly. In the latter case the TOE design needs to be + sufficiently detailed in order to facilitate direct + testing. + + In cases where the description of the TSF's architectural + soundness (in ) cites + specific mechanisms, the tests performed by the developer + must show that the mechanisms have been exercised and seen + to behave as described. + + At the highest component of this family, the testing is + performed not only against the TOE design, but also against + the implementation representation. + + + + + + + + The subsystem descriptions of the TSF provide a high-level + description of the internal workings of the TSF. Testing + at the level of the TOE subsystems provides assurance that + the TSF subsystems behave and interact as described in the + TOE design and the security architecture + description. + + + + The objective of this sub-activity is to determine whether + the developer has tested the TSF subsystems against the + TOE design and the security architecture + description. + + + + + + the ST; + + + the functional specification; + + + the TOE design; + + + the security architecture description; + + + the test documentation; + + + the depth of testing analysis. + + + + + The developer shall provide the analysis of the depth of + testing. + + + The analysis of the depth of testing shall demonstrate the + correspondence between the tests in the test documentation + and the TSF subsystems in the TOE design. + + + The analysis of the depth of testing shall demonstrate that + all TSF subsystems in the TOE design have been tested. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the depth of testing + analysis to determine that the descriptions of the + behaviour of TSF subsystems and of their interactions is + included within the test documentation. + + This work unit verifies the content of the + correspondence between the tests and the descriptions in + the TOE design. In cases where the description of the + TSF's architectural soundness (in ) cites specific mechanisms, this work + unit also verifies the correspondence between the tests + and the descriptions of the behaviour of such + mechanisms. + + A simple cross-table may be sufficient to show test + correspondence. The identification of the tests and the + behaviour/interaction presented in the depth-of coverage + analysis has to be unambiguous. + + When is combined with a component of , which includes descriptions at the module level + (e.g. ), the level of detail needed to map + the test cases to the behaviour of the subsystems may require + information from the module description to be used. This is + because allows the description of details + to be shifted from the subsystem level to the module level, or + even to omit the subsystems altogether. + In any case, the required level of detail in the provided + reference to the tested behaviour can be defined as ``the level + of detail required for the description of subsystem behaviour as + defined by (in particular work unit )''. It states that a detailed description of + the behaviour typically discusses how the functionality is + provided, in terms of what key data and data structures re + present; what control relationships exist within a subsytem and + how these elements work together to provide the SFR-enforcing + behaviour. + The evaluator is reminded that not all tests in the test + documentation must map to a subsystem behaviour or + interaction description. + + + + + The evaluator shall examine the test plan, test + prerequisites, test steps and expected result(s) to + determine that the testing approach for the behaviour + description demonstrates the behaviour of that subsystem + as described in the TOE design. + + Guidance on this work unit can be found in: + + + + + + + + + + When is combined with a component of , which includes descriptions at the module level + (e.g. ), the level of detail needed to map + the test cases to the behaviour of the subsystems may require + information from the module description to be used. This is + because allows the description of details + to be shifted from the subsystem level to the module level, or + even to omit the subsystems altogether. + In any case, the required level of detail in the provided + reference to the tested behaviour can be defined as ``the level + of detail required for the description of subsystem behaviour as + defined by (in particular work unit )''. It states that a detailed description of + the behaviour typically discusses how the functionality is + provided, in terms of what key data and data structures re + present; what control relationships exist within a subsytem and + how these elements work together to provide the SFR-enforcing + behaviour. + If TSF subsystem interfaces are described, the behaviour + of those subsystems may be tested directly from those + interfaces. Otherwise, the behaviour of those subsystems + is tested from the TSFI interfaces. Or a combination of + the two may be employed. Whatever strategy is used the + evaluator will consider its appropriateness for + adequately testing the behaviour that is described in + the TOE design. + + + + + The evaluator shall examine the test plan, test + prerequisites, test steps and expected result(s) to + determine that the testing approach for the behaviour + description demonstrates the interactions among + subsystems as described in the TOE design. + + While the previous work unit addresses behaviour of subsystems, + this work unit addresses the interactions among + subsystems. + + Guidance on this work unit can be found in: + + + + + + + + + + If TSF subsystem interfaces are described, the + interactions with other subsystems may be tested + directly from those interfaces. Otherwise, the + interactions among subsystems must be inferred from the + TSFI interfaces. Whatever strategy is used the evaluator + will consider its appropriateness for adequately testing + the interactions among subsystems that are described in + the TOE design. + + + + + The evaluator shall examine the test procedures to + determine that all descriptions of TSF subsystem + behaviour and interaction are tested. + + This work unit verifies the completeness of work unit + . All descriptions + of TSF subsystem behaviour and of interactions among TSF + subsystems that are provided in the TOE design have to + be tested. Incomplete depth of testing would be evident + if a description of TSF subsystem behaviour or of + interactions among TSF subsystems was identified in the + TOE design and no tests could be attributed to + it. + + When is combined with a component of , which includes descriptions at the module level + (e.g. ), the level of detail needed to map + the test cases to the behaviour of the subsystems may require + information from the module description to be used. This is + because allows the description of details + to be shifted from the subsystem level to the module level, or + even to omit the subsystems altogether. + In any case, the required level of detail in the provided + reference to the tested behaviour can be defined as ``the level + of detail required for the description of subsystem behaviour as + defined by (in particular work unit )''. It states that a detailed description of + the behaviour typically discusses how the functionality is + provided, in terms of what key data and data structures re + present; what control relationships exist within a subsytem and + how these elements work together to provide the SFR-enforcing + behaviour. + The evaluator is reminded that this does not imply that all + tests in the test documentation must map to the subsystem behaviour + or interaction description in the TOE design. + + + + + + + + + + + The subsystem and module descriptions of the TSF provide a + high-level description of the internal workings, and a + description of the interfaces of the SFR-enforcing + modules, of the TSF. Testing at this level of TOE + description provides assurance that the TSF subsystems and + SFR-enforcing modules behave and interact as described in + the TOE design and the security architecture + description. + + + + The objective of this sub-activity is to determine whether the + developer has tested all the TSF subsystems and SFR-enforcing + modules against the TOE design and the security architecture + description. + + + + + + the ST; + + + the functional specification; + + + the TOE design; + + + the security architecture description; + + + the test documentation; + + + the depth of testing analysis. + + + + + The developer shall provide the analysis of the depth of + testing. + + + The analysis of the depth of testing shall demonstrate the + correspondence between the tests in the test documentation and + the TSF subsystems and SFR-enforcing modules in the TOE design. + + + The analysis of the depth of testing shall demonstrate that + all TSF subsystems in the TOE design have been tested. + + + The analysis of the depth of testing shall demonstrate that + the SFR-enforcing modules in the TOE design have been + tested. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the depth of testing + analysis to determine that descriptions of the behaviour + of TSF subsystems and of their interactions are included + within the test documentation. + + This work unit verifies the content of the + correspondence between the tests and the descriptions in + the TOE design. In cases where the description of the + TSF's architectural soundness (in ) cites specific mechanisms, this work + unit also verifies the correspondence between the tests + and the descriptions of the behaviour of such + mechanisms. + + A simple cross-table may be sufficient to show test + correspondence. The identification of the tests and the + behaviour/interaction presented in the depth-of coverage + analysis has to be unambiguous. + + The evaluator is reminded that not all tests in the test + documentation must map to a subsystem behaviour or + interaction description. + + + + + The evaluator shall examine the test plan, test + prerequisites, test steps and expected result(s) to + determine that the testing approach for the behaviour + description demonstrates the behaviour of that subsystem + as described in the TOE design. + + Guidance on this work unit can be found in: + + + + + + + + + + If TSF subsystem interfaces are described, the behaviour + of those subsystems may be tested directly from those + interfaces. Otherwise, the behaviour of those subsystems + is tested from the TSFI interfaces. Or a combination of + the two may be employed. Whatever strategy is used the + evaluator will consider its appropriateness for + adequately testing the behaviour that is described in + the TOE design. + + + + + The evaluator shall examine the test plan, test + prerequisites, test steps and expected result(s) to + determine that the testing approach for the behaviour + description demonstrates the interactions among + subsystems as described in the TOE design. + + While the previous work unit addresses behaviour of subsystems, + this work unit addresses the interactions among + subsystems. + + Guidance on this work unit can be found in: + + + + + + + + + + If TSF subsystem interfaces are described, the + interactions with other subsystems may be tested + directly from those interfaces. Otherwise, the + interactions among subsystems must be inferred from the + TSFI interfaces. Whatever strategy is used the evaluator + will consider its appropriateness for adequately testing + the interactions among subsystems that are described in + the TOE design. + + + + + The evaluator shall examine the depth of testing + analysis to determine that the interfaces of + SFR-enforcing modules are included within the test + documentation. + + This work unit verifies the content of the + correspondence between the tests and the descriptions in + the TOE design. In cases where the description of the + TSF's architectural soundness (in ) cites specific mechanisms at the modular + level, this work unit also verifies the correspondence + between the tests and the descriptions of the behaviour + of such mechanisms. + + A simple cross-table may be sufficient to show test + correspondence. The identification of the tests and the + SFR-enforcing modules presented in the depth-of coverage + analysis has to be unambiguous. + + The evaluator is reminded that not all tests in the test + documentation must map to the interfaces of SFR-enforcing modules. + + + + + The evaluator shall examine the test plan, test prerequisites, + test steps and expected result(s) to determine that the testing + approach for each SFR-enforcing module interface demonstrates + the expected behaviour of that interface. + + While work unit addresses + expected behaviour of subsystems, this work unit addresses + expected behaviour of the SFR-enforcing module interfaces that + are covered by . + + Guidance on this work unit can be found in: + + + + + + + + + Testing of an interface may be performed directly + at that interface, or at the external interfaces, or a + combination of both. Whatever strategy is used the + evaluator will consider its appropriateness for + adequately testing the interfaces. Specifically the + evaluator determines whether testing at the internal + interfaces is necessary or whether these internal + interfaces can be adequately tested (albeit implicitly) + by exercising the external interfaces. This + determination is left to the evaluator, as is its + justification. + + + + + The evaluator shall examine the test procedures to + determine that all descriptions of TSF subsystem + behaviour and interaction are tested. + + This work unit verifies the completeness of work unit + . All descriptions + of TSF subsystem behaviour and of interactions among TSF + subsystems that are provided in the TOE design have to + be tested. Incomplete depth of testing would be evident + if a description of TSF subsystem behaviour or of + interactions among TSF subsystems was identified in the + TOE design and no tests could be attributed to + it. + + The evaluator is reminded that this does not imply that all + tests in the test documentation must map to the subsystem behaviour + or interaction description in the TOE design. + + + + + The evaluator shall examine the test procedures to + determine that all interfaces of SFR-enforcing modules + are tested. + + This work unit verifies the completeness of work unit + . All interfaces + of SFR-enforcing modules that are provided in the TOE + design have to be tested. Incomplete depth of testing + would be evident if any interface of any SFR-enforcing + modules was identified in the TOE design and no tests + could be attributed to it. + The evaluator is reminded that this does not imply + that all tests in the test documentation must map to an + interface of an SFR-enforcing module in the TOE + design. + + + + + + + + + + + The subsystem and module descriptions of the TSF provide a + high-level description of the internal workings, and a + description of the interfaces of the modules, of the + TSF. Testing at this level of TOE description provides + assurance that the TSF subsystems and modules behave and + interact as described in the TOE design and the security + architecture description. + + + + The objective of this sub-activity is to determine whether the + developer has tested the all the TSF subsystems and modules + against the TOE design and the security architecture + description. + + + + + + the ST; + + + the functional specification; + + + the TOE design; + + + the security architecture description; + + + the test documentation; + + + the depth of testing analysis. + + + + + The developer shall provide the analysis of the depth of + testing. + + + The analysis of the depth of testing shall demonstrate the + correspondence between the tests in the test documentation + and the TSF subsystems and modules in the TOE design. + + + The analysis of the depth of testing shall demonstrate that + all TSF subsystems in the TOE design have been tested. + + + The analysis of the depth of testing shall demonstrate that all + TSF modules in the TOE design have been tested. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the depth of testing + analysis to determine that descriptions of the behaviour + of TSF subsystems and of their interactions are included + within the test documentation. + + This work unit verifies the content of the + correspondence between the tests and the descriptions in + the TOE design. A simple cross-table may be sufficient + to show test correspondence. The identification of the + tests and the behaviour/interaction presented in the + depth-of coverage analysis has to be unambiguous. + + The evaluator is reminded that not all tests in the test + documentation must map to a subsystem behaviour or + interaction description. + + + + + The evaluator shall examine the test plan, test + prerequisites, test steps and expected result(s) to + determine that the testing approach for the behaviour + description demonstrates the behaviour of that subsystem + as described in the TOE design. + + Guidance on this work unit can be found in: + + + + + + + + + + If TSF subsystem interfaces are provided, the behaviour + of those subsystems may be performed directly from those + interfaces. Otherwise, the behaviour of those subsystems + is tested from the TSFI interfaces. Or a combination of + the two may be employed. Whatever strategy is used the + evaluator will consider its appropriateness for + adequately testing the behaviour that is described in + the TOE design. + + + + + The evaluator shall examine the test plan, test + prerequisites, test steps and expected result(s) to + determine that the testing approach for the behaviour + description demonstrates the interactions among + subsystems as described in the TOE design. + + Guidance on this work unit can be found in: + + + + + + + + + While the previous work unit addresses behaviour of subsystems, + this work unit addresses the interactions among + subsystems. + + If TSF subsystem interfaces are provided, the + interactions with other subsystems may be performed + directly from those interfaces. Otherwise, the + interactions among subsystems must be inferred from the + TSFI interfaces. Whatever strategy is used the evaluator + will consider its appropriateness for adequately testing + the interactions among subsystems that are described in + the TOE design. + + + + + The evaluator shall examine the depth of testing + analysis to determine that the interfaces of TSF modules + are included within the test documentation. + + This work unit verifies the content of the + correspondence between the tests and the descriptions in + the TOE design. A simple cross-table may be sufficient + to show test correspondence. The identification of the + tests and the behaviour/interaction presented in the + depth-of coverage analysis has to be unambiguous. + + The evaluator is reminded that not all tests in the test + documentation must map to a subsystem behaviour or + interaction description. + + + + + The evaluator shall examine the test plan, test + prerequisites, test steps and expected result(s) to + determine that the testing approach for each TSF module + interface demonstrates the expected behaviour of that + interface. + + Guidance on this work unit can be found in: + + + + + + + + + Testing of an interface may be performed directly + at that interface, or at the external interfaces, or a + combination of both. Whatever strategy is used the + evaluator will consider its appropriateness for + adequately testing the interfaces. Specifically the + evaluator determines whether testing at the internal + interfaces is necessary or whether these internal + interfaces can be adequately tested (albeit implicitly) + by exercising the external interfaces. This + determination is left to the evaluator, as is its + justification. + + + + + The evaluator shall examine the test procedures to + determine that all descriptions of TSF subsystem + behaviour and interaction are tested. + + This work unit verifies the completeness of work unit + . All descriptions + of TSF subsystem behaviour and of interactions among TSF + subsystems that are provided in the TOE design have to + be tested. Incomplete depth of testing would be evident + if a description of TSF subsystem behaviour or of + interactions among TSF subsystems was identified in the + TOE design and no tests could be attributed to + it. + + The evaluator is reminded that this does not imply that all + tests in the test documentation must map to the subsystem behaviour + or interaction description in the TOE design. + + + + + The evaluator shall examine the test procedures to determine + that all interfaces of all TSF modules are tested. + + This work unit verifies the completeness of work unit + . All interfaces + of TSF modules that are provided in the TOE design have + to be tested. Incomplete depth of testing would be + evident if any interface of any TSF module was + identified in the TOE design and no tests could be + attributed to it. + The evaluator is reminded that this does not imply + that all tests in the test documentation must map to an + interface of a TSF module in the TOE design. + + + + + + + + + + + + The subsystem and module descriptions of the TSF provide a + high-level description of the internal workings, and a + description of the interfaces of the modules, of the + TSF. Testing at this level of TOE description provides + assurance that the TSF subsystems and modules behave and + interact as described in the TOE design and the security + architecture description, and in accordance with the + implementation representation. + + + The developer shall provide the analysis of the depth of + testing. + + + The analysis of the depth of testing shall demonstrate the + correspondence between the tests in the test documentation + and the TSF subsystems and modules in the TOE design. + + + The analysis of the depth of testing shall demonstrate that + all TSF subsystems in the TOE design have been tested. + + + The analysis of the depth of testing shall demonstrate that + all modules in the TOE design have been tested. + + + The analysis of the depth of testing shall demonstrate that + the TSF operates in accordance with its implementation + representation. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + + + + Functional testing performed by the developer provides + assurance that the tests in the test documentation are + performed and documented correctly. The correspondence of + these tests to the design descriptions of the TSF is + achieved through the and + families. + + This family contributes to providing assurance that the + likelihood of undiscovered flaws is relatively small. + + The families , and are used in combination to define the evidence + of testing to be supplied by a developer. Independent + functional testing by the evaluator is specified by . + + + + Functional testing establishes that the tests performed by + the developer are performed and documented correctly. + + + + This family contains two components, the higher requiring + that ordering dependencies are analysed. + + + + Procedures for performing tests are expected to provide + instructions for using test programs and test suites, + including the test environment, test conditions, test data + parameters and values. The test procedures should also show + how the test results are derived from the test + inputs. + + Ordering dependencies are relevant when the successful + execution of a particular test depends upon the existence of + a particular state. For example, this might require that + test A be executed immediately before test B, since the + state resulting from the successful execution of test A is a + prerequisite for the successful execution of test B. Thus, + failure of test B could be related to a problem with the + ordering dependencies. In the above example, test B could + fail because test C (rather than test A) was executed + immediately before it, or the failure of test B could be + related to a failure of test A. + + + + + + The objective is for the developer to demonstrate that the + tests in the test documentation are performed and + documented correctly. + + + + The objective of this sub-activity is to determine whether + the developer correctly performed and documented the tests + in the test documentation. + + + + The extent to which the test documentation is required to + cover the TSF is dependent upon the coverage assurance + component. + + For the developer tests provided, the evaluator determines + whether the tests are repeatable, and the extent to which + the developer's tests can be used for the evaluator's + independent testing effort. Any TSFI for which the + developer's test results indicate that it might not + perform as specified should be tested independently by the + evaluator to determine whether or not it does. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the functional specification; + + + the test documentation. + + + + + The developer shall test the TSF and document the results. + + + The developer shall provide test documentation. + + + The test documentation shall consist of test plans, expected + test results and actual test results. + + + The test plans shall identify the tests to be performed and + describe the scenarios for performing each test. These + scenarios shall include any ordering dependencies on the + results of other tests. + + + The expected test results shall show the anticipated outputs + from a successful execution of the tests. + + + The actual test results shall be consistent with the + expected test results. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall check that the test documentation + includes test plans, expected test results and actual + test results. + + The evaluator checks that test plans, expected tests + results and actual test results are included in the test + documentation. + + + + + The evaluator shall examine the test plan to determine + that it describes the scenarios for performing each + test. + + The evaluator determines that the test plan provides + information about the test configuration being used: + both on the configuration of the TOE and on any test + equipment being used. This information should be + detailed enough to ensure that the test configuration is + reproducible. + + The evaluator also determines that the test plan + provides information about how to execute the test: any + necessary automated set-up procedures (and whether they + require privilege to run), inputs to be applied, how + these inputs are applied, how output is obtained, any + automated clean-up procedures (and whether they require + privilege to run), etc. This information should be + detailed enough to ensure that the test is + reproducible. + + The evaluator may wish to employ a sampling strategy + when performing this work unit. + + + + + The evaluator shall examine the test plan to determine + that the TOE test configuration is consistent with the + ST. + + The TOE referred to in the developer's test plan should + have the same unique reference as established by the + sub-activities and + identified in the ST introduction. + + It is possible for the ST to specify more than one + configuration for evaluation. The evaluator verifies + that all test configurations identified in the developer + test documentation are consistent with the ST. For + example, the ST might define configuration options that + must be set, which could have an impact upon what + constitutes the TOE by including or excluding additional + portions. The evaluator verifies that all such + variations of the TOE are considered. + + The evaluator should consider the security objectives + for the operational environment described in the ST that + may apply to the test environment. There may be some + objectives for the operational environment that do not + apply to the test environment. For example, an objective + about user clearances may not apply; however, an + objective about a single point of connection to a + network would apply. + + The evaluator may wish to employ a sampling strategy + when performing this work unit. + + If this work unit is applied to a component TOE that + might be used/integrated in a composed TOE (see ), the following will apply. In + the instances that the component TOE under evaluation + depends on other components in the operational + environment to support their operation, the developer + may wish to consider using the other component(s) that + will be used in the composed TOE to fulfil the + requirements of the operational environment as one of + the test configurations. This will reduce the amount an + additional testing that will be required for the + composed TOE evaluation. + + + + + The evaluator shall examine the test plans to determine + that sufficient instructions are provided for any + ordering dependencies. + + Some steps may have to be performed to establish initial + conditions. For example, user accounts need to be added + before they can be deleted. An example of ordering + dependencies on the results of other tests is the need + to perform actions in a test that will result in the + generation of audit records, before performing a test to + consider the searching and sorting of those audit + records. Another example of an ordering dependency + would be where one test case generates a file of data to + be used as input for another test case. + + The evaluator may wish to employ a sampling strategy + when performing this work unit. + + + + + The evaluator shall examine the test documentation to + determine that all expected tests results are + included. + + The expected test results are needed to determine + whether or not a test has been successfully + performed. Expected test results are sufficient if they + are unambiguous and consistent with expected behaviour + given the testing approach. + + The evaluator may wish to employ a sampling strategy + when performing this work unit. + + + + + The evaluator shall check that the actual test results + in the test documentation are consistent with the + expected test results in the test documentation. + + A comparison of the actual and expected test results + provided by the developer will reveal any + inconsistencies between the results. It may be that a + direct comparison of actual results cannot be made until + some data reduction or synthesis has been first + performed. In such cases, the developer's test + documentation should describe the process to reduce or + synthesise the actual data. + + For example, the developer may need to test the contents + of a message buffer after a network connection has + occurred to determine the contents of the buffer. The + message buffer will contain a binary number. This binary + number would have to be converted to another form of + data representation in order to make the test more + meaningful. The conversion of this binary representation + of data into a higher-level representation will have to + be described by the developer in enough detail to allow + an evaluator to perform the conversion process + (i.e. synchronous or asynchronous transmission, number + of stop bits, parity, etc.). + + It should be noted that the description of the process + used to reduce or synthesise the actual data is used by + the evaluator not to actually perform the necessary + modification but to assess whether this process is + correct. It is up to the developer to transform the + expected test results into a format that allows an easy + comparison with the actual test results. + + The evaluator may wish to employ a sampling strategy + when performing this work unit. + + + + + The evaluator shall report the developer testing effort, + outlining the testing approach, configuration, depth and + results. + + The developer testing information recorded in the ETR allows the + evaluator to convey the overall testing approach and effort + expended on the testing of the TOE by the developer. The intent + of providing this information is to give a meaningful overview + of the developer testing effort. It is not intended that the + information regarding developer testing in the ETR be an exact + reproduction of specific test steps or results of individual + tests. The intention is to provide enough detail to allow other + evaluators and evaluation authorities to gain some insight about the + developer's testing approach, amount of testing performed, TOE + test configurations, and the overall results of the developer + testing. + + Information that would typically be found in the ETR + subclause regarding the developer testing effort is: + + + TOE test configurations. The particular + configurations of the TOE that were tested, + including whether any privileged code was required + to set up the test or clean up afterwards; + + + testing approach. An account of the overall + developer testing strategy employed; + + + testing results. A description of the overall + developer testing results. + + + + This list is by no means exhaustive and is only intended + to provide some context as to the type of information + that should be present in the ETR concerning the + developer testing effort. + + + + + + + + + The objectives are for the developer to demonstrate that + the tests in the test documentation are performed and + documented correctly, and to ensure that testing is + structured such as to avoid circular arguments about the + correctness of the interfaces being tested. + + + + Although the test procedures may state pre-requisite + initial test conditions in terms of ordering of tests, + they may not provide a rationale for the ordering. An + analysis of test ordering is an important factor in + determining the adequacy of testing, as there is a + possibility of faults being concealed by the ordering of + tests. + + + The developer shall test the TSF and document the results. + + + The developer shall provide test documentation. + + + The test documentation shall consist of test plans, expected + test results and actual test results. + + + The test plans shall identify the tests to be performed and + describe the scenarios for performing each test. These + scenarios shall include any ordering dependencies on the + results of other tests. + + + The expected test results shall show the anticipated outputs + from a successful execution of the tests. + + + The actual test results shall be consistent with the + expected test results. + + + The test documentation shall include an analysis of the test + procedure ordering dependencies. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + + + + The objectives of this family are built upon the assurances + achieved in the , , and + families by verifying the developer testing and performing + additional tests by the evaluator. + + + + Independent testing specifies the degree to which the + testing of the TSF must be performed by a party other than + the developer (e.g. a third party). This family adds value + by the introduction of tests that are not part of the + developer's tests. + + + + Levelling is based upon the amount of developer test + documentation and test support and the amount of evaluator + testing. + + + + This family deals with the degree to which there is + independent functional testing of the TSF. Independent + functional testing may take the form of repeating the + developer's functional tests (in whole or in part) or of + extending the scope or the depth of the developer's + tests. These activities are complementary, and an + appropriate mix must be planned for each TOE, which takes + into account the availability and coverage of test results, + and the functional complexity of the TSF. + + Sampling of developer tests is intended to provide + confirmation that the developer has carried out his planned + test programme on the TSF, and has correctly recorded the + results. The size of sample selected will be influenced by + the detail and quality of the developer's functional test + results. The evaluator will also need to consider the scope + for devising additional tests, and the relative benefit that + may be gained from effort in these two areas. It is + recognised that repetition of all developer tests may be + feasible and desirable in some cases, but may be very + arduous and less productive in others. The highest component + in this family should therefore be used with + caution. Sampling will address the whole range of test + results available, including those supplied to meet the + requirements of both and + . + + There is also a need to consider the different + configurations of the TOE that are included within the + evaluation. The evaluator will need to assess the + applicability of the results provided, and to plan his own + testing accordingly. + + The suitability of the TOE for testing is based on the + access to the TOE, and the supporting documentation and + information required (including any test software or tools) + to run tests. The need for such support is addressed by the + dependencies to other assurance families. + + Additionally, suitability of the TOE for testing may be + based on other considerations. For example, the version of + the TOE submitted by the developer may not be the final + version. + + The term interfaces refers to interfaces + described in the functional specification and TOE design, + and parameters passed through invocations identified in the + implementation representation. The exact set of interfaces + to be used is selected through and the + components. + + References to a subset of the interfaces are intended to + allow the evaluator to design an appropriate set of tests + which is consistent with the objectives of the evaluation + being conducted. + + + + + + + + In this component, the objective is to demonstrate that + the TOE operates in accordance with its design + representations and guidance documents. + + + + This component does not address the use of developer test + results. It is applicable where such results are not + available, and also in cases where the developer's testing + is accepted without validation. The evaluator is required + to devise and conduct tests with the objective of + confirming that the TOE operates in accordance with its + design representations, including but not limited to the + functional specification. The approach is to gain + confidence in correct operation through representative + testing, rather than to conduct every possible test. The + extent of testing to be planned for this purpose is a + methodology issue, and needs to be considered in the + context of a particular TOE and the balance of other + evaluation activities. + + + + The goal of this activity is to determine, by + independently testing a subset of the TSFI, whether the + TOE behaves as specified in the functional specification + and guidance documentation. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the functional specification; + + + the operational user guidance; + + + the preparative user guidance; + + + the TOE suitable for testing. + + + + + The developer shall provide the TOE for testing. + + + The TOE shall be suitable for testing. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the TOE to determine that + the test configuration is consistent with the + configuration under evaluation as specified in the + ST. + + The TOE provided by the developer should have the same + unique reference as established by the sub-activities and identified + in the ST introduction. + + It is possible for the ST to specify more than one + configuration for evaluation. The TOE may comprise a + number of distinct hardware and software entities that + need to be tested in accordance with the ST. The + evaluator verifies that all test configurations are + consistent with the ST. + + The evaluator should consider the security objectives + for the operational environment described in the ST that + may apply to the test environment and ensure they are + met in the testing environment. There may be some + objectives for the operational environment that do not + apply to the test environment. For example, an objective + about user clearances may not apply; however, an + objective about a single point of connection to a + network would apply. + + If any test resources are used (e.g. meters, analysers) + it will be the evaluator's responsibility to ensure that + these resources are calibrated correctly. + + + + + The evaluator shall examine the TOE to determine that it + has been installed properly and is in a known + state. + + It is possible for the evaluator to determine the state + of the TOE in a number of ways. For example, previous + successful completion of the sub-activity will satisfy this work unit + if the evaluator still has confidence that the TOE being + used for testing was installed properly and is in a + known state. If this is not the case, then the evaluator + should follow the developer's procedures to install and + start up the TOE, using the supplied guidance + only. + + If the evaluator has to perform the installation + procedures because the TOE is in an unknown state, this + work unit when successfully completed could satisfy work + unit . + + + + The evaluator shall test a subset of the TSF to confirm that + the TSF operates as specified. + + + The evaluator shall devise a test subset. + + The evaluator selects a test subset and testing strategy + that is appropriate for the TOE. One extreme testing + strategy would be to have the test subset contain as + many interfaces as possible tested with little + rigour. Another testing strategy would be to have the + test subset contain a few interfaces based on their + perceived relevance and rigorously test these + interfaces. + + Typically the testing approach taken by the evaluator + should fall somewhere between these two extremes. The + evaluator should exercise most of the interfaces using + at least one test, but testing need not demonstrate + exhaustive specification testing. + + The evaluator, when selecting the subset of the + interfaces to be tested, should consider the following + factors: + + + The number of interfaces from which to draw upon for + the test subset. Where the TSF includes only a small + number of relatively simple interfaces, it may be + practical to rigorously test all of the + interfaces. In other cases this may not be + cost-effective, and sampling is required. + + + Maintaining a balance of evaluation activities. The + evaluator effort expended on the test activity + should be commensurate with that expended on any + other evaluation activity. + + + + The evaluator selects the interfaces to compose the + subset. This selection will depend on a number of + factors, and consideration of these factors may also + influence the choice of test subset size: + + + Significance of interfaces. Those interfaces more + significant than others should be included in the + test subset. One major factor of ``significance'' is + the security-relevance (SFR-enforcing interfaces + would be more significant than SFR-supporting + interfaces, which are more significant than + SFR-non-interfering interfaces; see CC Part 3 + Subclause ). The other + major factor of ``significance'' is the number of + SFRs mapping to this interface (as determined when + identifying the correspondence between levels of + abstraction in ). + + + Complexity of the interface. Complex interfaces may + require complex tests that impose onerous + requirements on the developer or evaluator, which + may not be conducive to cost-effective + evaluations. Conversely, they are a likely area to + find errors and are good candidates for the + subset. The evaluator will need to strike a balance + between these considerations. + + + Implicit testing. Testing some interfaces may often + implicitly test other interfaces, and their + inclusion in the subset may maximise the number of + interfaces tested (albeit implicitly). Certain + interfaces will typically be used to provide a + variety of security functionality, and will tend to + be the target of an effective testing approach. + + + Types of interfaces (e.g. programmatic, + command-line, protocol). The evaluator should + consider including tests for all different types of + interfaces that the TOE supports. + + + Interfaces that give rise to features that are + innovative or unusual. Where the TOE contains + innovative or unusual features, which may feature + strongly in marketing literature and guidance + documents, the corresponding interfaces should be + strong candidates for testing. + + + + This guidance articulates factors to consider during the + selection process of an appropriate test subset, but + these are by no means exhaustive. + + + The evaluator shall produce test documentation for the + test subset that is sufficiently detailed to enable the + tests to be reproducible. + + With an understanding of the expected behaviour of the + TSF, from the ST and the functional specification, the + evaluator has to determine the most feasible way to test + the interface. Specifically the evaluator considers: + + + the approach that will be used, for instance, + whether an external interface will be tested, or an + internal interface using a test harness, or will an + alternate test approach be employed (e.g. in + exceptional circumstances, a code inspection, if the + implementation representation is available); + + + the interface(s) that will be used to test and + observe responses; + + + the initial conditions that will need to exist for + the test (i.e. any particular objects or subjects + that will need to exist and security attributes they + will need to have); + + + special test equipment that will be required to + either stimulate an interface (e.g. packet + generators) or make observations of an interface + (e.g. network analysers). + + + + The evaluator may find it practical to test each + interface using a series of test cases, where each test + case will test a very specific aspect of expected + behaviour. + + The evaluator's test documentation should specify the + derivation of each test, tracing it back to the relevant + interface(s). + + + The evaluator shall conduct testing. + + The evaluator uses the test documentation developed as a + basis for executing tests on the TOE. The test + documentation is used as a basis for testing but this + does not preclude the evaluator from performing + additional ad hoc tests. The evaluator may devise new + tests based on behaviour of the TOE discovered during + testing. These new tests are recorded in the test + documentation. + + + The evaluator shall record the following information + about the tests that compose the test subset: + + + identification of the interface behaviour to be + tested; + + + instructions to connect and setup all required test + equipment as required to conduct the test; + + + instructions to establish all prerequisite test + conditions; + + + instructions to stimulate the interface; + + + instructions for observing the behaviour of the + interface; + + + descriptions of all expected results and the + necessary analysis to be performed on the observed + behaviour for comparison against expected results; + + + instructions to conclude the test and establish the + necessary post-test state for the TOE; + + + actual test results. + + + + The level of detail should be such that another + evaluator could repeat the tests and obtain an + equivalent result. While some specific details of the + test results may be different (e.g. time and date fields + in an audit record) the overall result should be + identical. + + There may be instances when it is unnecessary to provide + all the information presented in this work unit + (e.g. the actual test results of a test may not require + any analysis before a comparison between the expected + results can be made). The determination to omit this + information is left to the evaluator, as is the + justification. + + + The evaluator shall check that all actual test results + are consistent with the expected test results. + + Any differences in the actual and expected test results + may indicate that the TOE does not perform as specified + or that the evaluator test documentation may be + incorrect. Unexpected actual results may require + corrective maintenance to the TOE or test documentation + and perhaps require re-running of impacted tests and + modifying the test sample size and composition. This + determination is left to the evaluator, as is its + justification. + + + The evaluator shall report in the ETR the evaluator + testing effort, outlining the testing approach, + configuration, depth and results. + + The evaluator testing information reported in the ETR allows the + evaluator to convey the overall testing approach and effort + expended on the testing activity during the evaluation. The + intent of providing this information is to give a meaningful + overview of the testing effort. It is not intended that the + information regarding testing in the ETR be an exact + reproduction of specific test instructions or results of + individual tests. The intention is to provide enough detail to + allow other evaluators and evaluation authorities to gain some insight about + the testing approach chosen, amount of testing performed, TOE + test configurations, and the overall results of the testing + activity. + + Information that would typically be found in the ETR + subclause regarding the evaluator testing effort is: + + + TOE test configurations. The particular + configurations of the TOE that were tested; + + + subset size chosen. The amount of interfaces that + were tested during the evaluation and a + justification for the size; + + + selection criteria for the interfaces that compose + the subset. Brief statements about the factors + considered when selecting interfaces for inclusion + in the subset; + + + interfaces tested. A brief listing of the interfaces + that merited inclusion in the subset; + + + verdict for the activity. The overall judgement on + the results of testing during the evaluation. + + + + This list is by no means exhaustive and is only intended + to provide some context as to the type of information + that should be present in the ETR concerning the testing + the evaluator performed during the evaluation. + + + + + + + + + + + + In this component, the objective is to demonstrate that + the TOE operates in accordance with its design + representations and guidance documents. Evaluator testing + confirms that the developer performed some tests of some + interfaces in the functional specification. + + + + The intent is that the developer should provide the + evaluator with materials necessary for the efficient + reproduction of developer tests. This may include such + things as machine-readable test documentation, test + programs, etc. + + This component contains a requirement that the evaluator + has available test results from the developer to + supplement the programme of testing. The evaluator will + repeat a sample of the developer's tests to gain + confidence in the results obtained. Having established + such confidence the evaluator will build upon the + developer's testing by conducting additional tests that + exercise the TOE in a different manner. By using a + platform of validated developer test results the evaluator + is able to gain confidence that the TOE operates correctly + in a wider range of conditions than would be possible + purely using the developer's own efforts, given a fixed + level of resource. Having gained confidence that the + developer has tested the TOE, the evaluator will also have + more freedom, where appropriate, to concentrate testing in + areas where examination of documentation or specialist + knowledge has raised particular concerns. + + + + The goal of this activity is to determine, by + independently testing a subset of the TSF, whether the TOE + behaves as specified in the design documentation, and to + gain confidence in the developer's test results by + performing a sample of the developer's tests. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the functional specification; + + + the TOE design description; + + + the operational user guidance; + + + the preparative user guidance; + + + the configuration management documentation; + + + the test documentation; + + + the TOE suitable for testing. + + + + + The developer shall provide the TOE for testing. + + + The TOE shall be suitable for testing. + + + The developer shall provide an equivalent set of resources + to those that were used in the developer's functional + testing of the TSF. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the TOE to determine that + the test configuration is consistent with the + configuration under evaluation as specified in the + ST. + + The TOE provided by the developer and identified in the + test plan should have the same unique reference as + established by the + sub-activities and identified in the ST + introduction. + + It is possible for the ST to specify more than one + configuration for evaluation. The TOE may comprise a + number of distinct hardware and software entities that + need to be tested in accordance with the ST. The + evaluator verifies that all test configurations are + consistent with the ST. + + The evaluator should consider the security objectives + for the operational environment described in the ST that + may apply to the test environment and ensure they are + met in the testing environment. There may be some + objectives for the operational environment that do not + apply to the test environment. For example, an objective + about user clearances may not apply; however, an + objective about a single point of connection to a + network would apply. + + If any test resources are used (e.g. meters, analysers) + it will be the evaluator's responsibility to ensure that + these resources are calibrated correctly. + + + + + The evaluator shall examine the TOE to determine that it has been installed properly and is in a known state. + + It is possible for the evaluator to determine the state + of the TOE in a number of ways. For example, previous + successful completion of the sub-activity will satisfy this work unit + if the evaluator still has confidence that the TOE being + used for testing was installed properly and is in a + known state. If this is not the case, then the evaluator + should follow the developer's procedures to install and + start up the TOE, using the supplied guidance + only. + + If the evaluator has to perform the installation + procedures because the TOE is in an unknown state, this + work unit when successfully completed could satisfy work + unit . + + + + + The evaluator shall examine the set of resources provided by the developer + to determine that they are equivalent to the set of resources used by the + developer to functionally test the TSF. + + The set of resource used by the developer is documented + in the developer test plan, as considered in the family. The resource set may + include laboratory access and special test equipment, + among others. Resources that are not identical to those + used by the developer need to be equivalent in terms of + any impact they may have on test results. + + + + The evaluator shall execute a sample of tests in the test + documentation to verify the developer test results. + + + The evaluator shall conduct testing using a sample of + tests found in the developer test plan and + procedures. + + The overall aim of this work unit is to perform a + sufficient number of the developer tests to confirm the + validity of the developer's test results. The evaluator + has to decide on the size of the sample, and the + developer tests that will compose the sample (see ). + + All the developer tests can be traced back to specific + interfaces. Therefore, the factors to consider in the + selection of the tests to compose the sample are similar + to those listed for subset selection in work-unit . Additionally, the + evaluator may wish to employ a random sampling method to + select developer tests to include in the sample. + + + + The evaluator shall check that all the actual test + results are consistent with the expected test + results. + + Inconsistencies between the developer's expected test + results and actual test results will compel the + evaluator to resolve the discrepancies. Inconsistencies + encountered by the evaluator could be resolved by a + valid explanation and resolution of the inconsistencies + by the developer. + + If a satisfactory explanation or resolution can not be reached, + the evaluator's confidence in the developer's test results may be + lessened and it may be necessary for the evaluator to increase + the sample size to the extent that the subset identified in work unit + is adequately tested: + deficiencies with the developer's tests need to result in either + corrective action to the TOE by the developer (e.g., if the inconsistency + is caused by incorrect behaviour) or to the developer's tests (e.g., if the + inconsistency is caused by an incorrect test), or in the production of new + tests by the evaluator. + + + + The evaluator shall test a subset of the TSF to confirm that the + TSF operates as specified. + + + The evaluator shall devise a test subset. + + The evaluator selects a test subset and testing strategy + that is appropriate for the TOE. One extreme testing + strategy would be to have the test subset contain as + many interfaces as possible tested with little + rigour. Another testing strategy would be to have the + test subset contain a few interfaces based on their + perceived relevance and rigorously test these + interfaces. + + Typically the testing approach taken by the evaluator + should fall somewhere between these two extremes. The + evaluator should exercise most of the interfaces using + at least one test, but testing need not demonstrate + exhaustive specification testing. + + The evaluator, when selecting the subset of the + interfaces to be tested, should consider the following + factors: + + + The developer test evidence. The developer test + evidence consists of: the test documentation, the + available test coverage analysis, and the available + depth of testing analysis. The developer test + evidence will provide insight as to how the TSF has + been exercised by the developer during testing. The + evaluator applies this information when developing + new tests to independently test the + TOE. Specifically the evaluator should consider: + + + augmentation of developer testing for + interfaces. The evaluator may wish to perform + more of the same type of tests by varying + parameters to more rigorously test the + interface. + + + supplementation of developer testing strategy + for interfaces. The evaluator may wish to vary + the testing approach of a specific interface by + testing it using another test strategy. + + + + + The number of interfaces from which to draw upon for + the test subset. Where the TSF includes only a small + number of relatively simple interfaces, it may be + practical to rigorously test all of them. In other + cases this may not be cost-effective, and sampling + is required. + + + Maintaining a balance of evaluation activities. The + evaluator effort expended on the test activity + should be commensurate with that expended on any + other evaluation activity. + + + + The evaluator selects the interfaces to compose the + subset. This selection will depend on a number of + factors, and consideration of these factors may also + influence the choice of test subset size: + + + Rigour of developer testing of the interfaces. Those + interfaces that the evaluator determines require + additional testing should be included in the test + subset. + + + Developer test results. If the results of developer + tests cause the evaluator to doubt that an interface + is not properly implemented, then the evaluator + should include such interfaces in the test subset. + + + Significance of interfaces. Those interfaces more + significant than others should be included in the + test subset. One major factor of ``significance'' is + the security-relevance (SFR-enforcing interfaces + would be more significant than SFR-supporting + interfaces, which are more significant than + SFR-non-interfering interfaces; see CC Part 3 + Subclause ). The other + major factor of ``significance'' is the number of + SFRs mapping to this interface (as determined when + identifying the correspondence between levels of + abstraction in ). + + + Complexity of interfaces. Interfaces that require + complex implementation may require complex tests + that impose onerous requirements on the developer or + evaluator, which may not be conducive to + cost-effective evaluations. Conversely, they are a + likely area to find errors and are good candidates + for the subset. The evaluator will need to strike a + balance between these considerations. + + + Implicit testing. Testing some interfaces may often + implicitly test other interfaces, and their + inclusion in the subset may maximise the number of + interfaces tested (albeit implicitly). Certain + interfaces will typically be used to provide a + variety of security functionality, and will tend to + be the target of an effective testing approach. + + + Types of interfaces (e.g. programmatic, + command-line, protocol). The evaluator should + consider including tests for all different types of + interfaces that the TOE supports. + + + Interfaces that give rise to features that are + innovative or unusual. Where the TOE contains + innovative or unusual features, which may feature + strongly in marketing literature and guidance + documents, the corresponding interfaces should be + strong candidates for testing. + + + + This guidance articulates factors to consider during the + selection process of an appropriate test subset, but + these are by no means exhaustive. + + + The evaluator shall produce test documentation for the + test subset that is sufficiently detailed to enable the + tests to be reproducible. + + With an understanding of the expected behaviour of the + TSF, from the ST, the functional specification, and the + TOE design description, the evaluator has to determine + the most feasible way to test the + interface. Specifically the evaluator considers: + + + the approach that will be used, for instance, + whether an external interface will be tested, or an + internal interface using a test harness, or will an + alternate test approach be employed (e.g. in + exceptional circumstances, a code inspection); + + + the interface(s) that will be used to test and + observe responses; + + + the initial conditions that will need to exist for + the test (i.e. any particular objects or subjects + that will need to exist and security attributes they + will need to have); + + + special test equipment that will be required to + either stimulate an interface (e.g. packet + generators) or make observations of an interface + (e.g. network analysers). + + + + The evaluator may find it practical to test each + interface using a series of test cases, where each test + case will test a very specific aspect of expected + behaviour of that interface. + + The evaluator's test documentation should specify the + derivation of each test, tracing it back to the relevant + interface(s). + + + The evaluator shall conduct testing. + + The evaluator uses the test documentation developed as a + basis for executing tests on the TOE. The test + documentation is used as a basis for testing but this + does not preclude the evaluator from performing + additional ad hoc tests. The evaluator may devise new + tests based on behaviour of the TOE discovered during + testing. These new tests are recorded in the test + documentation. + + + The evaluator shall record the following information + about the tests that compose the test subset: + + + identification of the interface behaviour to be + tested; + + + instructions to connect and setup all required test + equipment as required to conduct the test; + + + instructions to establish all prerequisite test + conditions; + + + instructions to stimulate the interface; + + + instructions for observing the interface; + + + descriptions of all expected results and the + necessary analysis to be performed on the observed + behaviour for comparison against expected results; + + + instructions to conclude the test and establish the + necessary post-test state for the TOE; + + + actual test results. + + + + The level of detail should be such that another + evaluator could repeat the tests and obtain an + equivalent result. While some specific details of the + test results may be different (e.g. time and date fields + in an audit record) the overall result should be + identical. + + There may be instances when it is unnecessary to provide + all the information presented in this work unit + (e.g. the actual test results of a test may not require + any analysis before a comparison between the expected + results can be made). The determination to omit this + information is left to the evaluator, as is the + justification. + + + The evaluator shall check that all actual test results + are consistent with the expected test results. + + Any differences in the actual and expected test results + may indicate that the TOE does not perform as specified + or that the evaluator test documentation may be + incorrect. Unexpected actual results may require + corrective maintenance to the TOE or test documentation + and perhaps require re-running of impacted tests and + modifying the test sample size and composition. This + determination is left to the evaluator, as is its + justification. + + + The evaluator shall report in the ETR the evaluator + testing effort, outlining the testing approach, + configuration, depth and results. + + The evaluator testing information reported in the ETR allows the + evaluator to convey the overall testing approach and effort + expended on the testing activity during the evaluation. The + intent of providing this information is to give a meaningful + overview of the testing effort. It is not intended that the + information regarding testing in the ETR be an exact + reproduction of specific test instructions or results of + individual tests. The intention is to provide enough detail to + allow other evaluators and evaluation authorities to gain some insight about + the testing approach chosen, amount of evaluator testing + performed, amount of developer tests performed, TOE test + configurations, and the overall results of the testing + activity. + + Information that would typically be found in the ETR + subclause regarding the evaluator testing effort is: + + + TOE test configurations. The particular + configurations of the TOE that were tested. + + + subset size chosen. The amount of interfaces that + were tested during the evaluation and a + justification for the size. + + + selection criteria for the interfaces that compose + the subset. Brief statements about the factors + considered when selecting interfaces for inclusion + in the subset. + + + Interfaces tested. A brief listing of the interfaces + that merited inclusion in the subset. + + + developer tests performed. The amount of developer + tests performed and a brief description of the + criteria used to select the tests. + + + verdict for the activity. The overall judgement on + the results of testing during the evaluation. + + + + This list is by no means exhaustive and is only intended + to provide some context as to the type of information + that should be present in the ETR concerning the testing + the evaluator performed during the evaluation. + + + + + + + + + + + In this component, the objective is to demonstrate + that the TOE operates in accordance with its design + representations and guidance documents. Evaluator testing + includes repeating all of the developer tests. + + + + The intent is that the developer should provide the + evaluator with materials necessary for the efficient + reproduction of developer tests. This may include such + things as machine-readable test documentation, test + programs, etc. + + In this component the evaluator must repeat all of the + developer's tests as part of the programme of testing. As + in the previous component the evaluator will also conduct + tests that aim to exercise the TSF in a different manner + from that achieved by the developer. In cases where + developer testing has been exhaustive, there may remain + little scope for this. + + + The developer shall provide the TOE for testing. + + + The TOE shall be suitable for testing. + + + The developer shall provide an equivalent set of resources + to those that were used in the developer's functional + testing of the TSF. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + The evaluator shall execute all tests in the test + documentation to verify the developer test results. + + + The evaluator shall test the TSF to confirm that the entire + TSF operates as specified. + + + + + + + + The class addresses the + possibility of exploitable vulnerabilities introduced in the + development or the operation of the TOE. + + + + Assurance class defines + requirements directed at the identification of exploitable + vulnerabilities. Specifically, it addresses those + vulnerabilities introduced in the development, operation, + misuse, or incorrect configuration of the TOE. + + + + Generally, the vulnerability assessment activity covers various + vulnerabilities in the development and operation of the + TOE. Development vulnerabilities take advantage of some property + of the TOE which was introduced during its development, + e.g. defeating the TSF self protection through tampering, direct + attack or monitoring of the TSF, defeating the TSF domain + separation through monitoring or direct attack the TSF, or + defeating non-bypassability through circumventing (bypassing) + the TSF. Operational vulnerabilities take advantage of + weaknesses in non-technical countermeasures to violate the TOE + SFRs, e.g. misuse or incorrect configuration. Misuse + investigates whether the TOE can be configured or used in a + manner that is insecure, but that an administrator or user of + the TOE would reasonably believe to be secure. + + Assessment of development vulnerabilities is covered by the + assurance family . Basically, + all development vulnerabilities can be considered in the + context of due to the fact, + that this family allows application of a wide range of + assessment methodologies being unspecific to the kind of an + attack scenario. These unspecific assessment methodologies + comprise, among other, also the specific methodologies for + those TSF where covert channels are to be considered (a + channel capacity estimation can be done using informal + engineering measurements, as well as actual test measurements) + or can be overcome by the use of sufficient resources in the + form of a direct attack (underlying technical concept of those + TSF is based on probabilistic or permutational mechanisms; a + qualification of their security behaviour and the effort + required to overcome them can be made using a quantitative or + statistical analysis). + + If there are security objectives specified in the ST to either + to prevent one user of the TOE from observing activity + associated with another user of the TOE, or to ensure that + information flows cannot be used to achieve enforced illicit + data signals, covert channel analysis should be considered + during the conduct of the vulnerability analysis. This is often + reflected by the inclusion of + and multilevel access control policies specified through and/or requirements in the ST. + + + + The purpose of the vulnerability assessment activity is to + determine the exploitability of flaws or weaknesses in the TOE + in the operational environment. This determination is based + upon analysis of the evaluation evidence and a search of + publicly available material by the evaluator and is supported + by evaluator penetration testing. + + + + + 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. + + + + Vulnerability analysis consists of the identification of + flaws potentially introduced in the different refinement + steps of the development (development vulnerabilities) or + through the application of the guidance in operation of the + TOE (operational vulnerabilities). It results in the + definition of penetration tests through the collection of + the necessary information concerning: (1) the completeness + of the TSF (does the TSF counter all the postulated + threats?), (2) the dependencies between all SFRs and (3) + whether any of the SFRs can be undermined through unexpected + behaviour of the TOE. These potential vulnerabilities are + assessed through penetration testing to determine whether + they could, in practise, be exploitable to compromise the + security of the TOE. + + The characteristics of different levels of attack potential + are discussed in CEM . + + + + Levelling is based on an increasing rigour of vulnerability + analysis by the evaluator and increased levels of attack + potential required by an attacker to identify and exploit + the potential vulnerabilities. + + + + + + + + A vulnerability survey of information available in the + public domain is performed by the evaluator to ascertain + potential vulnerabilities that may be easily found by an + attacker. + + The evaluator performs penetration testing, to confirm + that the potential vulnerabilities cannot be exploited in + the operational environment for the TOE. Penetration + testing is performed by the evaluator assuming an attack + potential of Basic. + + + + The objective of this sub-activity is to determine whether + the TOE, in its operational environment, has easily + identifiable exploitable vulnerabilities. + + + + The evaluator should consider performing additional tests + as a result of potential vulnerabilities encountered + during the conduct of other parts of the + evaluation. + + The use of the term guidance in this sub-activity refers + to the operational guidance and the preparative + guidance. + + Potential vulnerabilities may be in information that is + publicly available, or not, and may require skill to + exploit, or not. These two aspects are related, but are + distinct. It should not be assumed that, simply because a + potential vulnerability is identifiable from information + that is publicly available, it can be easily + exploited. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + + the guidance documentation; + + + the TOE suitable for testing; + + + information publicly available to support the + identification of potential vulnerabilities. + + + + Other input for this sub-activity is: + + + current information regarding potential + vulnerabilities (e.g. from an evaluation authority). + + + + + The developer shall provide the TOE for testing. + + + The TOE shall be suitable for testing. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the TOE to determine that + the test configuration is consistent with the + configuration under evaluation as specified in the + ST. + + The TOE provided by the developer and identified in the + test plan should have the same unique reference as + established by the + sub-activities and identified in the ST + introduction. + + It is possible for the ST to specify more than one + configuration for evaluation. The TOE may comprise a + number of distinct hardware and software entities that + need to be tested in accordance with the ST. The + evaluator verifies that all test configurations are + consistent with the ST. + + The evaluator should consider the security objectives + for the operational environment described in the ST that + may apply to the test environment and ensure they are + met in the testing environment. There may be some + objectives for the operational environment that do not + apply to the test environment. For example, an objective + about user clearances may not apply; however, an + objective about a single point of connection to a + network would apply. + + If any test resources are used (e.g. meters, analysers) + it will be the evaluator's responsibility to ensure that + these resources are calibrated correctly. + + + + + The evaluator shall examine the TOE to determine that it + has been installed properly and is in a known + state + + It is possible for the evaluator to determine the state + of the TOE in a number of ways. For example, previous + successful completion of the sub-activity will satisfy this work unit + if the evaluator still has confidence that the TOE being + used for testing was installed properly and is in a + known state. If this is not the case, then the evaluator + should follow the developer's procedures to install and + start up the TOE, using the supplied guidance + only. + + If the evaluator has to perform the installation + procedures because the TOE is in an unknown state, this + work unit when successfully completed could satisfy work + unit . + + + + The evaluator shall perform a search of public domain + sources to identify potential vulnerabilities in the TOE. + + + The evaluator shall examine sources of information + publicly available to identify potential vulnerabilities + in the TOE. + + The evaluator examines the sources of information + publicly available to support the identification of + possible potential vulnerabilities in the TOE. There are + many sources of publicly available information, which + should be considered, e.g. mailing lists and security + forums on the world wide web that report known + vulnerabilities in specified technologies. + + The evaluator should not constrain their consideration + of publicly available information to the above, but + should consider any other relevant information + available. + + While examining the evidence provided the evaluator will + use the information in the public domain to further + search for potential vulnerabilities. Where the + evaluators have identified areas of concern, the + evaluator should consider information publicly available + that relate to those areas of concern. + + The availability of information that may be readily + available to an attacker that helps to identify and + facilitate attacks effectively operates to substantially + enhance the attack potential of a given attacker. The + accessibility of vulnerability information and + sophisticated attack tools on the Internet makes it more + likely that this information will be used in attempts to + identify potential vulnerabilities in the TOE and + exploit them. Modern search tools make such information + easily available to the evaluator, and the determination + of resistance to published potential vulnerabilities and + well known generic attacks can be achieved in a + cost-effective manner. + + The search of the information publicly available should + be focused on those sources that refer specifically to + the product from which the TOE is derived. The + extensiveness of this search should consider the + following factors: TOE type, evaluator experience in + this TOE type, expected attack potential and the level + of evidence available. + + The identification process is iterative, where the + identification of one potential vulnerability may lead + to identifying another area of concern that requires + further investigation. + + The evaluator will report what actions were taken to + identify potential vulnerabilities in the information + publicly available. However, in this type of search, the + evaluator may not be able to describe the steps in + identifying potential vulnerabilities before the outset + of the examination, as the approach may evolve as a + result of findings during the search. + + The evaluator will report the evidence examined in + completing the search for potential + vulnerabilities. + + + + The evaluator shall record in the ETR the identified + potential vulnerabilities that are candidates for + testing and applicable to the TOE in its operational + environment. + + It may be identified that no further consideration of + the potential vulnerability is required if for example + the evaluator identifies that measures in the + operational environment, either IT or non-IT, prevent + exploitation of the potential vulnerability in that + operational environment. For instance, restricting + physical access to the TOE to authorised users only may + effectively render a potential vulnerability to + tampering unexploitable. + + The evaluator records any reasons for exclusion of + potential vulnerabilities from further consideration if + the evaluator determines that the potential + vulnerability is not applicable in the operational + environment. Otherwise the evaluator records the + potential vulnerability for further + consideration. + + A list of potential vulnerabilities applicable to the + TOE in its operational environment, which can be used as + an input into penetration testing activities, shall be + reported in the ETR by the evaluators. + + + + The evaluator shall conduct penetration testing, based on + the identified potential vulnerabilities, to determine that + the TOE is resistant to attacks performed by an attacker + possessing Basic attack potential. + + + The evaluator shall devise penetration tests, based on + the independent search for potential + vulnerabilities. + + The evaluator prepares for penetration testing as necessary to + determine the susceptibility of the TOE, in its operational + environment, to the potential vulnerabilities identified during + the search of the sources of information publicly available. + Any current information provided to the evaluator by a third + party (e.g. evaluation authority) regarding known potential + vulnerabilities will be considered by the evaluator, together + with any encountered potential vulnerabilities resulting from + the performance of other evaluation activities. + + The evaluator will probably find it practical to carry + out penetration test using a series of test cases, where + each test case will test for a specific potential + vulnerability. + + The evaluator is not expected to test for potential + vulnerabilities (including those in the public domain) + beyond those which required a Basic attack potential. In + some cases, however, it will be necessary to carry out a + test before the exploitability can be determined. Where, + as a result of evaluation expertise, the evaluator + discovers a potential vulnerability that is beyond Basic + attack potential, this is reported in the ETR as a + residual vulnerability. + + + + The evaluator shall produce penetration test + documentation for the tests based on the list of + potential vulnerabilities in sufficient detail to enable + the tests to be repeatable. The test documentation shall + include: + + + identification of the potential vulnerability the + TOE is being tested for; + + + instructions to connect and setup all required test + equipment as required to conduct the penetration + test; + + + instructions to establish all penetration test + prerequisite initial conditions; + + + instructions to stimulate the TSF; + + + instructions for observing the behaviour of the TSF; + + + descriptions of all expected results and the + necessary analysis to be performed on the observed + behaviour for comparison against expected results; + + + instructions to conclude the test and establish the + necessary post-test state for the TOE. + + + + The evaluator prepares for penetration testing based on + the list of potential vulnerabilities identified during + the search of the public domain. + + The evaluator is not expected to determine the + exploitability for potential vulnerabilities beyond + those for which a Basic attack potential is required to + effect an attack. However, as a result of evaluation + expertise, the evaluator may discover a potential + vulnerability that is exploitable only by an attacker + with greater than Basic attack potential. Such + vulnerabilities are to be reported in the ETR as + residual vulnerabilities. + + With an understanding of the potential vulnerability, + the evaluator determines the most feasible way to test + for the TOE's susceptibility. Specifically the evaluator + considers: + + + the TSFI or other TOE interface that will be used to + stimulate the TSF and observe responses; + + + initial conditions that will need to exist for the + test (i.e. any particular objects or subjects that + will need to exist and security attributes they will + need to have); + + + special test equipment that will be required to + either stimulate a TSFI or make observations of a + TSFI (although it is unlikely that specialist + equipment would be required to exploit a potential + vulnerability assuming a Basic attack potential); + + + whether theoretical analysis should replace physical + testing, particularly relevant where the results of + an initial test can be extrapolated to demonstrate + that repeated attempts of an attack are likely to + succeed after a given number of attempts. + + + + The evaluator will probably find it practical to carry + out penetration testing using a series of test cases, + where each test case will test for a specific potential + vulnerability. + + The intent of specifying this level of detail in the + test documentation is to allow another evaluator to + repeat the tests and obtain an equivalent result. + + + + The evaluator shall conduct penetration testing. + + The evaluator uses the penetration test documentation + resulting from work unit as a basis for executing penetration tests + on the TOE, but this does not preclude the evaluator + from performing additional ad hoc penetration tests. If + required, the evaluator may devise ad hoc tests as a + result of information learnt during penetration testing + that, if performed by the evaluator, are to be recorded + in the penetration test documentation. Such tests may be + required to follow up unexpected results or + observations, or to investigate potential + vulnerabilities suggested to the evaluator during the + pre-planned testing. + + The evaluator is not expected to test for potential + vulnerabilities (including those in the public domain) + beyond those which required a Basic attack potential. In + some cases, however, it will be necessary to carry out a + test before the exploitability can be determined. Where, + as a result of evaluation expertise, the evaluator + discovers a potential vulnerability that is beyond Basic + attack potential, this is reported in the ETR as a + residual vulnerability. + + + + The evaluator shall record the actual results of the + penetration tests. + + While some specific details of the actual test results + may be different from those expected (e.g. time and date + fields in an audit record) the overall result should be + identical. Any unexpected test results should be + investigated. The impact on the evaluation should be + stated and justified. + + + + The evaluator shall report in the ETR the evaluator + penetration testing effort, outlining the testing + approach, configuration, depth and results. + + The penetration testing information reported in the ETR + allows the evaluator to convey the overall penetration + testing approach and effort expended on this + sub-activity. The intent of providing this information + is to give a meaningful overview of the evaluator's + penetration testing effort. It is not intended that the + information regarding penetration testing in the ETR be + an exact reproduction of specific test steps or results + of individual penetration tests. The intention is to + provide enough detail to allow other evaluators and + evaluation authorities to gain some insight about the + penetration testing approach chosen, amount of + penetration testing performed, TOE test configurations, + and the overall results of the penetration testing + activity. + + Information that would typically be found in the ETR + subclause regarding evaluator penetration testing efforts + is: + + + TOE test configurations. The particular + configurations of the TOE that were penetration + tested; + + + TSFI penetration tested. A brief listing of the TSFI + and other TOE interfaces that were the focus of the + penetration testing; + + + verdict for the sub-activity. The overall judgement + on the results of penetration testing. + + + + This list is by no means exhaustive and is only intended + to provide some context as to the type of information + that should be present in the ETR concerning the + penetration testing the evaluator performed during the + evaluation. + + + + The evaluator shall examine the results of all + penetration testing to determine that the TOE, in its + operational environment, is resistant to an attacker + possessing a Basic attack potential. + + If the results reveal that the TOE, in its operational + environment, has vulnerabilities exploitable by an + attacker possessing less than Enhanced-Basic attack + potential, then this evaluator action fails. + + The guidance in should be used to determine the attack + potential required to exploit a particular vulnerability + and whether it can therefore be exploited in the + intended environment. It may not be necessary for the + attack potential to be calculated in every instance, + only if there is some doubt as to whether or not the + vulnerability can be exploited by an attacker possessing + an attack potential less than Enhanced-Basic. + + + + The evaluator shall report in the ETR all exploitable + vulnerabilities and residual vulnerabilities, detailing + for each: + + + its source (e.g. CEM activity being undertaken when + it was conceived, known to the evaluator, read in a + publication); + + + the SFR(s) not met; + + + a description; + + + whether it is exploitable in its operational + environment or not (i.e. exploitable or residual). + + + the amount of time, level of expertise, level of + knowledge of the TOE, level of opportunity and the + equipment required to perform the identified + vulnerabilities, and the corresponding values using + the tables and + of Annex . + + + + + + + + + + + + + + + A vulnerability analysis is performed by the evaluator to + ascertain the presence of potential + vulnerabilities. + + The evaluator performs penetration testing, to confirm + that the potential vulnerabilities cannot be exploited in + the operational environment for the TOE. Penetration + testing is performed by the evaluator assuming an attack + potential of Basic. + + + + The objective of this sub-activity is to determine whether + the TOE, in its operational environment, has + vulnerabilities exploitable by attackers possessing Basic + attack potential. + + + + The evaluator should consider performing additional tests + as a result of potential vulnerabilities encountered + during other parts of the evaluation. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + the functional specification; + + the TOE design; + + the security architecture description; + + the guidance documentation; + + the TOE suitable for testing; + + information publicly available to support the + identification of possible potential + vulnerabilities. + + The remaining implicit evaluation evidence for this + sub-activity depends on the components that have been + included in the assurance package. The evidence provided + for each component is to be used as input in this + sub-activity. + + Other input for this sub-activity is: + + + current information regarding public domain potential + vulnerabilities and attacks (e.g. from an evaluation + authority). + + + + + The developer shall provide the TOE for testing. + + + The TOE shall be suitable for testing. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the TOE to determine that + the test configuration is consistent with the + configuration under evaluation as specified in the + ST. + + The TOE provided by the developer and identified in the + test plan should have the same unique reference as + established by the + sub-activities and identified in the ST + introduction. + + It is possible for the ST to specify more than one + configuration for evaluation. The TOE may comprise a + number of distinct hardware and software entities that + need to be tested in accordance with the ST. The + evaluator verifies that all test configurations are + consistent with the ST. + + The evaluator should consider the security objectives + for the operational environment described in the ST that + may apply to the test environment and ensure they are + met in the testing environment. There may be some + objectives for the operational environment that do not + apply to the test environment. For example, an objective + about user clearances may not apply; however, an + objective about a single point of connection to a + network would apply. + + If any test resources are used (e.g. meters, analysers) + it will be the evaluator's responsibility to ensure that + these resources are calibrated correctly. + + + + + The evaluator shall examine the TOE to determine that it + has been installed properly and is in a known + state + + It is possible for the evaluator to determine the state + of the TOE in a number of ways. For example, previous + successful completion of the sub-activity will satisfy this work unit + if the evaluator still has confidence that the TOE being + used for testing was installed properly and is in a + known state. If this is not the case, then the evaluator + should follow the developer's procedures to install and + start up the TOE, using the supplied guidance + only. + + If the evaluator has to perform the installation + procedures because the TOE is in an unknown state, this + work unit when successfully completed could satisfy work + unit . + + + + The evaluator shall perform a search of public domain + sources to identify potential vulnerabilities in the TOE. + + + The evaluator shall examine sources of information + publicly available to identify potential vulnerabilities + in the TOE. + + The evaluator examines the sources of information + publicly available to support the identification of + possible potential vulnerabilities in the TOE. There are + many sources of publicly available information which the + evaluator should consider using items such as those + available on the world wide web, including: + + + specialist publications (magazines, books); + + + research papers. + + + + The evaluator should not constrain their consideration + of publicly available information to the above, but + should consider any other relevant information + available. + + While examining the evidence provided the evaluator will + use the information in the public domain to further + search for potential vulnerabilities. Where the + evaluators have identified areas of concern, the + evaluator should consider information publicly available + that relate to those areas of concern. + + The availability of information that may be readily + available to an attacker that helps to identify and + facilitate attacks may substantially enhance the attack + potential of a given attacker. The accessibility of + vulnerability information and sophisticated attack tools + on the Internet makes it more likely that this + information will be used in attempts to identify + potential vulnerabilities in the TOE and exploit + them. Modern search tools make such information easily + available to the evaluator, and the determination of + resistance to published potential vulnerabilities and + well known generic attacks can be achieved in a + cost-effective manner. + + The search of the information publicly available should + be focused on those sources that refer specifically to + the product from which the TOE is derived. The + extensiveness of this search should consider the + following factors: TOE type, evaluator experience in + this TOE type, expected attack potential and the level + of evidence available. + + The identification process is iterative, where the + identification of one potential vulnerability may lead + to identifying another area of concern that requires + further investigation. + + The evaluator will report what actions were taken to + identify potential vulnerabilities in the + evidence. However, in this type of search, the evaluator + may not be able to describe the steps in identifying + potential vulnerabilities before the outset of the + examination, as the approach may evolve as a result of + findings during the search. + + The evaluator will report the evidence examined in + completing the search for potential + vulnerabilities. This selection of evidence may be + derived from those areas of concern identified by the + evaluator, linked to the evidence the attacker is + assumed to be able to obtain, or according to another + rationale provided by the evaluator. + + + + The evaluator shall perform an independent vulnerability + analysis of the TOE using the guidance documentation, + functional specification, TOE design and security + architecture description to identify potential + vulnerabilities in the TOE. + + + The evaluator shall conduct a search of ST, guidance + documentation, functional specification, TOE design and + security architecture description evidence to identify + possible potential vulnerabilities in the TOE. + + A search of the evidence should be completed whereby + specifications and documentation for the TOE are + analysed and then potential vulnerabilities in the TOE + are hypothesised, or speculated. The list of + hypothesised potential vulnerabilities is then + prioritised on the basis of the estimated probability + that a potential vulnerability exists and, assuming an + exploitable vulnerability does exist the attack + potential required to exploit it, and on the extent of + control or compromise it would provide. The prioritised + list of potential vulnerabilities is used to direct + penetration testing against the TOE. + + The security architecture description provides the + developer vulnerability analysis, as it documents how + the TSF protects itself from interference from untrusted + subjects and prevents the bypass of security enforcement + functionality. Therefore, the evaluator should use this + description of the protection of the TSF as a basis for + the search for possible ways to undermine the + TSF. + + Subject to the SFRs the TOE is to meet in the + operational environment, the evaluator's independent + vulnerability analysis should consider generic potential + vulnerabilities under each of the following headings: + + + generic potential vulnerabilities relevant for the + type of TOE being evaluated, as may be supplied by + the evaluation authority; + + bypassing; + + tampering; + + direct attacks; + + monitoring; + + misuse. + + Items b) - f) are explained in greater detail in . + + The security architecture description should be + considered in light of each of the above generic + potential vulnerabilities. Each potential vulnerability + should be considered to search for possible ways in + which to defeat the TSF protection and undermine the + TSF. + + + + The evaluator shall record in the ETR the identified + potential vulnerabilities that are candidates for + testing and applicable to the TOE in its operational + environment. + + It may be identified that no further consideration of + the potential vulnerability is required if for example + the evaluator identifies that measures in the + operational environment, either IT or non-IT, prevent + exploitation of the potential vulnerability in that + operational environment. For instance, restricting + physical access to the TOE to authorised users only may + effectively render a potential vulnerability to + tampering unexploitable. + + The evaluator records any reasons for exclusion of + potential vulnerabilities from further consideration if + the evaluator determines that the potential + vulnerability is not applicable in the operational + environment. Otherwise the evaluator records the + potential vulnerability for further + consideration. + + A list of potential vulnerabilities applicable to the + TOE in its operational environment, which can be used as + an input into penetration testing activities, shall be + reported in the ETR by the evaluators. + + + + The evaluator shall conduct penetration testing, based on + the identified potential vulnerabilities, to determine that + the TOE is resistant to attacks performed by an attacker + possessing Basic attack potential. + + + The evaluator shall devise penetration tests, based on + the independent search for potential + vulnerabilities. + + The evaluator prepares for penetration testing as necessary to + determine the susceptibility of the TOE, in its operational + environment, to the potential vulnerabilities identified during + the search of the sources of information publicly available. + Any current information provided to the evaluator by a third + party (e.g. evaluation authority) regarding known potential + vulnerabilities will be considered by the evaluator, together + with any encountered potential vulnerabilities resulting from + the performance of other evaluation activities. + + The evaluator is reminded that, as for considering the security + architecture description in the search for vulnerabilities (as + detailed in ), testing should + be performed to confirm the architectural properties. This is + likely to require negative tests attempting to disprove the + properties of the security architecture. In developing the + strategy for penetration testing, the evaluator will ensure that + each of the major characteristics of the security architecture + description are tested, either in functional testing (as + considered in ) or evaluator + penetration testing. + + The evaluator will probably find it practical to carry + out penetration test using a series of test cases, where + each test case will test for a specific potential + vulnerability. + + The evaluator is not expected to test for potential + vulnerabilities (including those in the public domain) + beyond those which required a Basic attack potential. In + some cases, however, it will be necessary to carry out a + test before the exploitability can be determined. Where, + as a result of evaluation expertise, the evaluator + discovers an exploitable vulnerability that is beyond + Basic attack potential, this is reported in the ETR as a + residual vulnerability. + + Guidance on determining the necessary attack potential + to exploit a potential vulnerability can be found in + Annex . + + Potential vulnerabilities hypothesised as exploitable + only by attackers possessing Enhanced-Basic, Moderate or + High attack potential do not result in a failure of this + evaluator action. Where analysis supports the + hypothesis, these need not be considered further as an + input to penetration testing. However, such + vulnerabilities are reported in the ETR as residual + vulnerabilities. + + Potential vulnerabilities hypothesised as exploitable by + an attacker possessing a Basic attack potential and + resulting in a violation of the security objectives + should be the highest priority potential vulnerabilities + comprising the list used to direct penetration testing + against the TOE. + + + + The evaluator shall produce penetration test + documentation for the tests based on the list of + potential vulnerabilities in sufficient detail to enable + the tests to be repeatable. The test documentation shall + include: + + + identification of the potential vulnerability the + TOE is being tested for; + + + instructions to connect and setup all required test + equipment as required to conduct the penetration + test; + + + instructions to establish all penetration test + prerequisite initial conditions; + + + instructions to stimulate the TSF; + + + instructions for observing the behaviour of the TSF; + + + descriptions of all expected results and the + necessary analysis to be performed on the observed + behaviour for comparison against expected results; + + + instructions to conclude the test and establish the + necessary post-test state for the TOE. + + + + The evaluator prepares for penetration testing based on + the list of potential vulnerabilities identified during + the search of the public domain and the analysis of the + evaluation evidence. + + The evaluator is not expected to determine the + exploitability for potential vulnerabilities beyond + those for which a Basic attack potential is required to + effect an attack. However, as a result of evaluation + expertise, the evaluator may discover a potential + vulnerability that is exploitable only by an attacker + with greater than Basic attack potential. Such + vulnerabilities are to be reported in the ETR as + residual vulnerabilities. + + With an understanding of the potential vulnerability, + the evaluator determines the most feasible way to test + for the TOE's susceptibility. Specifically the evaluator + considers: + + + the TSFI or other TOE interface that will be used to + stimulate the TSF and observe responses (It is + possible that the evaluator will need to use an + interface to the TOE other than the TSFI to + demonstrate properties of the TSF such as those + described in the security architecture description + (as required by ). It + should the noted, that although these TOE interfaces + provide a means of testing the TSF properties, they + are not the subject of the test.); + + + initial conditions that will need to exist for the + test (i.e. any particular objects or subjects that + will need to exist and security attributes they will + need to have); + + + special test equipment that will be required to + either stimulate a TSFI or make observations of a + TSFI (although it is unlikely that specialist + equipment would be required to exploit a potential + vulnerability assuming a Basic attack potential); + + + whether theoretical analysis should replace physical + testing, particularly relevant where the results of + an initial test can be extrapolated to demonstrate + that repeated attempts of an attack are likely to + succeed after a given number of attempts. + + + + The evaluator will probably find it practical to carry + out penetration testing using a series of test cases, + where each test case will test for a specific potential + vulnerability. + + The intent of specifying this level of detail in the + test documentation is to allow another evaluator to + repeat the tests and obtain an equivalent result. + + + + The evaluator shall conduct penetration testing. + + The evaluator uses the penetration test documentation + resulting from work unit as a basis for executing penetration tests + on the TOE, but this does not preclude the evaluator + from performing additional ad hoc penetration tests. If + required, the evaluator may devise ad hoc tests as a + result of information learnt during penetration testing + that, if performed by the evaluator, are to be recorded + in the penetration test documentation. Such tests may be + required to follow up unexpected results or + observations, or to investigate potential + vulnerabilities suggested to the evaluator during the + pre-planned testing. + + Should penetration testing show that a hypothesised + potential vulnerability does not exist, then the + evaluator should determine whether or not the + evaluator's own analysis was incorrect, or if evaluation + deliverables are incorrect or incomplete. + + The evaluator is not expected to test for potential + vulnerabilities (including those in the public domain) + beyond those which required a Basic attack potential. In + some cases, however, it will be necessary to carry out a + test before the exploitability can be determined. Where, + as a result of evaluation expertise, the evaluator + discovers an exploitable vulnerability that is beyond + basic attack potential, this is reported in the ETR as a + residual vulnerability. + + + + The evaluator shall record the actual results of the + penetration tests. + + While some specific details of the actual test results + may be different from those expected (e.g. time and date + fields in an audit record) the overall result should be + identical. Any unexpected test results should be + investigated. The impact on the evaluation should be + stated and justified. + + + + The evaluator shall report in the ETR the evaluator + penetration testing effort, outlining the testing + approach, configuration, depth and results. + + The penetration testing information reported in the ETR + allows the evaluator to convey the overall penetration + testing approach and effort expended on this + sub-activity. The intent of providing this information + is to give a meaningful overview of the evaluator's + penetration testing effort. It is not intended that the + information regarding penetration testing in the ETR be + an exact reproduction of specific test steps or results + of individual penetration tests. The intention is to + provide enough detail to allow other evaluators and + evaluation authorities to gain some insight about the + penetration testing approach chosen, amount of + penetration testing performed, TOE test configurations, + and the overall results of the penetration testing + activity. + + Information that would typically be found in the ETR + subclause regarding evaluator penetration testing efforts + is: + + + TOE test configurations. The particular + configurations of the TOE that were penetration + tested; + + + TSFI penetration tested. A brief listing of the TSFI + and other TOE interfaces that were the focus of the + penetration testing; + + + Verdict for the sub-activity. The overall judgement + on the results of penetration testing. + + + + This list is by no means exhaustive and is only intended + to provide some context as to the type of information + that should be present in the ETR concerning the + penetration testing the evaluator performed during the + evaluation. + + + + The evaluator shall examine the results of all + penetration testing to determine that the TOE, in its + operational environment, is resistant to an attacker + possessing a Basic attack potential. + + If the results reveal that the TOE, in its operational + environment, has vulnerabilities exploitable by an + attacker possessing less than an Enhanced-Basic attack + potential, then this evaluator action fails. + + The guidance in should be used to determine the attack + potential required to exploit a particular vulnerability + and whether it can therefore be exploited in the + intended environment. It may not be necessary for the + attack potential to be calculated in every instance, + only if there is some doubt as to whether or not the + vulnerability can be exploited by an attacker possessing + an attack potential less than Enhanced-Basic. + + + + The evaluator shall report in the ETR all exploitable + vulnerabilities and residual vulnerabilities, detailing + for each: + + + its source (e.g. CEM activity being undertaken when + it was conceived, known to the evaluator, read in a + publication); + + + the SFR(s) not met; + + + a description; + + + whether it is exploitable in its operational + environment or not (i.e. exploitable or residual). + + + the amount of time, level of expertise, level of + knowledge of the TOE, level of opportunity and the + equipment required to perform the identified + vulnerabilities, and the corresponding values using + the tables and + of Annex . + + + + + + + + + + + + + + + + A vulnerability analysis is performed by the evaluator to + ascertain the presence of potential + vulnerabilities. + + The evaluator performs penetration testing, to confirm + that the potential vulnerabilities cannot be exploited in + the operational environment for the TOE. Penetration + testing is performed by the evaluator assuming an attack + potential of Enhanced-Basic. + + + + The objective of this sub-activity is to determine whether + the TOE, in its operational environment, has + vulnerabilities exploitable by attackers possessing + Enhanced-Basic attack potential. + + + + During the conduct of evaluation activities the evaluator + may also identify areas of concern. These are specific + portions of the TOE evidence that the evaluator has some + reservation about, although the evidence meets the + requirements for the activity with which the evidence is + associated. For example, a particular interface + specification looks particularly complex, and therefore + may be prone to error either in the development of the TOE + or in the operation of the TOE. There is no potential + vulnerability apparent at this stage, further + investigation is required. This is beyond the bounds of + encountered, as further investigation is required. + + The focused approach to the identification of potential + vulnerabilities is an analysis of the evidence with the + aim of identifying any potential vulnerabilities evident + through the contained information. It is an unstructured + analysis, as the approach is not predetermined. Further + guidance on focused vulnerability analysis can be found in + Annex . + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + the functional specification; + + the TOE design; + + the security architecture description; + + the implementation subset selected; + + the guidance documentation; + + the TOE suitable for testing; + + information publicly available to support the identification of possible potential vulnerabilities; + + the results of the testing of the basic design. + + + The remaining implicit evaluation evidence for this + sub-activity depends on the components that have been + included in the assurance package. The evidence provided + for each component is to be used as input in this + sub-activity. + + Other input for this sub-activity is: + + + current information regarding public domain potential + vulnerabilities and attacks (e.g. from an evaluation + authority). + + + + + The developer shall provide the TOE for testing. + + + The TOE shall be suitable for testing. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the TOE to determine that + the test configuration is consistent with the + configuration under evaluation as specified in the + ST. + + The TOE provided by the developer and identified in the + test plan should have the same unique reference as + established by the + sub-activities and identified in the ST + introduction. + + It is possible for the ST to specify more than one + configuration for evaluation. The TOE may comprise a + number of distinct hardware and software entities that + need to be tested in accordance with the ST. The + evaluator verifies that all test configurations are + consistent with the ST. + + The evaluator should consider the security objectives + for the operational environment described in the ST that + may apply to the test environment and ensure they are + met in the testing environment. There may be some + objectives for the operational environment that do not + apply to the test environment. For example, an objective + about user clearances may not apply; however, an + objective about a single point of connection to a + network would apply. + + If any test resources are used (e.g. meters, analysers) + it will be the evaluator's responsibility to ensure that + these resources are calibrated correctly. + + + + + The evaluator shall examine the TOE to determine that it + has been installed properly and is in a known + state + + It is possible for the evaluator to determine the state + of the TOE in a number of ways. For example, previous + successful completion of the sub-activity will satisfy this work unit + if the evaluator still has confidence that the TOE being + used for testing was installed properly and is in a + known state. If this is not the case, then the evaluator + should follow the developer's procedures to install and + start up the TOE, using the supplied guidance + only. + + If the evaluator has to perform the installation + procedures because the TOE is in an unknown state, this + work unit when successfully completed could satisfy work + unit . + + + + The evaluator shall perform a search of public domain + sources to identify potential vulnerabilities in the TOE. + + + The evaluator shall examine sources of information + publicly available to identify potential vulnerabilities + in the TOE. + + The evaluator examines the sources of information + publicly available to support the identification of + possible potential vulnerabilities in the TOE. There are + many sources of publicly available information which the + evaluator should consider using items such as those + available on the world wide web, including: + + + specialist publications (magazines, books); + + + research papers; + + + conference proceedings. + + + + The evaluator should not constrain their consideration + of publicly available information to the above, but + should consider any other relevant information + available. + + While examining the evidence provided the evaluator will + use the information in the public domain to further + search for potential vulnerabilities. Where the + evaluators have identified areas of concern, the + evaluator should consider information publicly available + that relate to those areas of concern. + + The availability of information that may be readily + available to an attacker that helps to identify and + facilitate attacks may substantially enhance the attack + potential of a given attacker. The accessibility of + vulnerability information and sophisticated attack tools + on the Internet makes it more likely that this + information will be used in attempts to identify + potential vulnerabilities in the TOE and exploit + them. Modern search tools make such information easily + available to the evaluator, and the determination of + resistance to published potential vulnerabilities and + well known generic attacks can be achieved in a + cost-effective manner. + + The search of the information publicly available should + be focused on those sources that refer to the + technologies used in the development of the product from + which the TOE is derived. The extensiveness of this + search should consider the following factors: TOE type, + evaluator experience in this TOE type, expected attack + potential and the level of + evidence available. + + The identification process is iterative, where the + identification of one potential vulnerability may lead + to identifying another area of concern that requires + further investigation. + + The evaluator will report what actions were taken to + identify potential vulnerabilities in the + evidence. However, in this type of search, the evaluator + may not be able to describe the steps in identifying + potential vulnerabilities before the outset of the + examination, as the approach may evolve as a result of + findings during the search. + + The evaluator will report the evidence examined in + completing the search for potential + vulnerabilities. This selection of evidence may be + derived from those areas of concern identified by the + evaluator, linked to the evidence the attacker is + assumed to be able to obtain, or according to another + rationale provided by the evaluator. + + + + The evaluator shall perform an independent, focused vulnerability analysis of the + TOE using the guidance documentation, functional specification, TOE design, security + architecture description and implementation representation to identify potential + vulnerabilities in the TOE. + + + The evaluator shall conduct a focused search of ST, + guidance documentation, functional specification, TOE + design, security architecture description and + implementation representation to identify possible + potential vulnerabilities in the TOE. + + A flaw hypothesis methodology needs to be used whereby + specifications and development and guidance evidence are + analysed and then potential vulnerabilities in the TOE are + hypothesised, or speculated. + + The evaluator uses the knowledge of the TOE design and operation + gained from the TOE deliverables to conduct a flaw hypothesis to + identify potential flaws in the development of the TOE and + potential errors in the specified method of operation of the + TOE. + + The security architecture description provides the developer + vulnerability analysis, as it documents how the TSF protects + itself from interference from untrusted subjects and prevents + the bypass of security enforcement functionality. Therefore, the + evaluator should build upon the understanding of the TSF + protection gained from the analysis of this evidence and then + develop this in the knowledge gained from other development + evidence. + + + The approach taken is directed by areas of concern + identified during examination of the evidence during the + conduct of evaluation activities and ensuring a + representative sample of the development and guidance + evidence provided for the evaluation is searched. + + For guidance on sampling see Annex . This guidance + should be considered when selecting the subset, giving + reasons for: + + + the approach used in selection; + + + qualification that the evidence to be examined + supports that approach. + + + + The areas of concern may relate to the sufficiency of + specific protection features detailed in the security + architecture description. + + The evidence to be considered during the vulnerability analysis + may be linked to the evidence the attacker is assumed to be able + to obtain. For example, the developer may protect the TOE design + and implementation representations, so the only information + assumed to be available to an attacker is the functional + specification and guidance (publicly available). So, although + the objectives for assurance in the TOE ensure the TOE design + and implementation representation requirements are met, these + design representations may only be searched to further + investigate areas of concerns. + + On the other hand, if the source is publicly available it would + be reasonable to assume that the attacker has access to the + source and can use this in attempts to attack the + TOE. Therefore, the source should be considered in the focused + examination approach. + + The following indicates examples for the selection of + the subset of evidence to be considered: + + + For an evaluation where all levels of design + abstraction from functional specification to + implementation representation are provided, + examination of information in the functional + specification and the implementation representation + may be selected, as the functional specification + provides detail of interfaces available to an + attacker, and the implementation representation + incorporates the design decisions made at all other + design abstractions. Therefore, the TOE design + information will be considered as part of the + implementation representation. + + + Examination of a particular subset of information in + each of the design representations provided for the + evaluation. + + + Coverage of particular SFRs through each of the + design representations provided for the evaluation. + + + Examination of each of the design representations + provided for the evaluation, considering different + SFRs within each design representations. + + + Examination of aspects of the evidence provided for + the evaluation relating to current potential + vulnerability information the evaluator has received + (e.g. from a scheme). + + + + This approach to identification of potential + vulnerabilities is to take an ordered and planned + approach; applying a system to the examination. The + evaluator is to describe the method to be used in terms + of what evidence will be considered, the information + within the evidence that is to be examined, the manner + in which this information is to be considered and the + hypothesis that is to be created. + + The following provide some examples that a hypothesis + may take: + + + consideration of malformed input for interfaces + available to an attacker at the external interfaces; + + + examination of a key security mechanism cited in the + security architecture description, such as process + separation, hypothesising internal buffer overflows + that may lead to degradation of separation; + + + search to identify any objects created in the TOE + implementation representation that are then not + fully controlled by the TSF, and could be used by an + attacker to undermine SFRs. + + + + For example, the evaluator may identify that interfaces + are a potential area of weakness in the TOE and specify + an approach to the search that ``all interface + specifications provided in the functional specification + and TOE design will be searched to hypothesise potential + vulnerabilities'' and go on to explain the methods used + in the hypothesis. + + The identification process is iterative, where the + identification of one potential vulnerability may lead + to identifying another area of concern that requires + further investigation. + + The evaluator will report what actions were taken to + identify potential vulnerabilities in the + evidence. However, in this type of search, the evaluator + may not be able to describe the steps in identifying + potential vulnerabilities before the outset of the + examination, as the approach may evolve as a result of + findings during the search. + + The evaluator will report the evidence examine in + completing the search for potential + vulnerabilities. This selection of evidence may be + derived from those areas of concern identified by the + evaluator, linked to the evidence the attacker is + assumed to be able to obtain, or according to another + rationale provided by the evaluator. + + Subject to the SFRs the TOE is to meet in the + operational environment, the evaluator's independent + vulnerability analysis should consider generic potential + vulnerabilities under each of the following headings: + + + generic potential vulnerabilities relevant for the + type of TOE being evaluated, as may be supplied by + the evaluation authority; + + bypassing; + + tampering; + + direct attacks; + + monitoring; + + misuse. + + Items b) - f) are explained in greater detail in . + + The security architecture description should be + considered in light of each of the above generic + potential vulnerabilities. Each potential vulnerability + should be considered to search for possible ways in + which to defeat the TSF protection and undermine the + TSF. + + + The evaluator shall record in the ETR the identified + potential vulnerabilities that are candidates for + testing and applicable to the TOE in its operational + environment. + + It may be identified that no further consideration of + the potential vulnerability is required if for example + the evaluator identifies that measures in the + operational environment, either IT or non-IT, prevent + exploitation of the potential vulnerability in that + operational environment. For instance, restricting + physical access to the TOE to authorised users only may + effectively render a potential vulnerability to + tampering unexploitable. + + The evaluator records any reasons for exclusion of + potential vulnerabilities from further consideration if + the evaluator determines that the potential + vulnerability is not applicable in the operational + environment. Otherwise the evaluator records the + potential vulnerability for further + consideration. + + A list of potential vulnerabilities applicable to the + TOE in its operational environment, which can be used as + an input into penetration testing activities, shall be + reported in the ETR by the evaluators. + + + The evaluator shall conduct penetration testing, based on + the identified potential vulnerabilities, to determine that + the TOE is resistant to attacks performed by an attacker + possessing Enhanced-Basic attack potential. + + + The evaluator shall devise penetration tests, based on + the independent search for potential + vulnerabilities. + + The evaluator prepares for penetration testing as necessary to + determine the susceptibility of the TOE, in its operational + environment, to the potential vulnerabilities identified during + the search of the sources of information publicly available. + Any current information provided to the evaluator by a third + party (e.g. evaluation authority) regarding known potential + vulnerabilities will be considered by the evaluator, together + with any encountered potential vulnerabilities resulting from + the performance of other evaluation activities. + + The evaluator is reminded that, as for considering the security + architecture description in the search for vulnerabilities (as + detailed in ), testing should + be performed to confirm the architectural properties. If + requirements from are included in + the SARs, the developer testing evidence will include testing + performed to confirm the correct implementation of any specific + mechanisms detailed in the security architecture + description. However, the developer testing will not necessarily + include testing of all aspects of the architectural properties + that protect the TSF, as much of this testing will be negative + testing in nature, attempting to disprove the properties. In + developing the strategy for penetration testing, the evaluator + will ensure that all aspects of the security architecture + description are tested, either in functional testing (as + considered in ) or evaluator + penetration testing. + + It will probably be practical to carry out penetration + test using a series of test cases, where each test case + will test for a specific potential vulnerability. + + The evaluator is not expected to test for potential + vulnerabilities (including those in the public domain) + beyond those which required an Enhanced-Basic attack + potential. In some cases, however, it will be necessary + to carry out a test before the exploitability can be + determined. Where, as a result of evaluation expertise, + the evaluator discovers an exploitable vulnerability + that is beyond Enhanced-Basic attack potential, this is + reported in the ETR as a residual vulnerability. + + Guidance on determining the necessary attack potential + to exploit a potential vulnerability can be found in + Annex . + + Potential vulnerabilities hypothesised as exploitable + only by attackers possessing Moderate or High attack + potential do not result in a failure of this evaluator + action. Where analysis supports the hypothesis, these + need not be considered further as an input to + penetration testing. However, such vulnerabilities are + reported in the ETR as residual vulnerabilities. + + Potential vulnerabilities hypothesised as exploitable by + an attacker possessing a Basic or Enhanced-Basic attack + potential and resulting in a violation of the security + objectives should be the highest priority potential + vulnerabilities comprising the list used to direct + penetration testing against the TOE. + + + + The evaluator shall produce penetration test + documentation for the tests based on the list of + potential vulnerabilities in sufficient detail to enable + the tests to be repeatable. The test documentation shall + include: + + + identification of the potential vulnerability the + TOE is being tested for; + + + instructions to connect and setup all required test + equipment as required to conduct the penetration + test; + + + instructions to establish all penetration test + prerequisite initial conditions; + + + instructions to stimulate the TSF; + + + instructions for observing the behaviour of the TSF; + + + descriptions of all expected results and the + necessary analysis to be performed on the observed + behaviour for comparison against expected results; + + + instructions to conclude the test and establish the + necessary post-test state for the TOE. + + + + The evaluator prepares for penetration testing based on + the list of potential vulnerabilities identified during + the search of the public domain and the analysis of the + evaluation evidence. + + The evaluator is not expected to determine the + exploitability for potential vulnerabilities beyond + those for which an Enhanced-Basic attack potential is + required to effect an attack. However, as a result of + evaluation expertise, the evaluator may discover a + potential vulnerability that is exploitable only by an + attacker with greater than Enhanced-Basic attack + potential. Such vulnerabilities are to be reported in + the ETR as residual vulnerabilities. + + With an understanding of the potential vulnerability, + the evaluator determines the most feasible way to test + for the TOE's susceptibility. Specifically the evaluator + considers: + + + the TSFI or other TOE interface that will be used to + stimulate the TSF and observe responses (It is + possible that the evaluator will need to use an + interface to the TOE other than the TSFI to + demonstrate properties of the TSF such as those + described in the security architecture description + (as required by ). It + should the noted, that although these TOE interfaces + provide a means of testing the TSF properties, they + are not the subject of the test.); + + + initial conditions that will need to exist for the + test (i.e. any particular objects or subjects that + will need to exist and security attributes they will + need to have); + + + special test equipment that will be required to + either stimulate a TSFI or make observations of a + TSFI (although it is unlikely that specialist + equipment would be required to exploit a potential + vulnerability assuming an Enhanced-Basic attack + potential); + + + whether theoretical analysis should replace physical + testing, particularly relevant where the results of + an initial test can be extrapolated to demonstrate + that repeated attempts of an attack are likely to + succeed after a given number of attempts. + + + + The evaluator will probably find it practical to carry + out penetration testing using a series of test cases, + where each test case will test for a specific potential + vulnerability. + + The intent of specifying this level of detail in the + test documentation is to allow another evaluator to + repeat the tests and obtain an equivalent result. + + + + The evaluator shall conduct penetration testing. + + The evaluator uses the penetration test documentation + resulting from work unit as a basis for executing penetration tests + on the TOE, but this does not preclude the evaluator + from performing additional ad hoc penetration tests. If + required, the evaluator may devise ad hoc tests as a + result of information learnt during penetration testing + that, if performed by the evaluator, are to be recorded + in the penetration test documentation. Such tests may be + required to follow up unexpected results or + observations, or to investigate potential + vulnerabilities suggested to the evaluator during the + pre-planned testing. + + Should penetration testing show that a hypothesised + potential vulnerability does not exist, then the + evaluator should determine whether or not the + evaluator's own analysis was incorrect, or if evaluation + deliverables are incorrect or incomplete. + + The evaluator is not expected to test for potential + vulnerabilities (including those in the public domain) + beyond those which required an Enhanced-Basic attack + potential. In some cases, however, it will be necessary + to carry out a test before the exploitability can be + determined. Where, as a result of evaluation expertise, + the evaluator discovers an exploitable vulnerability + that is beyond Enhanced-Basic attack potential, this is + reported in the ETR as a residual vulnerability. + + + + The evaluator shall record the actual results of the + penetration tests. + + While some specific details of the actual test results + may be different from those expected (e.g. time and date + fields in an audit record) the overall result should be + identical. Any unexpected test results should be + investigated. The impact on the evaluation should be + stated and justified. + + + + The evaluator shall report in the ETR the evaluator + penetration testing effort, outlining the testing + approach, configuration, depth and results. + + The penetration testing information reported in the ETR + allows the evaluator to convey the overall penetration + testing approach and effort expended on this + sub-activity. The intent of providing this information + is to give a meaningful overview of the evaluator's + penetration testing effort. It is not intended that the + information regarding penetration testing in the ETR be + an exact reproduction of specific test steps or results + of individual penetration tests. The intention is to + provide enough detail to allow other evaluators and + evaluation authorities to gain some insight about the + penetration testing approach chosen, amount of + penetration testing performed, TOE test configurations, + and the overall results of the penetration testing + activity. + + Information that would typically be found in the ETR + subclause regarding evaluator penetration testing efforts + is: + + + TOE test configurations. The particular + configurations of the TOE that were penetration + tested; + + + TSFI penetration tested. A brief listing of the TSFI + and other TOE interfaces that were the focus of the + penetration testing; + + + Verdict for the sub-activity. The overall judgement + on the results of penetration testing. + + + + This list is by no means exhaustive and is only intended + to provide some context as to the type of information + that should be present in the ETR concerning the + penetration testing the evaluator performed during the + evaluation. + + + + The evaluator shall examine the results of all + penetration testing to determine that the TOE, in its + operational environment, is resistant to an attacker + possessing an Enhanced-Basic attack potential. + + If the results reveal that the TOE, in its operational + environment, has vulnerabilities exploitable by an + attacker possessing less than Moderate attack potential, + then this evaluator action fails. + + The guidance in should be used to determine the attack + potential required to exploit a particular vulnerability + and whether it can therefore be exploited in the + intended environment. It may not be necessary for the + attack potential to be calculated in every instance, + only if there is some doubt as to whether or not the + vulnerability can be exploited by an attacker possessing + an attack potential less than Moderate. + + + + The evaluator shall report in the ETR all exploitable + vulnerabilities and residual vulnerabilities, detailing + for each: + + + its source (e.g. CEM activity being undertaken when + it was conceived, known to the evaluator, read in a + publication); + + + the SFR(s) not met; + + + a description; + + + whether it is exploitable in its operational + environment or not (i.e. exploitable or residual). + + + the amount of time, level of expertise, level of + knowledge of the TOE, level of opportunity and the + equipment required to perform the identified + vulnerabilities, and the corresponding values using + the tables and + of Annex . + + + + + + + + + + + + + + + + A methodical vulnerability analysis is performed by the + evaluator to ascertain the presence of potential + vulnerabilities. + + The evaluator performs penetration testing, to confirm + that the potential vulnerabilities cannot be exploited in + the operational environment for the TOE. Penetration + testing is performed by the evaluator assuming an attack + potential of Moderate. + + + + The objective of this sub-activity is to determine whether + the TOE, in its operational environment, has + vulnerabilities exploitable by attackers possessing + Moderate attack potential. + + + + The methodical analysis approach takes the form of a + structured examination of the evidence. This method + requires the evaluator to specify the structure and form + the analysis will take (i.e. the manner in which the + analysis is performed is predetermined, unlike the focused + analysis). The method is specified in terms of the + information that will be considered and how/why it will be + considered. Further guidance on methodical vulnerability + analysis can be found in Annex . + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + the functional specification; + + the TOE design; + + the security architecture description; + + the implementation representation; + + the guidance documentation; + + the TOE suitable for testing; + + information publicly available to support the identification of possible potential vulnerabilities; + + the results of the testing of the basic design. + + + The remaining implicit evaluation evidence for this + sub-activity depends on the components that have been + included in the assurance package. The evidence provided + for each component is to be used as input in this + sub-activity. + + Other input for this sub-activity is: + + + current information regarding public domain potential + vulnerabilities and attacks (e.g. from an evaluation + authority). + + + + + The developer shall provide the TOE for testing. + + + The TOE shall be suitable for testing. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + + The evaluator shall examine the TOE to determine that + the test configuration is consistent with the + configuration under evaluation as specified in the + ST. + + The TOE provided by the developer and identified in the + test plan should have the same unique reference as + established by the + sub-activities and identified in the ST + introduction. + + It is possible for the ST to specify more than one + configuration for evaluation. The TOE may comprise a + number of distinct hardware and software entities that + need to be tested in accordance with the ST. The + evaluator verifies that all test configurations are + consistent with the ST. + + The evaluator should consider the security objectives + for the operational environment described in the ST that + may apply to the test environment and ensure they are + met in the testing environment. There may be some + objectives for the operational environment that do not + apply to the test environment. For example, an objective + about user clearances may not apply; however, an + objective about a single point of connection to a + network would apply. + + If any test resources are used (e.g. meters, analysers) + it will be the evaluator's responsibility to ensure that + these resources are calibrated correctly. + + + + + The evaluator shall examine the TOE to determine that it + has been installed properly and is in a known + state + + It is possible for the evaluator to determine the state + of the TOE in a number of ways. For example, previous + successful completion of the sub-activity will satisfy this work unit + if the evaluator still has confidence that the TOE being + used for testing was installed properly and is in a + known state. If this is not the case, then the evaluator + should follow the developer's procedures to install and + start up the TOE, using the supplied guidance + only. + + If the evaluator has to perform the installation + procedures because the TOE is in an unknown state, this + work unit when successfully completed could satisfy work + unit . + + + + The evaluator shall perform a search of public domain + sources to identify potential vulnerabilities in the TOE. + + + The evaluator shall examine sources of information + publicly available to identify potential vulnerabilities + in the TOE. + + The evaluator examines the sources of information + publicly available to support the identification of + possible potential vulnerabilities in the TOE. There are + many sources of publicly available information which the + evaluator should consider using items such as those + available on the world wide web, including: + + + specialist publications (magazines, books); + + + research papers; + + + conference proceedings. + + + + The evaluator should not constrain their consideration + of publicly available information to the above, but + should consider any other relevant information + available. + + While examining the evidence provided the evaluator will + use the information in the public domain to further + search for potential vulnerabilities. Where the + evaluators have identified areas of concern, the + evaluator should consider information publicly available + that relate to those areas of concern. + + The availability of information that may be readily + available to an attacker that helps to identify and + facilitate attacks may substantially enhance the attack + potential of a given attacker. The accessibility of + vulnerability information and sophisticated attack tools + on the Internet makes it more likely that this + information will be used in attempts to identify + potential vulnerabilities in the TOE and exploit + them. Modern search tools make such information easily + available to the evaluator, and the determination of + resistance to published potential vulnerabilities and + well known generic attacks can be achieved in a + cost-effective manner. + + The search of the information publicly available should + be focused on those sources that refer to the + technologies used in the development of the product from + which the TOE is derived. The extensiveness of this + search should consider the following factors: TOE type, + evaluator experience in this TOE type, expected attack + potential and the level of + evidence available. + + The identification process is iterative, where the + identification of one potential vulnerability may lead + to identifying another area of concern that requires + further investigation. + + The evaluator will describe the approach to be taken to + identify potential vulnerabilities in the publicly + available material, detailing the search to be + performed. This may be driven by factors such as areas + of concern identified by the evaluator, linked to the + evidence the attacker is assumed to be able to obtain. + However, it is recognised that in this type of search + the approach may further evolve as a result of findings + during the search. Therefore, the evaluator will also + report any actions taken in addition to those described + in the approach to further investigate issues thought to + lead to potential vulnerabilities, and will report the + evidence examined in completing the search for potential + vulnerabilities. + + + + The evaluator shall perform an independent, methodical + vulnerability analysis of the TOE using the guidance + documentation, functional specification, TOE design, + security architecture description and implementation + representation to identify potential vulnerabilities in the + TOE. + + + The evaluator shall conduct a methodical analysis of ST, + guidance documentation, functional specification, TOE + design, security architecture description and + implementation representation to identify possible + potential vulnerabilities in the TOE. + + Guidance on methodical vulnerability analysis is + provided in Annex . + + This approach to identification of potential + vulnerabilities is to take an ordered and planned + approach. A system is to be applied in the + examination. The evaluator is to describe the method to + be used in terms of the manner in which this information + is to be considered and the hypothesis that is to be + created. + + A flaw hypothesis methodology needs to be used whereby the ST, + development (functional specification, TOE design and + implementation representation) and guidance evidence are + analysed and then vulnerabilities in the TOE are hypothesised, + or speculated. + + The evaluator uses the knowledge of the TOE design and operation + gained from the TOE deliverables to conduct a flaw hypothesis to + identify potential flaws in the development of the TOE and + potential errors in the specified method of operation of the + TOE. + + The security architecture description provides the developer + vulnerability analysis, as it documents how the TSF protects + itself from interference from untrusted subjects and prevents + the bypass of security enforcement functionality. Therefore, the + evaluator should build upon the understanding of the TSF + protection gained from the analysis of this evidence and then + develop this in the knowledge gained from other development + evidence. + + The approach taken to the methodical search for vulnerabilities + is to consider any areas of concern identified in the results of + the evaluator's assessment of the development and guidance + evidence. However, the evaluator should also consider each + aspect of the security architecture analysis to search for any + ways in which the protection of the TSF can be undermined. It + may be helpful to structure the methodical analysis on the basis + of the material presented in the security architecture + description, introducing concerns from other evidence as appropriate. The analysis can then be + further developed to ensure all other material from the evidence is considered. + + The following provide some examples of hypotheses that + may be created when examining the evidence: + + + consideration of malformed input for interfaces + available to an attacker at the external interfaces; + + + examination of a key security mechanism cited in the + security architecture description, such as process + separation, hypothesising internal buffer overflows + that may lead to degradation of separation; + + + search to identify any objects created in the TOE + implementation representation that are then not + fully controlled by the TSF, and could be used by an + attacker to undermine SFRs. + + + + For example, the evaluator may identify that interfaces + are a potential area of weakness in the TOE and specify + an approach to the search that 'all interface + specifications in the evidence provided will be searched + to hypothesise potential vulnerabilities' and go on to + explain the methods used in the hypothesis. + + In addition, areas of concern the evaluator has identified + during examination of the evidence during the conduct of + evaluation activities. Areas of concern may also be identified + during the conduct of other work units associated with this + component, in particular , + and where the development and conduct of penetration + tests may identify further areas of concerns for investigation, + or potential vulnerabilities. + + However, examination of only a subset of the development + and guidance evidence or their contents is not permitted + in this level of rigour. The approach description should + provide a demonstration that the methodical approach + used is complete, providing confidence that the approach + used to search the deliverables has considered all of + the information provided in those deliverables. + + This approach to identification of potential vulnerabilities is + to take an ordered and planned approach; applying a system to + the examination. The evaluator is to describe the method to be + used in terms of how the evidence will be considered; the manner + in which this information is to be considered and the hypothesis + that is to be created. This approach should be agreed with the + evaluation authority, and the evaluation authority may + provide detail of any additional approaches the evaluator should + take to the vulnerability analysis and identify any additional + information that should be considered by the evaluator. + + Although a system to identifying potential + vulnerabilities is predefined, the identification + process may still be iterative, where the identification + of one potential vulnerability may lead to identifying + another area of concern that requires further + investigation. + + Subject to the SFRs the TOE is to meet in the + operational environment, the evaluator's independent + vulnerability analysis should consider generic potential + vulnerabilities under each of the following headings: + + + generic potential vulnerabilities relevant for the + type of TOE being evaluated, as may be supplied by + the evaluation authority; + + bypassing; + + tampering; + + direct attacks; + + monitoring; + + misuse. + + Items b) - f) are explained in greater detail in . + + The security architecture description should be + considered in light of each of the above generic + potential vulnerabilities. Each potential vulnerability + should be considered to search for possible ways in + which to defeat the TSF protection and undermine the + TSF. + + + + The evaluator shall record in the ETR the identified + potential vulnerabilities that are candidates for + testing and applicable to the TOE in its operational + environment. + + It may be identified that no further consideration of + the potential vulnerability is required if for example + the evaluator identifies that measures in the + operational environment, either IT or non-IT, prevent + exploitation of the potential vulnerability in that + operational environment. For instance, restricting + physical access to the TOE to authorised users only may + effectively render a potential vulnerability to + tampering unexploitable. + + The evaluator records any reasons for exclusion of + potential vulnerabilities from further consideration if + the evaluator determines that the potential + vulnerability is not applicable in the operational + environment. Otherwise the evaluator records the + potential vulnerability for further + consideration. + + A list of potential vulnerabilities applicable to the + TOE in its operational environment, which can be used as + an input into penetration testing activities, shall be + reported in the ETR by the evaluators. + + + + The evaluator shall conduct penetration testing based on the + identified potential vulnerabilities to determine that the + TOE is resistant to attacks performed by an attacker + possessing Moderate attack potential. + + + The evaluator shall devise penetration tests, based on + the independent search for potential + vulnerabilities. + + The evaluator prepares for penetration testing as necessary to + determine the susceptibility of the TOE, in its operational + environment, to the potential vulnerabilities identified during + the search of the sources of information publicly available. + Any current information provided to the evaluator by a third + party (e.g. evaluation authority) regarding known potential + vulnerabilities will be considered by the evaluator, together + with any encountered potential vulnerabilities resulting from + the performance of other evaluation activities. + + The evaluator is reminded that, as for considering the + security architecture description in the search for + vulnerabilities (as detailed in ), testing should be performed to confirm the + architectural properties. If requirements from are included in the SARs, the + developer testing evidence will include testing + performed to confirm the correct implementation of any + specific mechanisms detailed in the security + architecture description. However, the developer testing + will not necessarily include testing of all aspects of + the architectural properties that protect the TSF, as + much of this testing will be negative testing in nature, + attempting to disprove the properties. In developing the + strategy for penetration testing, the evaluator will + ensure that all aspects of the security architecture + description are tested, either in functional testing (as + considered in ) or evaluator + penetration testing. + + The evaluator will probably find it practical to carry + out penetration test using a series of test cases, where + each test case will test for a specific potential + vulnerability. + + The evaluator is not expected to test for potential + vulnerabilities (including those in the public domain) + beyond those which required a Moderate attack + potential. In some cases, however, it will be necessary + to carry out a test before the exploitability can be + determined. Where, as a result of evaluation expertise, + the evaluator discovers an exploitable vulnerability + that is beyond Moderate attack potential, this is + reported in the ETR as a residual vulnerability. + + Guidance on determining the necessary attack potential + to exploit a potential vulnerability can be found in + Annex . + + Potential vulnerabilities hypothesised as exploitable by + an attacker possessing a Moderate (or less) attack + potential and resulting in a violation of the security + objectives should be the highest priority potential + vulnerabilities comprising the list used to direct + penetration testing against the TOE. + + + + The evaluator shall produce penetration test + documentation for the tests based on the list of + potential vulnerabilities in sufficient detail to enable + the tests to be repeatable. The test documentation shall + include: + + + identification of the potential vulnerability the + TOE is being tested for; + + + instructions to connect and setup all required test + equipment as required to conduct the penetration + test; + + + instructions to establish all penetration test + prerequisite initial conditions; + + + instructions to stimulate the TSF; + + + instructions for observing the behaviour of the TSF; + + + descriptions of all expected results and the + necessary analysis to be performed on the observed + behaviour for comparison against expected results; + + + instructions to conclude the test and establish the + necessary post-test state for the TOE. + + + + The evaluator prepares for penetration testing based on + the list of potential vulnerabilities identified during + the search of the public domain and the analysis of the + evaluation evidence. + + The evaluator is not expected to determine the + exploitability for potential vulnerabilities beyond + those for which a Moderate attack potential is required + to effect an attack. However, as a result of evaluation + expertise, the evaluator may discover a potential + vulnerability that is exploitable only by an attacker + with greater than Moderate attack potential. Such + vulnerabilities are to be reported in the ETR as + residual vulnerabilities. + + With an understanding of the potential vulnerability, + the evaluator determines the most feasible way to test + for the TOE's susceptibility. Specifically the evaluator + considers: + + + the TSFI or other TOE interface that will be used to + stimulate the TSF and observe responses (It is + possible that the evaluator will need to use an + interface to the TOE other than the TSFI to + demonstrate properties of the TSF such as those + described in the security architecture description + (as required by ). It + should the noted, that although these TOE interfaces + provide a means of testing the TSF properties, they + are not the subject of the test.); + + + initial conditions that will need to exist for the + test (i.e. any particular objects or subjects that + will need to exist and security attributes they will + need to have); + + + special test equipment that will be required to + either stimulate a TSFI or make observations of a + TSFI; + + + whether theoretical analysis should replace physical + testing, particularly relevant where the results of + an initial test can be extrapolated to demonstrate + that repeated attempts of an attack are likely to + succeed after a given number of attempts. + + + + The evaluator will probably find it practical to carry + out penetration testing using a series of test cases, + where each test case will test for a specific potential + vulnerability. + + The intent of specifying this level of detail in the + test documentation is to allow another evaluator to + repeat the tests and obtain an equivalent result. + + + + The evaluator shall conduct penetration testing. + + The evaluator uses the penetration test documentation + resulting from work unit as a basis for executing penetration tests + on the TOE, but this does not preclude the evaluator + from performing additional ad hoc penetration tests. If + required, the evaluator may devise ad hoc tests as a + result of information learnt during penetration testing + that, if performed by the evaluator, are to be recorded + in the penetration test documentation. Such tests may be + required to follow up unexpected results or + observations, or to investigate potential + vulnerabilities suggested to the evaluator during the + pre-planned testing. + + Should penetration testing show that a hypothesised + potential vulnerability does not exist, then the + evaluator should determine whether or not the + evaluator's own analysis was incorrect, or if evaluation + deliverables are incorrect or incomplete. + + The evaluator is not expected to test for potential + vulnerabilities (including those in the public domain) + beyond those which required a Moderate attack + potential. In some cases, however, it will be necessary + to carry out a test before the exploitability can be + determined. Where, as a result of evaluation expertise, + the evaluator discovers an exploitable vulnerability + that is beyond Moderate attack potential, this is + reported in the ETR as a residual vulnerability. + + + + The evaluator shall record the actual results of the + penetration tests. + + While some specific details of the actual test results + may be different from those expected (e.g. time and date + fields in an audit record) the overall result should be + identical. Any unexpected test results should be + investigated. The impact on the evaluation should be + stated and justified. + + + + The evaluator shall report in the ETR the evaluator + penetration testing effort, outlining the testing + approach, configuration, depth and results. + + The penetration testing information reported in the ETR + allows the evaluator to convey the overall penetration + testing approach and effort expended on this + sub-activity. The intent of providing this information + is to give a meaningful overview of the evaluator's + penetration testing effort. It is not intended that the + information regarding penetration testing in the ETR be + an exact reproduction of specific test steps or results + of individual penetration tests. The intention is to + provide enough detail to allow other evaluators and + evaluation authorities to gain some insight about the + penetration testing approach chosen, amount of + penetration testing performed, TOE test configurations, + and the overall results of the penetration testing + activity. + + Information that would typically be found in the ETR + subclause regarding evaluator penetration testing efforts + is: + + + TOE test configurations. The particular + configurations of the TOE that were penetration + tested; + + + TSFI penetration tested. A brief listing of the TSFI + and other TOE interfaces that were the focus of the + penetration testing; + + + Verdict for the sub-activity. The overall judgement + on the results of penetration testing. + + + + This list is by no means exhaustive and is only intended + to provide some context as to the type of information + that should be present in the ETR concerning the + penetration testing the evaluator performed during the + evaluation. + + + + The evaluator shall examine the results of all + penetration testing to determine that the TOE, in its + operational environment, is resistant to an attacker + possessing a Moderate attack potential. + + If the results reveal that the TOE, in its operational + environment, has vulnerabilities exploitable by an + attacker possessing less than a High attack potential, + then this evaluator action fails. + + The guidance in should be used to determine the attack + potential required to exploit a particular vulnerability + and whether it can therefore be exploited in the + intended environment. It may not be necessary for the + attack potential to be calculated in every instance, + only if there is some doubt as to whether or not the + vulnerability can be exploited by an attacker possessing + an attack potential less than High. + + + + The evaluator shall report in the ETR all exploitable + vulnerabilities and residual vulnerabilities, detailing + for each: + + + its source (e.g. CEM activity being undertaken when + it was conceived, known to the evaluator, read in a + publication); + + + the SFR(s) not met; + + + a description; + + + whether it is exploitable in its operational + environment or not (i.e. exploitable or residual). + + + the amount of time, level of expertise, level of + knowledge of the TOE, level of opportunity and the + equipment required to perform the identified + vulnerabilities, and the corresponding values using + the tables and + of Annex . + + + + + + + + + + + + + + + + A methodical vulnerability analysis is performed by the + evaluator to ascertain the presence of potential + vulnerabilities. + + The evaluator performs penetration testing, to confirm + that the potential vulnerabilities cannot be exploited in + the operational environment for the TOE. Penetration + testing is performed by the evaluator assuming an attack + potential of High. + + + + The objective of this sub-activity is to determine whether + the TOE, in its operational environment, has + vulnerabilities exploitable by attackers possessing High + attack potential. + + + + The methodical analysis approach takes the form of a + structured examination of the evidence. This method + requires the evaluator to specify the structure and form + the analysis will take (i.e. the manner in which the + analysis is performed is predetermined, unlike the focused + analysis). The method is specified in terms of the + information that will be considered and how/why it will be + considered. Further guidance on methodical vulnerability + analysis can be found in Annex . + + If the TOE SFRs include and + requirements such that + actions and data of one subject cannot be observed and + linked with another subject, the evaluator should consider + performing a covert channel analysis. This will build + upon the design evidence provided by the developer in + satisfaction of and requirements. The design evidence + will include details of how the TOE architecture prevents + observation by subjects of actions performed by other + subjects. the evaluator should seek guidance from the + evaluation authority on the conduct of such a covert + channel analysis. + + The analysis of the guidance documentation is to include + consideration of whether it is possible to unknowingly + configure the TOE insecurely. Therefore, the analysis will + consider warning prompts provided by the TOE when + configuration options are selected by the user that may + render the TOE in an insecure state, not just in the + guidance but also in the use of the TOE. An example may be + when access control rules are amended from a remote + administration console, which will not take effect until + the TOE has been restarted. The evaluator will determine + whether the TOE issues a suitable warning when the changes + are made to ensure the user is aware that a restart must + be completed before the changes take effect. + + + + The evaluation evidence for this sub-activity is: + + + the ST; + + the functional specification; + + the TOE design; + + the security architecture description; + + the implementation representation; + + the guidance documentation; + + the TOE suitable for testing; + + information publicly available to support the + identification of possible potential + vulnerabilities. + + The remaining implicit evaluation evidence for this + sub-activity depends on the components that have been + included in the assurance package. The evidence provided + for each component is to be used as input in this + sub-activity. + + Other input for this sub-activity is: + + + current information regarding public domain potential + vulnerabilities and attacks (e.g. from an evaluation + authority). + + + + + The developer shall provide the TOE for testing. + + + The TOE shall be suitable for testing. + + + The evaluator shall confirm that the information provided + meets all requirements for content and presentation of + evidence. + + + The evaluator shall perform a search of public domain + sources to identify potential vulnerabilities in the TOE. + + + The evaluator shall perform an independent, methodical + vulnerability analysis of the TOE using the guidance + documentation, functional specification, TOE design, + security architecture description and implementation + representation to identify potential vulnerabilities in the + TOE. + + + The evaluator shall conduct penetration testing based on the + identified potential vulnerabilities to determine that the + TOE is resistant to attacks performed by an attacker + possessing High attack potential. + + + + + + + + EAL1 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. + + EAL1 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. + + EAL1 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 EAL1 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. + + + + EAL1 provides a basic level of assurance by a limited security + target and an analysis of the SFRs in that ST using a + functional and interface specification and guidance + documentation, to understand the security behaviour. + + The analysis is supported by a search for potential + vulnerabilities in the public domain and independent testing + (functional and penetration) of the TSF. + + EAL1 also provides assurance through unique identification of + the TOE and of the relevant evaluation documents. + + This EAL provides a meaningful increase in assurance over + unevaluated IT. + + + + + + + + + + + + + + + + + + + EAL2 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. + + EAL2 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. + + + + EAL2 provides assurance by a full security target and an + analysis of the SFRs in that ST, using a functional and + interface specification, guidance documentation and a basic + description of the architecture of the TOE, to understand the + security behaviour. + + The analysis is supported by independent testing of the TSF, + evidence of developer testing based on the functional + specification, selective independent confirmation of the + developer test results, and a vulnerability analysis (based + upon the functional specification, TOE design, security architecture + description and guidance evidence provided) demonstrating + resistance to penetration attackers with a basic attack + potential. + + EAL2 also provides assurance through use of a configuration + management system and evidence of secure delivery + procedures. + + This EAL represents a meaningful increase in assurance from + EAL1 by requiring developer testing, a vulnerability analysis + (in addition to the search of the public domain), and + independent testing based upon more detailed TOE + specifications. + + + + + + + + + + + + + + + + + + + + + + + + + EAL3 permits a conscientious developer to gain maximum + assurance from positive security engineering at the design + stage without substantial alteration of existing sound + development practises. + + EAL3 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. + + + + EAL3 provides assurance by a full security target and an + analysis of the SFRs in that ST, using a functional and + interface specification, guidance documentation, and an + architectural description of the design of the TOE, to + understand the security behaviour. + + The analysis is supported by independent testing of the TSF, + evidence of developer testing based on the functional + specification and TOE design, selective independent + confirmation of the developer test results, and a + vulnerability analysis (based upon the functional + specification, TOE design, security architecture description and guidance + evidence provided) demonstrating resistance to penetration + attackers with a basic attack potential. + + EAL3 also provides assurance through the use of development + environment controls, TOE configuration management, and + evidence of secure delivery procedures. + + This EAL represents a meaningful increase in assurance from + EAL2 by requiring more complete testing coverage of the + security functionality and mechanisms and/or procedures that + provide some confidence that the TOE will not be tampered with + during development. + + + + + + + + + + + + + + + + + + + + + + + + + + + + EAL4 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. EAL4 is the highest level at which it is likely to + be economically feasible to retrofit to an existing product + line. + + EAL4 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. + + + + EAL4 provides assurance by a full security target and an + analysis of the SFRs in that ST, using a functional and + complete interface specification, guidance documentation, a + description of the basic modular design of the TOE, and a + subset of the implementation, to understand the security + behaviour. + + The analysis is supported by independent testing of the TSF, + evidence of developer testing based on the functional + specification and TOE design, selective independent confirmation + of the developer test results, and a vulnerability analysis (based upon + the functional specification, TOE design, implementation + representation, security architecture description and guidance + evidence provided) demonstrating resistance to penetration + attackers with an Enhanced-Basic attack potential. + + EAL4 also provides assurance through the use of development + environment controls and additional TOE configuration + management including automation, and evidence of secure + delivery procedures. + + This EAL represents a meaningful increase in assurance from EAL3 + by requiring more design description, the implementation + representation for the entire TSF, and improved mechanisms + and/or procedures that provide confidence that the TOE will not + be tampered with during development. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + EAL5 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 EAL5 assurance. It is likely that the additional + costs attributable to the EAL5 requirements, relative to + rigorous development without the application of specialised + techniques, will not be large. + + EAL5 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. + + + + EAL5 provides assurance by a full security target and an + analysis of the SFRs in that ST, using a functional and + complete interface specification, guidance documentation, a + description of the design of the TOE, and the implementation, + to understand the security behaviour. A modular TSF design is + also required. + + The analysis is supported by independent testing of the TSF, + evidence of developer testing based on the functional + specification, TOE design, selective independent confirmation + of the developer test results, and an independent + vulnerability analysis demonstrating resistance to penetration + attackers with a moderate attack potential. + + EAL5 also provides assurance through the use of a development + environment controls, and comprehensive TOE configuration + management including automation, and evidence of secure + delivery procedures. + + This EAL represents a meaningful increase in assurance from EAL4 + by requiring semiformal design descriptions, a more structured + (and hence analysable) architecture, and improved mechanisms + and/or procedures that provide confidence that the TOE will not + be tampered with during development. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + EAL6 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. + + EAL6 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. + + + + EAL6 provides assurance by a full security target and an + analysis of the SFRs in that ST, using a functional and + complete interface specification, guidance documentation, the + design of the TOE, and the implementation to understand the + security behaviour. Assurance is additionally gained through a + formal model of select TOE security policies and a semiformal + presentation of the functional specification and TOE design. A + modular, layered and simple TSF design is also required. + + The analysis is supported by independent testing of the TSF, + evidence of developer testing based on the functional + specification, TOE design, selective independent confirmation + of the developer test results, and an independent + vulnerability analysis demonstrating resistance to penetration + attackers with a high attack potential. + + EAL6 also provides assurance through the use of a structured + development process, development environment controls, and + comprehensive TOE configuration management including complete + automation, and evidence of secure delivery procedures. + + This EAL represents a meaningful increase in assurance from + EAL5 by requiring more comprehensive analysis, a structured + representation of the implementation, more architectural + structure (e.g. layering), more comprehensive independent + vulnerability analysis, and improved configuration management + and development environment controls. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + EAL7 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 EAL7 is currently limited to TOEs with tightly + focused security functionality that is amenable to extensive + formal analysis. + + + + EAL7 provides assurance by a full security target and an + analysis of the SFRs in that ST, using a functional and + complete interface specification, guidance documentation, the + design of the TOE, and a structured presentation of the + implementation to understand the security behaviour. Assurance + is additionally gained through a formal model of select TOE + security policies and a semiformal presentation of the + functional specification and TOE design. A modular, layered + and simple TSF design is also required. + + The analysis is supported by independent testing of the TSF, + evidence of developer testing based on the functional + specification, TOE design and implementation representation, + complete independent confirmation of the developer test + results, and an independent vulnerability analysis + demonstrating resistance to penetration attackers with a high + attack potential. + + EAL7 also provides assurance through the use of a structured + development process, development environment controls, and + comprehensive TOE configuration management including complete + automation, and evidence of secure delivery procedures. + + This EAL represents a meaningful increase in assurance from + EAL6 by requiring more comprehensive analysis using formal + representations and formal correspondence, and comprehensive + testing. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + CAP-A is applicable when a composed TOE is integrated and + confidence in the correct security operation of the resulting + composite is required. This requires the cooperation of the + developer of the dependent component in terms of delivery of + design information and test results from the dependent + component certification, without requiring the involvement of + the base component developer. + + CAP-A 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. + + + + CAP-A provides assurance by analysis of a security target for + the composed TOE. The SFRs in the composed TOE ST are + analysed using the outputs from the evaluations of the + component TOEs (e.g. ST, guidance documentation) and a + specification for the interfaces between the component TOEs in + the composed TOE to understand the security behaviour. + + The analysis is supported by independent testing of the + interfaces of the base component that are relied upon by the + dependent component, as described in the reliance information, + evidence of developer testing based on the reliance + information, development information and composition + rationale, and selective independent confirmation of the + developer test results. The analysis is also supported by a + vulnerability review of the composed TOE by the + evaluator. + + CAP-A also provides assurance through unique identification of + the composed TOE (i.e. IT TOE and guidance + documentation). + + + + + + + + + + + + + + + + + + + + + CAP-B permits a conscientious developer to gain maximum + assurance from understanding, at a subsystem level, the + affects of interactions between component TOEs integrated in + the composed TOE, whilst minimising the demand of involvement + of the base component developer. + + CAP-B is applicable in those circumstances where developers or + users require a moderate level of independently assured + security, and require a thorough investigation of the composed + TOE and its development without substantial + re-engineering. + + + + CAP-B provides assurance by analysis of a full security target + for the composed TOE. The SFRs in the composed TOE ST are + analysed using the outputs from the evaluations of the + component TOEs (e.g. ST, guidance documentation), a + specification for the interfaces between the component TOEs + and the TOE design (describing TSF subsystems) contained in + the composed development information to understand the + security behaviour. + + The analysis is supported by independent testing of the + interfaces of the base component that are relied upon by the + dependent component, as described in the reliance information + (now also including TOE design), evidence of developer testing + based on the reliance information, development information and + composition rationale, and selective independent confirmation + of the developer test results. The analysis is also supported + by a vulnerability analysis of the composed TOE by the + evaluator demonstrating resistance to attackers with basic + attack potential. + + This CAP represents a meaningful increase in assurance from + CAP-A by requiring more complete testing coverage of the + security functionality. + + + + + + + + + + + + + + + + + + + + + + CAP-C permits a developer to gain maximum assurance from + positive analysis of the interactions between the components + of the composed TOE, which, though rigorous, do not require + full access to all evaluation evidence of the base + component. + + CAP-C is therefore applicable in those circumstances where + developers or users require a moderate to high level of + independently assured security in conventional commodity + composed TOEs and are prepared to incur additional + security-specific engineering costs. + + + + CAP-C provides assurance by analysis of a full security target + for the composed TOE. The SFRs in the composed TOE ST are + analysed using the outputs from the evaluations of the + component TOEs (e.g. ST, guidance documentation), a + specification for the interfaces between the component TOEs + and the TOE design (describing TSF modules) contained in the + composed development information to understand the security + behaviour. + + The analysis is supported by independent testing of the + interfaces of the base component that are relied upon by the + dependent component, as described in the reliance information + (now including TOE design), evidence of developer testing based + on the reliance information, development information and + composition rationale, and selective independent confirmation of + the developer test results. The analysis is also supported by a + vulnerability analysis of the composed TOE by the evaluator + demonstrating resistance to attackers with Enhanced-Basic attack + potential. + + This CAP represents a meaningful increase in assurance from + CAP-B by requiring more design description and demonstration + of resistance to a higher attack potential. + + + + + + + + + + + + + + + + + + + + diff --git a/input/esr.xml b/input/esr.xml new file mode 100644 index 0000000..da5837d --- /dev/null +++ b/input/esr.xml @@ -0,0 +1,505 @@ + + + + + + + Application Software Essential Security Requirements + National Information Assurance Partnership (NIAP) + 42 + 1.0 + draft + 29 Aug 2015 + + none + + +
+ The following is an Essential Security Requirements (ESR) document + for application software. + The creation of an ESR is a necessary + prerequisite to develop an Application Software cPP, and this + document represents material provided by NIAP for that purpose. +
+ +
+ + This document describes a core set of security requirements + for application software. These requirements cover basic security behavior for + application software. Evaluation against the resulting Protection Profile + ensures that this fundamental set of requirements is met. These fundamental + requirements must be extended to adequately cover the functionality of many + types of applications. + This is not a declaration that all software should be evaluated through the + Common Criteria. Although it depends on the national market, Common Criteria + evaluation generally focuses on providing assurance for products which provide security + functionality. Many applications without security functionality, particularly on + mobile platforms, now receive some type of evaluation (often called vetting). + This occurs because software without + security functionality, when flawed, has security consequences. + This document is offered as a reference for those activities, in addition to + its role in the Common Criteria. + The goal is to establish a consistent set of expectations for all application software + developers, independent of the evaluation methodology. + +

+ The vast majority of application software should satisfy + this core set of requirements, yet a very small set of extremely specialized + software may not do so. The requirements for such exceptional software + may be specified in Protection Profiles which do not extend the requirements + described here. +

+ Application software in the context of this document is software that runs on + a platform and performs tasks on behalf of the user or owner of the + system. The platform for the application is an operating system, an execution + environment, or some combination of these. +

+

+ +
+ + Application software is used in innumerable specific use cases. +

+ However, in formal Common Criteria evaluations we seek evaluation only of applications + which provide security functionality (which are called IA or IA-enabled in + some markets). Such applications include thin clients and host-based security agents. + Other applications will be covered by Extended Packages of the + resulting Protection Profile (email client, web browser, VPN client, MDM agent). + + +

+ +
+ +

+

    +
  • + Sensitive data in transit. +
    • +
  • + Sensitive data stored locally by the application. +
    • +
  • + Application code and configuration parameters. +
    • +
+ The application should also not require security features in the + platform be disabled, as this weakens the underlying platform. +

+
+ +
+
    +
  • + An attacker is assumed to attempt attacks from the following + vantage points: +
      +
    • + The network across which the application engages + in communication, both actively and passively. +
      • +
    • + The platform on which the application is + installed, though as an unprivileged subject. +
      • +
    +
    • +
  • + An attacker has an arbitrary amount of time to analyze the + behavior of the application, its interaction with its host + device or platform, and/or the data it transmits over the + network. +
    • +
+
+ +
+
    +
  • + The application consists of the software + provided by its vendor. + Any software in the application + installation package is potentially in scope + during evaluation. This includes those pieces that may + extend the functionality of the underlying + platform, such as kernel drivers. The + application exists both as an object that is + stored on the file system of the host platform + as well as a runtime object that exists during + its execution. The application + code may execute directly on a microprocessor, + or it may be script or bytecode interpreted by + a runtime environment. +
    • +
  • + Shared libraries (static or dynamically loaded) + from third parties that convey with the + application are also in scope. +
    • +
+
+ +
+ +

+ Functionality-related requirements are: +

    +
  • + Limit network connectivity to necessary communications, and + encrypt sensitive data that is transmitted remotely + using a trusted communications channel. +
    • +
  • + Leverage the platform to protect any + sensitive data at rest stored in non-volatile memory, such + as credentials. +
    • +
  • + Require initial assignment of credentials by the end user whenever the + application is shipped with default credentials or no credentials. +
    • +
  • + Restrict access to those platform resources which are necessary to achieve + its stated functionality. +
    • +
  • + Properly implement, or leverage the platform, for cryptographic operations such as + key generation, encryption and decryption, random bit generation, hashing, signing, + and keyed-hash message authentication. +
    • +
  • + Leverage the platform's exploit mitigation features, and never engage + in behavior that undermines the platform's security features. +
    • + + +
  • + Be distributed only in the format supported by the + platform's package manager, and ensure trusted update. +
    • +
+ Assurance-related requirements are: +
    +
  • + Timely patching of any publicly-disclosed vulnerabilities, + including those in 3rd party components that convey with the + application. +
    • +
  • + Use of anti-exploitation options provided in the development + toolchain. +
    • +
+
+ +
+ + +
    +
  • + The application relies upon a trustworthy computing platform + for its execution. This includes the underlying platform and + whatever runtime environment it provides to the application. +
    • +
  • + The user of the application software is not willfully negligent + or hostile, and uses the software in compliance with the + applied enterprise security policy. +
    • +
  • + The administrator of the underlying platform or application software is not careless, + willfully negligent or hostile, and administers the software + within compliance of the approved enterprise security policy. +
    • +
+
+ +
+ +
    +
  • + Client authentication to remote + peers using X.509v3 certificates. +
    • +
+ +
+ +
+ +
    + +
  • + Use of Software ID (SWID) tags to enable software inventory + as defined by ISO/IEC 19770-2:2009. +
    • +
+
+ +
+ +
    +
  • + The hardware or firmware of the underlying platform. +
    • +
  • + The host operating system or runtime environment on which the + application executes. +
    • +
  • + Specific functional behavior that is not global to all + applications. +
    • +
+
+ diff --git a/input/tds/README.md b/input/tds/README.md new file mode 100644 index 0000000..04e1b77 --- /dev/null +++ b/input/tds/README.md @@ -0,0 +1,9 @@ +# TDs README + +This is the TD directory. +For a release branch, authors should create XML representations for all TDs issued for this version of the PP document. +Eventually these TD files should be pulled into the development branch, usually the 'master' branch. +Once they get pulled into the master branch, they should be manually incoporated into the main XML input document and then deleted from the master branch. + + + diff --git a/output/images/appdiagram.png b/output/images/appdiagram.png new file mode 100644 index 0000000..071d91d Binary files /dev/null and b/output/images/appdiagram.png differ diff --git a/output/images/cclogo.png b/output/images/cclogo.png new file mode 100644 index 0000000..8464869 Binary files /dev/null and b/output/images/cclogo.png differ diff --git a/output/images/collapsed.png b/output/images/collapsed.png new file mode 100644 index 0000000..dd0ea45 Binary files /dev/null and b/output/images/collapsed.png differ diff --git a/output/images/expanded.png b/output/images/expanded.png new file mode 100644 index 0000000..468b56d Binary files /dev/null and b/output/images/expanded.png differ diff --git a/output/images/niaplogo.png b/output/images/niaplogo.png new file mode 100644 index 0000000..2de1b05 Binary files /dev/null and b/output/images/niaplogo.png differ diff --git a/output/images/niaplogodraft.png b/output/images/niaplogodraft.png new file mode 100644 index 0000000..e56d71d Binary files /dev/null and b/output/images/niaplogodraft.png differ diff --git a/output/images/toe.png b/output/images/toe.png new file mode 100644 index 0000000..650a8e8 Binary files /dev/null and b/output/images/toe.png differ diff --git a/output/images/toeruntime.png b/output/images/toeruntime.png new file mode 100644 index 0000000..5079d4b Binary files /dev/null and b/output/images/toeruntime.png differ diff --git a/review_artifacts/agent-module-distributed-microservices-redline.docx b/review_artifacts/agent-module-distributed-microservices-redline.docx new file mode 100644 index 0000000..3f3018f Binary files /dev/null and b/review_artifacts/agent-module-distributed-microservices-redline.docx differ diff --git a/review_artifacts/application-v2-distributed-microservices-redline.docx b/review_artifacts/application-v2-distributed-microservices-redline.docx new file mode 100644 index 0000000..5c4c7f5 Binary files /dev/null and b/review_artifacts/application-v2-distributed-microservices-redline.docx differ diff --git a/review_artifacts/server-agent-configuration-distributed-microservices-redline.docx b/review_artifacts/server-agent-configuration-distributed-microservices-redline.docx new file mode 100644 index 0000000..45a3c3a Binary files /dev/null and b/review_artifacts/server-agent-configuration-distributed-microservices-redline.docx differ diff --git a/review_artifacts/server-module-distributed-microservices-redline.docx b/review_artifacts/server-module-distributed-microservices-redline.docx new file mode 100644 index 0000000..6ac0049 Binary files /dev/null and b/review_artifacts/server-module-distributed-microservices-redline.docx differ diff --git a/tools/html_to_review_adoc.py b/tools/html_to_review_adoc.py new file mode 100644 index 0000000..f376f1d --- /dev/null +++ b/tools/html_to_review_adoc.py @@ -0,0 +1,140 @@ +#!/usr/bin/env python3 +"""Create a readable AsciiDoc review draft from generated PP HTML.""" + +from __future__ import annotations + +import argparse +import re +from pathlib import Path + +from lxml import html + + +SKIP_TAGS = {"script", "style", "noscript"} + + +def clean(text: str) -> str: + text = text.replace("\xa0", " ") + text = re.sub(r"[ \t\r\f\v]+", " ", text) + text = re.sub(r"\n{3,}", "\n\n", text) + return text.strip() + + +def adoc_text(text: str) -> str: + text = clean(text) + if re.fullmatch(r"\[[^\]]+\]", text): + return "\\" + text + return text + + +def text_content(node) -> str: + return adoc_text(" ".join(node.itertext())) + + +def table_to_adoc(table) -> list[str]: + rows = [] + for tr in table.xpath("./tr|./thead/tr|./tbody/tr"): + cells = [text_content(cell) for cell in tr.xpath("./th|./td")] + if cells: + rows.append(cells) + if not rows: + return [] + + max_cols = max(len(row) for row in rows) + lines = ["[cols=\"{}*\",options=\"header\"]".format(max_cols), "|===",] + for row_index, row in enumerate(rows): + padded = row + [""] * (max_cols - len(row)) + for cell in padded: + lines.append("|" + cell.replace("\n", " +\n")) + if row_index == 0: + lines.append("") + lines.append("|===") + return lines + + +def list_to_adoc(node, ordered: bool = False) -> list[str]: + marker = "." if ordered else "*" + lines = [] + for li in node.xpath("./li"): + value = text_content(li) + if value: + lines.append(f"{marker} {value}") + return lines + + +def emit_block(node) -> list[str]: + tag = node.tag.lower() if isinstance(node.tag, str) else "" + if tag in SKIP_TAGS: + return [] + if tag in {"h1", "h2", "h3", "h4", "h5", "h6"}: + level = min(int(tag[1]) + 1, 6) + title = text_content(node) + if not title: + return [] + if title == getattr(node.getroottree(), "_review_title", None): + return [] + if title == "Contents": + return [] + return ["=" * level + " " + title] + if tag == "table": + return table_to_adoc(node) + if tag == "ul": + return list_to_adoc(node) + if tag == "ol": + return list_to_adoc(node, ordered=True) + if tag in {"p", "div", "section", "blockquote"}: + children = [child for child in node if isinstance(child.tag, str) and child.tag.lower() not in SKIP_TAGS] + child_tags = {child.tag.lower() for child in children} + if child_tags and child_tags <= {"h1", "h2", "h3", "h4", "h5", "h6", "table", "ul", "ol", "p", "div", "section"}: + lines: list[str] = [] + for child in children: + lines.extend(emit_block(child)) + if lines and lines[-1] != "": + lines.append("") + return lines + value = text_content(node) + return [value] if value else [] + value = text_content(node) + return [value] if value else [] + + +def convert(src: Path, dst: Path) -> None: + root = html.fromstring(src.read_bytes().decode("utf-8", errors="replace")) + body = root.find("body") + if body is None: + raise RuntimeError("HTML body not found") + + title = root.findtext(".//title") or "Application Software cPP Review Draft" + root.getroottree()._review_title = clean(title) + lines = [ + f"= {clean(title)}", + ":doctype: book", + ":toc: left", + ":toclevels: 4", + ":sectnums:", + ":icons: font", + ":source-highlighter: rouge", + ":pdf-page-size: Letter", + ":pdf-theme: default", + "", + ] + + for child in body: + block = emit_block(child) + if block: + lines.extend(block) + lines.append("") + + dst.write_text("\n".join(lines).replace("\n\n\n", "\n\n"), encoding="utf-8") + + +def main() -> None: + parser = argparse.ArgumentParser() + parser.add_argument("src", type=Path) + parser.add_argument("dst", type=Path) + args = parser.parse_args() + convert(args.src, args.dst) + + +if __name__ == "__main__": + main() diff --git a/tools/make_distributed_toe_redlines.py b/tools/make_distributed_toe_redlines.py new file mode 100644 index 0000000..d89175f --- /dev/null +++ b/tools/make_distributed_toe_redlines.py @@ -0,0 +1,367 @@ +from datetime import datetime, timezone +from pathlib import Path + +from docx import Document +from docx.enum.text import WD_COLOR_INDEX +from docx.oxml import OxmlElement +from docx.oxml.ns import qn +from docx.shared import Pt + + +OUT_DIR = Path("review_artifacts") +AUTHOR = "Codex draft" +STAMP = datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ") + + +def set_track_revisions(doc): + settings = doc.settings.element + track = settings.find(qn("w:trackRevisions")) + if track is None: + settings.append(OxmlElement("w:trackRevisions")) + + +def set_run_style(run): + run.font.name = "Aptos" + run.font.size = Pt(10) + + +def add_deleted(paragraph, text, change_id): + deleted = OxmlElement("w:del") + deleted.set(qn("w:id"), str(change_id)) + deleted.set(qn("w:author"), AUTHOR) + deleted.set(qn("w:date"), STAMP) + + run = OxmlElement("w:r") + props = OxmlElement("w:rPr") + color = OxmlElement("w:color") + color.set(qn("w:val"), "C00000") + strike = OxmlElement("w:strike") + props.append(color) + props.append(strike) + run.append(props) + del_text = OxmlElement("w:delText") + del_text.set(qn("xml:space"), "preserve") + del_text.text = text + run.append(del_text) + deleted.append(run) + paragraph._p.append(deleted) + + +def add_inserted(paragraph, text, change_id): + inserted = OxmlElement("w:ins") + inserted.set(qn("w:id"), str(change_id)) + inserted.set(qn("w:author"), AUTHOR) + inserted.set(qn("w:date"), STAMP) + + run = OxmlElement("w:r") + props = OxmlElement("w:rPr") + color = OxmlElement("w:color") + color.set(qn("w:val"), "0070C0") + underline = OxmlElement("w:u") + underline.set(qn("w:val"), "single") + props.append(color) + props.append(underline) + run.append(props) + ins_text = OxmlElement("w:t") + ins_text.set(qn("xml:space"), "preserve") + ins_text.text = text + run.append(ins_text) + inserted.append(run) + paragraph._p.append(inserted) + + +def add_review_paragraph(doc, parts, style=None): + p = doc.add_paragraph(style=style) + for mode, text in parts: + if mode == "normal": + run = p.add_run(text) + set_run_style(run) + elif mode == "delete": + add_deleted(p, text, add_review_paragraph.change_id) + add_review_paragraph.change_id += 1 + elif mode == "insert": + add_inserted(p, text, add_review_paragraph.change_id) + add_review_paragraph.change_id += 1 + else: + raise ValueError(mode) + return p + + +add_review_paragraph.change_id = 1 + + +def add_source_note(doc, source_path): + p = doc.add_paragraph() + run = p.add_run(f"Source file: {source_path}") + run.italic = True + run.font.size = Pt(9) + run.font.highlight_color = WD_COLOR_INDEX.GRAY_25 + + +def build_doc(filename, title, source_path, changes): + add_review_paragraph.change_id = 1 + doc = Document() + set_track_revisions(doc) + styles = doc.styles + styles["Normal"].font.name = "Aptos" + styles["Normal"].font.size = Pt(10) + doc.add_heading(title, level=1) + add_source_note(doc, source_path) + doc.add_paragraph( + "This review copy shows the proposed distributed TOE and microservices changes as tracked revisions. " + "Blue underlined text is inserted text; red strikethrough text is deleted text." + ) + for heading, paragraphs in changes: + doc.add_heading(heading, level=2) + for parts in paragraphs: + add_review_paragraph(doc, parts) + OUT_DIR.mkdir(exist_ok=True) + doc.save(OUT_DIR / filename) + + +def source_block_as_insertions(source_path, start_marker, end_marker): + text = Path(source_path).read_text(encoding="utf-8") + start = text.index(start_marker) + end = text.index(end_marker, start) + block = text[start:end].strip() + paragraphs = [] + for line in block.splitlines(): + if line.strip(): + paragraphs.append([("insert", line)]) + return paragraphs + + +base_changes = [ + ( + "New Section After Compliant TOE / Use Cases", + [ + [ + ("insert", "Distributed and Microservices TOE Architectures"), + ], + [ + ( + "insert", + "A TOE may consist of multiple separately deployed application components that collectively provide the TOE security functionality. Examples include server-agent products, clustered application deployments, and microservices-based applications composed of multiple application payloads. If a TOE is distributed across multiple TOE components, the ST shall identify each TOE component, describe the role of each TOE component, identify which components implement each claimed SFR, describe all communications between TOE components, and distinguish TOE components from operational environment components.", + ) + ], + [ + ( + "insert", + "For containerized or microservices TOEs, the TOE consists of the application payloads and TOE-provided application components identified in the ST. The container orchestration platform, container runtime, operating system, service mesh infrastructure, ingress infrastructure, cluster networking, and platform-provided secret or configuration stores are part of the operational environment unless explicitly included in the TOE boundary. The PP does not require these operational environment components to be included in the TOE boundary solely because the TOE depends on them for execution, scheduling, networking, isolation, credential storage, configuration storage, or time services.", + ) + ], + [ + ( + "insert", + "When the TOE relies on operational environment components to provide services used by the TOE, the ST shall identify the dependency and the guidance shall describe the required environmental configuration. Inter-component communication between TOE parts shall be identified in the ST. Where the TOE claims conformance to a PP-Configuration that includes Server and Agent application modules, the ST shall use the module requirements to address authorization or registration of TOE components before communication is permitted and protection of security-relevant data transmitted between TOE components. The ST shall provide an SFR allocation rationale that identifies whether each claimed requirement is satisfied by all TOE components, by applicable TOE components that perform the relevant function, by at least one TOE component, by the TOE as a whole, or by an allowed operational environment dependency.", + ) + ], + ], + ) +] + +server_changes = [ + ( + "TOE Overview", + [ + [ + ( + "normal", + "This is a Collaborative Protection Profile (cPP) Module whose Target of Evaluation (TOE) is Enterprise Server Applications. This PP-Module is compatible with the cPP for Application Software. ", + ) + ], + [ + ( + "insert", + "For a distributed TOE, the Server Application is the TOE component, or set of TOE components, that provides management, coordination, policy, API-facing, or other server-side functionality for the TOE. In a microservices architecture, a Server Application component may be a service or application payload that coordinates, exposes, or controls TOE functionality. The container orchestration platform, container runtime, operating system, service mesh infrastructure, ingress infrastructure, cluster networking, and platform-provided secret or configuration stores are part of the operational environment unless explicitly included in the TOE boundary.", + ) + ], + ], + ), + ( + "New Distributed/Microservices Section", + [ + [("insert", "Distributed and Microservices TOE Configurations")], + [ + ( + "insert", + "This PP-Module may be used in a PP-Configuration with the PP-Module for Agent Applications to evaluate distributed application software. Distributed application software includes server-agent deployments, clustered server deployments, and microservices architectures composed of multiple application payload components.", + ) + ], + [ + ( + "insert", + "For a distributed TOE, the ST shall identify each TOE component, describe the role of each TOE component, identify which components implement each claimed SFR, and describe all communications between TOE components. The ST shall also distinguish TOE components from operational environment components. Operational environment components may include container orchestration, container runtimes, operating systems, service mesh infrastructure, ingress infrastructure, cluster networking, platform-provided secret or configuration stores, and other infrastructure services not explicitly included in the TOE boundary.", + ) + ], + [ + ( + "insert", + "If the TOE relies on operational environment components for execution, scheduling, networking, isolation, credential storage, configuration storage, time services, or protection of inter-component communications, the ST shall identify the dependency and the guidance shall describe the required environmental configuration.", + ) + ], + ], + ), + ( + "SFR Applicability Updates", + [ + [ + ("normal", "These SFRs apply "), + ("delete", "if and only if an Agent Module is included in the evaluation."), + ( + "insert", + "when the TOE includes separately deployed TOE parts that communicate with one another as part of a PP-Configuration that includes the Agent Module. For microservices architectures, these SFRs apply to the communication relationships between Server Application components and Agent Application components as those components are identified in the ST. The ST author should iterate these SFRs as needed for different component pairs or communication mechanisms.", + ), + ], + [ + ("normal", "configuration of communication with "), + ("delete", "Agent"), + ("insert", "other TOE components"), + ("normal", " according to FCO_CPC_EXT.1/Server and FPT_ITT.1/Server"), + ], + ], + ), +] + +agent_changes = [ + ( + "TOE Overview", + [ + [ + ( + "normal", + "This is a Collaborative Protection Profile (cPP) Module whose Target of Evaluation (TOE) is Enterprise Agent Applications. This PP-Module is compatible with the cPP for Application Software and collaborative PP-Module for Server Applications. ", + ) + ], + [ + ( + "insert", + "For purposes of a PP-Configuration, an Agent Application is any separately deployed TOE application component that communicates with another TOE component under the control, coordination, policy, enrollment, or trust relationship established by the TOE. This may include endpoint agents, worker services, peer services, microservice payloads, subordinate application services, or other application components that are identified as TOE parts in the ST.", + ) + ], + [ + ( + "insert", + "For containerized or microservices TOEs, the TOE consists of the application payload components identified in the ST. The container orchestration platform, container runtime, operating system, service mesh infrastructure, ingress infrastructure, cluster networking, and platform-provided secret or configuration stores are part of the operational environment unless explicitly included in the TOE boundary.", + ) + ], + ], + ), + ( + "New Distributed/Microservices Section", + [ + [("insert", "Distributed and Microservices TOE Configurations")], + [ + ( + "insert", + "This PP-Module may be used in a PP-Configuration with the PP-Module for Server Applications to evaluate distributed application software. Distributed application software includes server-agent deployments, clustered server deployments, and microservices architectures composed of multiple application payload components.", + ) + ], + [ + ( + "insert", + "The ST shall identify each Agent Application component, describe the role of each component, identify which claimed SFRs are implemented by each component, and describe all communications between Agent Application components and other TOE components. The ST shall also distinguish TOE components from operational environment components. If the TOE relies on operational environment components for execution, scheduling, networking, isolation, credential storage, configuration storage, time services, or protection of inter-component communications, the ST shall identify the dependency and the guidance shall describe the required environmental configuration.", + ) + ], + ], + ), + ( + "FCO Application Note", + [ + [ + ("delete", "An Agent can communicate with a Server or another Agent."), + ( + "insert", + "An Agent can communicate with a Server, another Agent, or another separately deployed TOE component identified in the ST. In a microservices architecture, this may include communication between application payload services.", + ), + ("normal", " This SFR can be iterated if the registration method varies depending on what TOE parts are communicating."), + ] + ], + ), +] + +config_changes = [ + ( + "Title and Overview", + [ + [ + ("delete", "PP-Configuration for Enterprise Server Applications and Client Agent(s)"), + ("insert", "PP-Configuration for Enterprise Server Applications and Agent/Application Component(s)"), + ], + [ + ("normal", "This PP-Configuration is for enterprise server applications and their "), + ("delete", "client agent(s)."), + ( + "insert", + "agent or application component(s). It provides the enforceable PP-Configuration path for distributed application software, including server-agent deployments, clustered server deployments, and microservices architectures composed of multiple application payload components.", + ), + ], + ], + ), + ( + "New Distributed/Microservices Section", + [ + [("insert", "Distributed and Microservices TOE Architectures")], + [ + ( + "insert", + "For this PP-Configuration, a distributed TOE consists of multiple separately deployed application components that collectively provide the TOE security functionality. Each TOE component shall be identified in the ST and mapped to the base PP, Server Module, Agent Module, or a combination of those components, as applicable.", + ) + ], + [ + ( + "insert", + "For containerized or microservices TOEs, the TOE consists of the application payload components identified in the ST. The container orchestration platform, container runtime, operating system, service mesh infrastructure, ingress infrastructure, cluster networking, and platform-provided secret or configuration stores are part of the operational environment unless explicitly included in the TOE boundary.", + ) + ], + [ + ( + "insert", + "The ST shall provide an SFR allocation rationale that identifies whether each claimed requirement is satisfied by all TOE components, by applicable TOE components that perform the relevant function, by at least one TOE component, by the TOE as a whole, or by an allowed operational environment dependency. The ST shall describe all inter-component TOE communications and identify the mechanisms used to authorize and protect those communications.", + ) + ], + ], + ), +] + +config_changes.append( + ( + "SFR Allocation Tables", + source_block_as_insertions( + "Archive/Modules/Agent/appSW_PP_Config_ServerAgent.adoc", + "==== SFR Allocation for Distributed TOEs", + "\n== Conformance Claims", + ), + ) +) + + +def main(): + build_doc( + "application-v2-distributed-microservices-redline.docx", + "Application Software PP v2 Distributed/Microservices Redline", + "input/application.xml", + base_changes, + ) + build_doc( + "server-module-distributed-microservices-redline.docx", + "Server Module Distributed/Microservices Redline", + "Modules/Server/cPP_MOD-Server.adoc", + server_changes, + ) + build_doc( + "agent-module-distributed-microservices-redline.docx", + "Agent Module Distributed/Microservices Redline", + "Modules/Agent/cPP_MOD-Agent.adoc", + agent_changes, + ) + build_doc( + "server-agent-configuration-distributed-microservices-redline.docx", + "Server + Agent PP-Configuration Distributed/Microservices Redline", + "Modules/Agent/appSW_PP_Config_ServerAgent.adoc", + config_changes, + ) + + +if __name__ == "__main__": + main() diff --git a/transforms b/transforms new file mode 160000 index 0000000..813616b --- /dev/null +++ b/transforms @@ -0,0 +1 @@ +Subproject commit 813616b9c790f1a7f084fa9fbe8dfb472c6c8e67