diff --git a/.github/workflows/quick_build.yml b/.github/workflows/quick_build.yml index d5f255bb..b50ff66a 100644 --- a/.github/workflows/quick_build.yml +++ b/.github/workflows/quick_build.yml @@ -1,4 +1,4 @@ -name: QuickBuild +name: QuickBuild v4.4 on: push: @@ -18,82 +18,84 @@ jobs: name: Quick Build steps: - name: Checkout project and transforms - uses: actions/checkout@v2 + 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 xsltproc hunspell" + run: "sudo apt-get update && sudo apt-get install -y xsltproc hunspell python3-lxml" - name: Install Jing run: wget -O - https://github.com/relaxng/jing-trang/releases/download/V20181222/jing-20181222.zip | jar -x - # Get current banch name to use it as dest directory - - name: Extract branch name - id: extract_branch - shell: bash - run: echo "##[set-output name=branch;]$(echo ${GITHUB_REF#refs/heads/})" + - 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: | - pwd - WARN_PATH="output/SanityChecksOutput.md" make + 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 - if: ${{ github.ref_name != 'master' }} + if: ${{ env.action_is_release == 'YES' }} run: | sudo apt-get install -y wkhtmltopdf xvfb - xvfb-run --auto-servernum --server-args='-screen 0, 1024x768x16' /usr/bin/wkhtmltopdf \ - --javascript-delay 15000 --footer-right '[page]' \ - file://${PWD}/output/${PWD##*/}.html?expand=on \ - output/${PWD##*/}-paged.pdf + cd output + for aa in *.html; do + xvfb-run --auto-servernum --server-args='-screen 0, 1024x768x16' /usr/bin/wkhtmltopdf \ + --enable-local-file-access --javascript-delay 15000 --footer-right '[page]' \ + file://${PWD}/${aa}?expand=on ${aa}.pdf + done - id: validate run: | RNG_OUT="output/ValidationReport.txt" make validate || true - echo ::set-output name=VALERRORS::$(wc -l output/ValidationReport.txt | { read first rest ; echo $first ; } ) + - 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 - echo ::set-output name=LINES::$(wc -l output/SpellCheckReport.txt | { read first rest ; echo $first ; } ) - - id: tdate - run: | - echo "##[set-output name=TDATE;]$(cd transforms && git log -1 --format=%cs; cd -)" + - name: Set spellerrors + run: echo "action_spellerrors=$(wc -l output/SpellCheckReport.txt | { read first rest ; echo $first ; } )" >> $GITHUB_ENV - -# ======= -# echo "##[set-output name=TDATE;]$(cd transforms && git log -1 --format=%cs; cd -)" # - -# - name: Setup Java JDK -# uses: actions/setup-java@v1.4.3 -# with: -# java-version: 1.8 -# - 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: 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: Make tmp dir + run: mkdir tmp -# # - name: Diff against specified versions -# # run: DAISY_DIR=ExecuteDaisy-master make diff -# >>>>>>> release-3.2 - - name: diff - run: make diff || true; + 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: | @@ -103,163 +105,179 @@ jobs: ls input/tds/*.xml ; then echo "Master branch should not have TDs" >> output/TDValidationReport.txt fi - echo "##[set-output name=TDCOLOR;]$(if [ -s output/TDValidationReport.txt ]; then echo orange; else echo green; fi)" - echo "##[set-output name=TDWARNS;]$( wc -l output/TDValidationReport.txt | { read first rest ; echo $first;} )" - if ls input/tds/*.xml; then - PP_XML=output/effective.xml PP_RELEASE_HTML=output/AppliedTDs.html make release + 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 -# MDF can do -# java -jar ExecuteDaisy-master/*.jar output/*-release.html output/AppliedTDs.html --file=output/AppliedTDs-Diff.html - - - - name: Make a directory listing - run: > - cd output; - (echo "Listing"; - date; - echo "
    "; - for aa in $(find . -name '*.*'); do - echo "
  1. $aa
    2. "; - done; - echo "
") > index.html - cd - - - - name: Prepare environment - id: coverage + # Not sure what the point of this is + - name: Validate Effective run: | - # Generates a GitHub Workflow output named `lines` with a coverage value - echo "##[set-output name=spellcolor;]$(if [ 0 = ${{ steps.spellcheck.outputs.LINES }} ]; then echo green; else echo red; fi)" - echo "##[set-output name=valcolor;]$(if [ 0 = ${{ steps.validate.outputs.VALERRORS }} ]; then echo green; else echo red; fi)" + 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 - # Output values to be used by other steps - echo "##[set-output name=path;]${BADGE_PATH}" - echo "##[set-output name=branch;]${BRANCH}" - env: - BADGE_PATH: output/warnings-badge.svg - BRANCH: gh-pages - - name: Get Status + - name: Prepare environment run: | - echo ::set-output name=WORD::$(if [ -s output/SanityChecksOutput.md ]; then echo some; else echo none; fi ) - echo ::set-output name=COLOR::$(if [ -s output/SanityChecksOutput.md ]; then echo red; else echo green; fi ) - id: status - - # - uses: actions/checkout@v1 - # with: - # ref: ${{ steps.coverage.outputs.branch }} + # 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 + - # # Create the directory where badges will be saved, if needed - # - name: Create destination directory - # env: - # BADGE_PATH: ${{ steps.coverage.outputs.path }} - # run: mkdir -p "${BADGE_PATH%/*}" - # Use the output from the `coverage` step - name: Generate the spelling badge SVG image - uses: emibcn/badge-action@v1 + uses: emibcn/badge-action@v2.0.2 with: label: 'Misspellings' - status: ${{ steps.spellcheck.outputs.LINES }} - color: ${{ steps.coverage.outputs.spellcolor }} + status: ${{ env.action_spellerrors }} + color: ${{ env.action_spellcolor }} path: output/spell-badge.svg - - name: Generate the built branch SVG - uses: emibcn/badge-action@v1 + + + - name: Generate the validation badge SVG image + uses: emibcn/badge-action@v2.0.2 with: - label: 'Last Built' - status: ${{ steps.extract_branch.outputs.branch }} - color: black - path: "output/build-branch-badge.svg" - - - # - name: Upload badge as artifact - # uses: actions/upload-artifact@v2 - # with: - # name: badge - # path: build-branch-badge.svg - # if-no-files-found: error - - # Use the output from the `coverage` step - - name: Generate the badge SVG image - uses: emibcn/badge-action@v1 + 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: ${{ steps.status.outputs.WORD }} - color: ${{ steps.status.outputs.COLOR }} + status: ${{ env.action_sanitystatus }} + color: ${{ env.action_sanitycolor }} path: output/warnings.svg + - name: Generate the transforms badge - uses: emibcn/badge-action@v1 + uses: emibcn/badge-action@v2.0.2 with: label: 'Transforms' - status: ${{ steps.tdate.outputs.TDATE }} + status: ${{ env.action_tdate }} color: gray path: output/transforms.svg - name: TD Badge - uses: emibcn/badge-action@v1 + uses: emibcn/badge-action@v2.0.2 with: label: 'TDs' - status: ${{steps.tds.outputs.TDWARNS}} - color: ${{steps.tds.outputs.TDCOLOR}} + status: ${{ env.action_tdwarns }} + color: ${{ env.action_tdcolor }} path: output/tds.svg + - name: Make Dashboard Snippet + run: | + rurl="https://raw.githubusercontent.com/commoncriteria/${{env.action_projname}}/gh-pages/${{env.action_branch}}" + surl="https://commoncriteria.github.io/${{env.action_projname}}/${{env.action_branch}}" + gurl="https://github.com/commoncriteria/${{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/commoncriteria/${{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://commoncriteria.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://commoncriteria.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 - # Use the output from the `coverage` step - - name: Generate the validation badge SVG image - uses: emibcn/badge-action@v1 + - name: Prepare checkout + run: | + mkdir gh-pages + + - uses: actions/checkout@v3 with: - label: 'Validation' - status: ${{ steps.validate.outputs.VALERRORS }} - color: ${{ steps.coverage.outputs.valcolor }} - path: output/validation.svg + ref: gh-pages + path: gh-pages - - id: debug + + - name: Move output to branch run: | - ls - ls output - pwd + 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@4.0.0 + uses: JamesIves/github-pages-deploy-action@v4 with: branch: gh-pages # The branch the action should deploy to. - folder: output # The folder the action should deploy. + folder: gh-pages # The folder the action should deploy. - # - name: Commit badges - # continue-on-error: true - # env: - # BADGE: ${{ steps.coverage.outputs.path }} - # run: | - # git config --local user.email "action@github.com" - # git config --local user.name "GitHub Action" - # git add output #warnings.svg validation.svg build-branch-badge.svg spell-badge.svg transforms.svg tds.svg - # git commit -m "Update files" - - # # - name: Upload badge as artifact - # # - name: Upload badge as artifact - # # uses: actions/upload-artifact@v2 - # # with: - # # name: badge - # # path: ${{ steps.coverage.outputs.path }} - # # if-no-files-found: error - - # # - name: Commit badges - # # continue-on-error: true - # # env: - # # BADGE: ${{ steps.coverage.outputs.path }} - # # run: | - # # git config --local user.email "action@github.com" - # # git config --local user.name "GitHub Action" - # # git add "${{ steps.extract_branch.outputs.branch }}" - # # git commit -m "Add/Update badges" - - # - name: Push badge commit - # uses: ad-m/github-push-action@master - # if: ${{ success() }} - # with: - # github_token: ${{ secrets.GITHUB_TOKEN }} - # branch: ${{ steps.coverage.outputs.branch }} diff --git a/README.adoc b/README.adoc new file mode 100644 index 00000000..8c7bca89 --- /dev/null +++ b/README.adoc @@ -0,0 +1,105 @@ +== Protection Profile for Mobile Device Fundamentals +[cols="1,1,1,1,1,1,1,1"] +|=== +8+|mobile-device +| https://github.com/commoncriteria/mobile-device/tree/release-3.3[release-3.3] +a| https://commoncriteria.github.io/mobile-device/release-3.3/mobile-device-release.html[πŸ“„] +a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/release-3.3/ValidationReport.txt] +image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/release-3.3/validation.svg[Validation] +a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/release-3.3/SanityChecksOutput.md] +image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/release-3.3/warnings.svg[SanityChecks] +a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/release-3.3/SpellCheckReport.txt] +image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/release-3.3/spell-badge.svg[SpellCheck] +a|[link=https://github.com/commoncriteria/mobile-device/blob/gh-pages/release-3.3/TDValidationReport.txt] +image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/release-3.3/tds.svg[TDs] +a|image::https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/release-3.3/transforms.svg[transforms,150] +a| +https://commoncriteria.github.io/mobile-device/release-3.3/mobile-device-release-linkable.html[mobile-device-release-linkable.html] + +https://commoncriteria.github.io/mobile-device/release-3.3/mobile-device-release.html[mobile-device-release.html] + +https://commoncriteria.github.io/mobile-device/release-3.3/mobile-device.html[mobile-device.html] + +https://commoncriteria.github.io/mobile-device/release-3.3/mobile-device-paged.pdf[mobile-device-paged.pdf] + +|=== + + +https://github.com/commoncriteria/mobile-device/issues[image:https://img.shields.io/github/issues/commoncriteria/mobile-device.svg?maxAge=2592000[GitHub +issues Open]] + +This repository hosts the draft version of the Protection Profile for +Mobile Device Fundamentals based on the +https://commoncriteria.github.io/pp/mobile-device/mobile-device-esr.html[Essential +Security Requirements (ESR)] for this technology class of products. 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. A list +of products that have passed evaluation against this Protection Profile +can be found https://www.niap-ccevs.org/Profile/Info.cfm?id=417[here]. + +=== Draft Version + +* https://commoncriteria.github.io/pp/mobile-device/mobile-device-release.html[Protection +Profile for Mobile Device Fundamentals] (html) +* https://commoncriteria.github.io/pp/mobile-device/mobile-device-release.pdf[Protection +Profile for Mobile Device Fundamentals] (pdf) + +=== Release Version + +* https://www.niap-ccevs.org/Profile/Info.cfm?PPID=455&id=455[Protection +Profile for Mobile Device Fundamentals v3.2] + +=== Contributing + +If you are interested in contributing directly to future versions the +this Protection Profile, please consider joining the NIAP technical +community. * +https://www.niap-ccevs.org/NIAP_Evolution/tech_communities.cfm[How to +join the NIAP Technical Community (Mailing list and updates)] + +=== Feedback + +Questions, comments, and fixes can be submitted to the +https://github.com/commoncriteria/mobile-device/issues[repository issue +tracker] + +=== Quickstart + +To clone this project along with its _transforms_ submodule run: + +.... + git clone --recursive git@github.com:commoncriteria/mobile-device.git +.... + +or + +.... + git clone --recursive https://github.com/commoncriteria/mobile-device.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. + +=== Links + +* https://www.niap-ccevs.org/[National Information Assurance Partnership +(NIAP)] +* https://www.commoncriteriaportal.org/[Common Criteria Portal] diff --git a/README.md b/README.md deleted file mode 100644 index 26f5e06a..00000000 --- a/README.md +++ /dev/null @@ -1,71 +0,0 @@ -Protection Profile for Mobile Device Fundamentals -============================================= -![Master Badges](https://img.shields.io/badge/Build-master-black.svg) -![Build](https://github.com/commoncriteria/mobile-device/workflows/Build/badge.svg) -![Validate](https://github.com/commoncriteria/mobile-device/workflows/Validate/badge.svg) - -![Last QuickBuilt Branch](https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/build-branch-badge.svg) -[![Validation](https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/validation.svg)](https://github.com/commoncriteria/mobile-device/blob/gh-pages/ValidationReport.txt) -[![SanityChecks](https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/warnings.svg)](https://github.com/commoncriteria/mobile-device/blob/gh-pages/SanityChecksOutput.md) -[![SpellCheck](https://raw.githubusercontent.com/commoncriteria/mobile-device/gh-pages/spell-badge.svg)](https://github.com/commoncriteria/mobile-device/blob/gh-pages/SpellCheckReport.txt) -[![QuickBuild](https://github.com/commoncriteria/mobile-device/actions/workflows/quick_build.yml/badge.svg)](https://commoncriteria.github.io/mobile-device) - -[![GitHub issues Open](https://img.shields.io/github/issues/commoncriteria/mobile-device.svg?maxAge=2592000)](https://github.com/commoncriteria/mobile-device/issues) - -This repository hosts the draft version of the Protection Profile for Mobile Device Fundamentals based on the -[Essential Security Requirements (ESR)](https://commoncriteria.github.io/pp/mobile-device/mobile-device-esr.html) for this technology class of -products. This repository is used to facilitate collaboration and development on the draft document. -See the [release](#Release-Version) section if you are looking for the officially released version for evaluations. -A list of products that have passed evaluation against this Protection Profile can be found [here](https://www.niap-ccevs.org/Profile/Info.cfm?id=417). - - -## Draft Version -* [Protection Profile for Mobile Device Fundamentals ](https://commoncriteria.github.io/pp/mobile-device/mobile-device-release.html) (html) -* [Protection Profile for Mobile Device Fundamentals ](https://commoncriteria.github.io/pp/mobile-device/mobile-device-release.pdf) (pdf) - -## Release Version -* [Protection Profile for Mobile Device Fundamentals v3.2](https://www.niap-ccevs.org/Profile/Info.cfm?PPID=455&id=455) - -## Contributing - -If you are interested in contributing directly to future versions the this Protection Profile, please consider joining the NIAP technical community. -* [How to join the NIAP Technical Community (Mailing list and updates)](https://www.niap-ccevs.org/NIAP_Evolution/tech_communities.cfm) - -## Feedback - -Questions, comments, and fixes can be submitted to the [repository issue tracker](https://github.com/commoncriteria/mobile-device/issues) - -## Quickstart -To clone this project along with its _transforms_ submodule run: - -```` - git clone --recursive git@github.com:commoncriteria/mobile-device.git -```` -or -```` - git clone --recursive https://github.com/commoncriteria/mobile-device.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 -[Help working with Transforms Submodule](https://github.com/commoncriteria/transforms/wiki/Working-with-Transforms-as-a-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. - -## Links -* [National Information Assurance Partnership (NIAP)](https://www.niap-ccevs.org/) -* [Common Criteria Portal](https://www.commoncriteriaportal.org/) - -## License - -See [License](./LICENSE) diff --git a/input/cc.xml b/input/cc.xml deleted file mode 100755 index 52c4e42b..00000000 --- a/input/cc.xml +++ /dev/null @@ -1,53805 +0,0 @@ - - - - - - - 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 centralized - 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/mobile-device.xml b/input/mobile-device.xml index 82c4f775..d79bf295 100644 --- a/input/mobile-device.xml +++ b/input/mobile-device.xml @@ -65,7 +65,7 @@ How is it differenet then me using subsection? -