Common Criteria (CC) | Common Criteria for Information Technology Security
Evaluation. |
Common Evaluation Methodology (CEM) | Common Evaluation Methodology for Information Technology Security
Evaluation. |
Extended Package (EP) | An implementation-independent set of security requirements for a category
of products, which extends those in a Protection Profile. |
Protection Profile (PP) | An implementation-independent set of security requirements for a category
of products. |
Security Target (ST) | A set of implementation-dependent security requirements for a specific
product. |
Target of Evaluation (TOE) | The product under evaluation. In this case, application software and its
supporting documentation. |
TOE Security Functionality (TSF) | The security functionality of the product under evaluation. |
TOE Summary Specification (TSS) | A description of how a TOE satisfies the SFRs in a ST. |
Security Functional Requirement (SFR) | A requirement for security enforcement by the TOE.
|
Security Assurance Requirement (SAR) | A requirement to assure the security of the TOE.
|
Visible contents | The visible contents of the file; the visual representation of text, images
and complex objects. |
Obscured visible data | Content that could be visible but is obscured in some way such as content
that runs off an edge of the container, text in a black font on black background (or
any color of font on a similar color background), very small fonts, cropped or clipped
graphics or images, hidden layers, portions of an embedded object (e.g. Microsoft OLE)
that are outside the view container. |
Static data or metadata | File properties such as author or creation date, stored form field data,
undo cache or any data kept to revert to a prior version of an element or the document
itself, incremental updates, collaboration data such as comments, tracked changes,
workflow data, embedded search indexes, bookmarks, document info added by 3rd-party
apps, accessibility data such as alternate text, etc. |
Structural data | Data that is part of the file format structure, such as a file header or
fonts, and is necessary to interpret the file properly for display or
print. |
Functional data | Forms, scripts, link Uniform Resource Locators (URLs), workflow data,
action buttons, formulas in a spreadsheet, macros or any type of executable
content. |
Remnant data | Artifacts of the original application or source file format such as remnant
or unreferenced data from fast saves, unreferenced or unused elements, malformed
elements that cannot be fixed, garbage data in the file structure. |
Images | The actual image data stored in the file as opposed to what is visible; the
visible image can be cropped or resized but the full image could still be retained in
the file format and may or may not match the visible image; some image formats can
have their own metadata, such as Joint Photographic Experts Group (JPG) and Tagged
Image File Format (TIFF). |
Complex Objects | Objects that may have their own static or functional metadata and may
differ between the stored and visible form, such as images, attachments, Microsoft OLE
objects, Microsoft ActiveX controls, and temporal objects. |
Temporal Objects | A particular type of complex object whose representation extends through a
time interval, such as video, audio, flash animation, slide shows, etc. References to
“complex objects” in the requirements section of this paper include temporal
objects. |
Metadata of objects or embedded objects | Such as EXIF data of images; images themselves can contain other images and
their own metadata |
Attachments | An electronic document or data file that is part of the main file but is
logically distinct and separable from the main electronic document. |
Simplify (or simplified) | Replace a complex object or element with a single layer element that does
not contain hidden or obscured data. The original representation of the object and all
of the original hidden data must be removed from the document and the visible space
must be replaced with the simplified element. For example, a document could contain an
embedded spreadsheet on a page where only a small portion of the spreadsheet is
visible within the view container on the page while content in the rest of the
spreadsheet is in the document but hidden from the viewer. To simplify such an object,
the TOE could create a single layer image
(with no metadata of its own) from just the portion of the spreadsheet that is
visible, place that image on the page and remove the embedded spreadsheet. This is
just one solution. The intent of simplifying an object is to remove something complex
that could contain hidden data and replace it with something simple that does not
contain hidden data. |
Examine a test file or document | The evaluator uses a hex editor or similar tool to view the raw binary (or
hex) data of the file and the format structure. This allows the evaluator to view the
contents of the file directly rather than through the TOE’s interpretation of those contents. The
examination can include the use of tools to extract, decode or decompress certain
types of elements from the format, such as text or images. Care must be taken so that
the extraction process does not change the element’s size, resolution, or content. The
Technical Community will identify appropriate tools. |
Apply the TOE | Follow the multi-step process where the user selects or marks areas or
items in a document for redaction and then instructs the TOE to redact the marked
areas and hidden information from the file. |
Test files | To test the TOE, the evaluator
will have to use test documents that have content expected to produce a certain
result. The evaluator will apply the redaction tool to the test files and examine the
output to determine if it is as expected. The same test documents can be used for each
TOE that produces the same format as those
test documents. For example, a set of PDF test files can be used for all PDF redaction
tools. Test files will usually contain only one testable item at a time to make it
easier to identify that item in the structure of the document, but some test files
should contain multiple testable items. The Technical Community will create a set of
test files for the assurance activities for the most common formats. |