Security Target
Common Criteria: EAL1 augmented with ALC_FLR.3
Version 1.0
5‐JUL‐10
Document management
Document identification
Document ID E14_EAL1_ASE
Document title Microsoft Exchange Server 2010 Security Target
Release authority Amy Blumenfield (amyblu)
Product version Exchange Server 2010 Enterprise (English) 64‐bit (Build:
14.00.0639.021)
Document history
Version Date Description
0.1 01‐MAY‐10 Release for internal review.
0.2 02‐MAY‐10 Update for formatting and internal review.
0.3 03‐MAY‐10 Released for Microsoft review.
0.4 25‐MAY‐10 Formatting updates.
0.5 30‐MAY‐10 Minor updates.
0.6 5‐JUL‐10 Minor syntax and typographical updates. Corrected the process flow for
remote wipe functionality.
1.0 05‐JUL‐10 Initial release.
2 of 52
Table of Contents
1 Security Target introduction (ASE_INT)......................................................................................... 4
1.1 ST and TOE identification..............................................................................................................4
1.2 Document organization ................................................................................................................4
1.3 TOE description.............................................................................................................................5
1.4 Logical scope of the TOE ...............................................................................................................8
2 Conformance Claim (ASE_CCL).................................................................................................... 10
3 Security objectives (ASE_OBJ)..................................................................................................... 11
3.1 Overview .....................................................................................................................................11
3.2 Security objectives for the IT environment ................................................................................11
3.3 Security objectives for the non‐IT environment.........................................................................12
4 Security requirements (ASE_REQ)............................................................................................... 13
4.1 Overview .....................................................................................................................................13
4.2 SFR conventions..........................................................................................................................13
4.3 Security functional requirements ...............................................................................................14
4.4 Dependency analysis...................................................................................................................33
4.5 TOE security assurance requirements ........................................................................................37
4.6 Assurance measures ...................................................................................................................39
5 TOE summary specification (ASE_TSS) ........................................................................................ 41
5.1 Overview .....................................................................................................................................41
5.2 Connection Filtering....................................................................................................................42
5.3 Message filtering.........................................................................................................................43
5.4 Attachment Filtering...................................................................................................................44
5.5 Transport Filtering.......................................................................................................................45
5.6 Access Control.............................................................................................................................46
5.7 Identification and Authentication...............................................................................................49
5.8 Distribution Group Restriction....................................................................................................50
5.9 Remote Wipe ..............................................................................................................................51
3 of 52
1 Security Target introduction (ASE_INT)
1.1 ST and TOE identification
ST Title Microsoft Exchange 2010 Security Target
ST Version 1.0, 5‐JUL‐10
TOE Reference Microsoft Exchange Server 2010 Enterprise (English) 64‐bit (Build:
14.00.0639.021)
Assurance Level EAL1 augmented with ALC_FLR.3
CC Identification Common Criteria for Information Technology (IT) Security Evaluation, Version
3.1, July 2009, incorporating:
• Part One – Introduction and General Model, Revision Three, July 2009;
• Part Two – Security Functional Components, Revision Three, July 2009;
and
• Part Three – Security Assurance Components, Revision Three, July 2009.
International Standard – International Organization for Standardization
(ISO)/International Electro technical Commission (IEC) 15408:1999.
1.2 Document organization
This document is organized into the following sections:
• Section 1 provides the introductory material for the ST as well as the TOE description.
• Section 2 provides the conformance claims for the evaluation.
• Section 3 defines the security objectives for the environment.
• Section 4 contains the functional and assurance requirements derived from the Common
Criteria, Part 2 and 3, respectively that must be satisfied by the TOE.
4 of 52
• Section 5 provides a summary of the TOE specification, identifying the IT security functions
provided by the TOE.
1.3 TOE description
1.3.1 TOE type and usage
The TOE is Exchange Server 2010 Enterprise (English) 64‐bit (Build 14.00.0639.021) and is referred to as
Exchange 2010 in this document. The TOE is an e‐mail and collaboration server that provides secure
access to personal and shared data for a variety of clients using various protocols.
1.3.2 TOE security functions
The following table highlights the range of security functions and features implemented by the TOE.
Security function Description
Connection filtering Protects from unwanted spam or Unsolicited Commercial E‐mail (UCE) by
blocking messages from specified IP addresses.
Message filtering Filters potential spam messages based on Administrator configured SMTP
filters, including local and third party block/allow lists.
Attachment filtering Provides a mechanism to filter potentially harmful attachments.
Transport filtering Allows the administrator to define mail policies to prevent specific internal
and/or external users from emailing each other.
Access control Protects mailboxes and public folders from unauthorized access.
Identification and
authentication
Provides identification and authentication mechanism for the Outlook Voice
Access functionality in cases where Outlook Voice Access is not secured by the
use of the TLS protocol.
Distribution group
restriction
Requires users sending mail to a distribution group to be successfully
authenticated and to be authorized.
Remote device wipe An Administrator can issue a command to wipe a managed Windows Mobile
device in the event that the device may have been compromised.
5 of 52
1.3.3 Physical scope of the TOE
The TOE comprises the Exchange 2010 software. This software is installed on a Windows server
operating system and underlying suitable hardware. A typical installation of the TOE can be found in
Figure 1 below and identifies the various server roles and components of the Exchange 2010 Server.
The underlying platform for the evaluated version of Exchange 2010 is the Windows Server 2008 R2
Enterprise Edition x64 Edition (English) operating system with patches as listed in the Exchange Server
Guidance Addendum. This includes Internet protocol support using the Internet Information Services
(IIS) component in Windows and the Active Directory for directory services.
Figure 1 – Exchange 2010 architecture
All roles, with the exception of the Edge Transport Server, can be installed on a single machine;
however, for reasons of performance, in medium and large organization installations, these roles may
be installed on individual servers. The TOE roles communicate in the same way whether they are
installed on one server or many servers. More information about the installation of the TOE will be
provided in the related guidance documents.
6 of 52
The following table describes each of the Exchange Server roles specified in Figure 1 above.
Server role Description
Mailbox Server
Role
The Mailbox server role hosts mailbox and public folder databases. The
administrator manages mail Lifecycle folders and policies from a Mailbox server.
The mailbox server role, in conjunction with the environment, provides access
control for users, mail, fax, and voice messages.
Client Access
Server Role
This is the server that hosts the client protocols. The Client Access Server also
exposes a Web Services interface for application developers.
The Client Access server role accepts connections to the Exchange server from a
variety of different clients. See Section1.4.1 for more details on client
applications and protocols.
Unified Messaging
Server Role
Unified Messaging combines voice messaging, fax, calendaring and e‐mail, which
are accessible from a telephone or a computer. Exchange 2010 Unified
Messaging integrates Exchange Server with telephony networks and brings
Unified Messaging features to the core of Exchange Server. Outlook Voice Access
(OVA) is a feature of the Unified Messaging Role and lets users access their
mailbox using telephone communication. OVA can optionally be secured by the
Transport Layer Security Protocol (TLS).
Hub Transport
Server Role
This is the mail routing server that routes mail within the Exchange organization.
The Hub Transport server role handles all mail flow inside the organization,
applies transport rules, applies journaling policies, and delivers messages to the
recipient's mailbox. Messages that are sent to the Internet are relayed by the
Hub Transport server to the Edge Transport server role that is deployed in the
perimeter network.
Edge Transport
Server Role
This is the mail routing server that sits at the perimeter of the network topology
and routes mail into and out of the Exchange organization. The Edge Transport
server role handles the following scenarios:
• Mail Flow ‐ The Edge Transport server role accepts mail coming into the
Exchange Server organization from the Internet and routes all outbound
messages to the Internet.
• Filtering ‐ The Edge Transport server role helps protect the Exchange
Server organization from spam by filtering inbound messages as they
arrive and before they are delivered to the internal private network.
7 of 52
1.4 Logical scope of the TOE
1.4.1 Supported protocols and clients
The TOE offers its services for users via a variety of protocols including:
• RPC for applications like Microsoft Office Outlook ,
• SMTP for generic clients and servers sending e‐mail to the TOE,
• HTTP for Web Browsers (using Outlook Web Access) and for ActiveSync clients,
• RPC tunnelled over HTTP,
• Web Services Application Programming Interface (API) for in‐house applications, and
• SIP/RTP for Outlook Voice Access (OVA).
Outlook Voice Access (OVA) can optionally be secured by enabling the TLS protocol with mutual
authentication for SIP/RTP. In this case, the identification and authentication of OVA users is not
performed by the TOE but is the sole responsibility of the TLS authenticated application which is part of
the IT environment.
These protocols can be used to connect to the TOE via different clients. Clients can be categorized into
the following groups:
• Generic Client (also known as Internet Client): A client of this type could be any mail client that
uses SMTP to connect to the TOE or a web browser that uses HTTP or Web Services to connect
to the TOE.
• Outlook client: In contrast to the generic clients, an Outlook client uses RPC (or RPC over http)
to connect to the TOE.
In addition to the above clients, the TOE allows users to connect using a standard or IP telephone via
Outlook Voice Access. To use standard telephones, a PBX must be connected to the TOE. A PBX may also
forward IP calls.
The Unified Messaging server role in Exchange 2010 lets users access voice mail, e‐mail, fax messages,
and calendar information located in their Exchange Server mailbox from an e‐mail client such as
Microsoft Outlook or Outlook Web Access, from a mobile device that has Microsoft Exchange ActiveSync
8 of 52
enabled, such as a Windows Mobile® powered Smartphone or a personal digital assistant (PDA), or from
a telephone. Further, the SMTP protocol can be used by a SMTP server to connect to the TOE.
The scope of the TOE ends at the interfaces where it provides its services and does not include any
functionality of any client.
1.4.2 Excluded features
The following components and features are considered outside the scope of the evaluation:
• the IMAP4 and POP3 protocols,
• all clients that can be used to connect to the TOE, and
• all externally compiled lists that the TOE relies on for filtering of email messages.
9 of 52
2 Conformance Claim (ASE_CCL)
The ST and TOE are conformant to version 3.1 (Revision 3) of the Common Criteria for Information
Technology Security Evaluation.
The following conformance claims are made for the TOE and ST:
• Part 2 conformant. Conformant with Common Criteria for Information Technology Security
Evaluation Part 2: Security functional requirements, version 3.1, July 2009.
• Part 3 conformant, EAL1 augmented. Conformant with Common Criteria for Information
Technology Security Evaluation Part 3: Security assurance requirements, version 3.1, Revision 3.
Evaluation is EAL1 augmented with ALC_FLR.3.
10 of 52
3 Security objectives (ASE_OBJ)
3.1 Overview
The security objectives at an EAL1 level of assurance include concise statements of the objectives to be
achieved by the supporting environment.
3.2 Security objectives for the IT environment
Identifier Objective statements
OE.PLATFORM The platform upon which the TOE resides shall be Windows Server 2008R2
Enterprise Edition x64 (English).The platform provides:
• Access Control to restrict modification to TOE executables, the platform
itself, configuration files and databases (mailboxes and public folders)
only to the authorized administrators.
• Functionality for supporting and enforcing Identification and
Authentication of users. The platform shall ensure the identification
and authentication of users except for the case that they connect via a
non TLS encrypted Outlook Voice Access connection.
• Methods to store and manage TSF data for the TOE. Further, the
platform will provide a role concept for administrative roles and restrict
access to TSF data where necessary.
11 of 52
3.3 Security objectives for the non‐IT environment
Identifier Objective statements
OE.COM_PROT The administrator of the TOE shall ensure that the communication channels
between all server roles are appropriately secured against eavesdropping and
manipulation by physical protection of the wire or by using encryption.
Any internet connection to a server role shall be appropriately secured by a
firewall.
The administrator shall ensure that the connection between the TOE and the
user is appropriately secured by a physical protection of the wire or by using
encryption to avoid eavesdropping or manipulation of the communication.
OE.INSTALL The TOE shall be delivered, installed, configured and set up in accordance with
documented delivery and installation/setup procedures and only by trustworthy
staff.
The administrator must ensure that the TOE is delivered, installed, configured,
managed and operated in a manner that is consistent with IT security.
Beside the software necessary for the management and operation of the TOE
(e.g. management tools) no untrusted software shall be installed on the
machines the TOE is installed on.
The administrator(s) shall ensure – during TOE installation and operation ‐ that
the platform the TOE is running on allows the secure operation of the TOE.
OE.BLOCKLIST Block/allow lists from third parties ‐ which are used to evaluate email messages ‐
have to be of sufficient quality and trustworthy. Therefore, the administrator
shall ensure that only third party block/allow lists from trustworthy sources will
be used and that the download of these block/allow lists is appropriately secured
with respect to the integrity and authenticity of the block/allow lists
OE.PHYSICAL The administrators shall ensure that those parts of the TOE and its platform that
are critical to security policy are protected from any physical attack.
12 of 52
4 Security requirements (ASE_REQ)
4.1 Overview
This section defines the security requirements satisfied by the TOE. Each requirement has been
extracted from version 3.1 of the Common Criteria, part 2 providing functional requirements and part 3
providing assurance requirements.
4.2 SFR conventions
Part 2 of the Common Criteria defines an approved set of operations that may be applied to security
functional requirements. Following are the approved operations and the document conventions that
are used within this ST to depict their application:
• Assignment. The assignment operation provides the ability to specify an identified parameter
within a requirement. Assignments are depicted using bolded text and are surrounded by
square brackets as follows [assignment].
• Selection. The selection operation allows the specification of one or more items from a list.
Selections are depicted using bold italics text and are surrounded by square brackets as follows
[selection].
• Refinement. The refinement operation allows the addition of extra detail to a requirement.
Refinements are indicated using bolded text, for additions, and strike‐through, for deletions.
• Iteration. The iteration operation allows a component to be used more than once with varying
operations. Iterations are depicted by placing a letter at the end of the component identifier as
follows FDP_IFF.1a and FDP_IFF.1b.
13 of 52
4.3 Security functional requirements
4.3.1 Overview
The security functional requirements are expressed using the notation stated in Section 4.2 and
summarized in the table below.
Identifier Title
FDP_ACC.1a Subset access control (Folder)
FDP_ACC.1b Subset access control (Group)
FDP_ACF.1a Security attribute based access control (Folder)
FDP_ACF.1b Security attribute based access control (Group)
FDP_IFC.1a Subset information flow control (Connect)
FDP_IFC.1b Subset information flow control (SRL)
FDP_IFC.1c Subset information flow control (Message)
FDP_IFC.1d Subset information flow control (Attachment Filter)
FDP_IFC.1e Subset information flow control (Transport)
FDP_IFF.1a Simple security attributes (Connect)
FDP_IFF.1b Simple security attributes (SRL)
FDP_IFF.1c Simple security attributes (Message)
FDP_IFF.1d Simple security attributes (AttachmentFilter)
FDP_IFF.1e Simple security attributes (Transport)
FIA_SOS.1 Verification of secrets
FIA_UAU.2 User authentication before any action
FIA_UID.2 User identification before any action
14 of 52
Identifier Title
FIA_USB.1 User‐subject binding
FMT_MOF.1 Management of security functions behaviour (Remote Wipe)
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1 Management of security attributes (Folder)
FMT_MSA.3a Static attribute initialisation (Folder)
FMT_MSA.3b Static attribute initialisation (Group)
FMT_MSA.3c Static attribute initialisation (Connect)
FMT_MSA.3d Static attribute initialisation (SRL)
FMT_MSA.3e Static attribute initialisation (Message)
FMT_MSA.3f Static attribute initialisation (AttachmentFilter)
FMT_MSA.3g Static attribute initialisation (Transport)
15 of 52
4.3.2 FDP_ACC.1a Subset access control (Folder)
Hierarchical to: No other components.
FDP_ACC.1a.1 The TSF shall enforce the [Discretionary Access Control SFP] on [
Subjects:
a) processes acting on behalf of users
Objects:
a) Mailbox, public folder items1 and (sub)folders
Mailbox operations:
a) List folder
b) Create subfolder
c) Create item
d) Read item
e) Edit item
f) Delete item
g) Modify folder permissions
h) Send item
Public folder operations:
a) List Folder
b) Create subfolder
c) Create item
d) Read item
e) Edit item
f) Delete item
g) Modify folder permissions].
Dependencies: FDP_ACF.1 ‐ Security attribute based access control
Notes: None.
1
Mailbox and public folder items include all objects that are stored in a mailbox or public folder (e.g. emails, contacts or
certificates)
16 of 52
4.3.3 FDP_ACC.1b Subset access control (Group)
Hierarchical to: No other components.
FDP_ACC.1b.1 The TSF shall enforce the [Distribution Group Restriction SFP] on [
Subjects:
a) users sending e‐mail
objects:
a) distribution groups
operation:
a) use, i.e. send messages to a distribution group].
Dependencies: FDP_ACF.1 ‐ Security attribute based access control
Notes: None.
4.3.4 FDP_ACF.1a Security attribute based access control (Folder)
Hierarchical to: No other components.
FDP_ACF.1a.1 The TSF shall enforce the [Discretionary Access Control SFP] to objects based on
the following: [
Subject attribute:
a) ID2
of the user and its corresponding role
Object attributes:
a) Object name
b) Owner of the folder].
FDP_ACF.1a.2 The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: [
The operation is allowed if the ID of the user is linked to a role 3
permitted to
perform the requested operation on the object.].
FDP_ACF.1a.3 The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: [None].
2
The ID of the current user is provided by the Windows Operating System or by the authentication policy as expressed in
FIA_UAU.2 (only when the user is connected via non‐TLS secured Outlook Voice Access).
3
A role in this context is a collection of operations linked to a scope
17 of 52
FDP_ACF.1a.4 The TSF shall explicitly deny access of subjects to objects based on the following
additional rules: [None].
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
Notes: None.
4.3.5 FDP_ACF.1b Security attribute based access control (Group)
Hierarchical to: No other components.
FDP_ACF.1b.1 The TSF shall enforce the [Distribution Group Restriction SFP] to objects based on
the following: [
Object attributes (distribution groups):
a) Message Delivery Restrictions
1. “Require that all senders are authenticated” restriction
2. “Accept messages from a specific list of senders” list
3. “Reject messages from a specific list of senders” list].
Subject attribute:
a) ID of the user and its corresponding role
b) Authentication status within exchange
FDP_ACF.1b.2 The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: [
The operation is allowed, if:
a) the “require that all senders are authenticated” is set to false; or
b) the “require that all senders are authenticated” is set to true and the
subject is authenticated (i.e. the corresponding ID is available),
and
a) the ID of the sending user is in the “Accept messages from a specific list
of senders” list and not the “Reject messages from a specific list of
senders” list].
FDP_ACF.1b.3 The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: [None].
FDP_ACF.1b.4 The TSF shall explicitly deny access of subjects to objects based on the following
additional rules: [None].
18 of 52
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
Notes: None.
4.3.6 FDP_IFC.1a Subset information flow control (Connect)
Hierarchical to: No other components.
FDP_IFC.1a.1 The TSF shall enforce the [Connection Filtering SFP] on [
Subjects:
a) External SMTP Servers
b) Edge Transport Server Role
Information:
a) email messages
Operations:
a) email transfer].
Dependencies: FDP_IFF.1 Simple security attributes
Notes: None.
4.3.7 FDP_IFC.1b Subset information flow control (SRL)
Hierarchical to: No other components.
FDP_IFC.1b.1 The TSF shall enforce the [Sender Reputation SFP] on [
Subjects:
a) External SMTP Servers
b) Edge Transport Server Role
Information:
a) email Messages
Operations:
b) Mail Transfer].
Dependencies: FDP_IFF.1 Simple security attributes
Notes: None.
19 of 52
4.3.8 FDP_IFC.1c Subset information flow control (Message)
Hierarchical to: No other components.
FDP_IFC.1c.1 The TSF shall enforce the [Message Filtering SFP] on [
Subjects:
a) External SMTP Servers
b) Edge Transport Server Role
Information:
a) email messages
Operations:
a) email transfer].
Dependencies: FDP_IFF.1 Simple security attributes
Notes: None.
4.3.9 FDP_IFC.1d Subset information flow control (Attachment
Filter)
Hierarchical to: No other components.
FDP_IFC.1d.1 The TSF shall enforce the [Attachment SFP] on [
Subjects:
a) External SMTP Servers
b) Edge Transport Server Role
Information:
a) email messages
Operations:
a) email transfer].
Dependencies: FDP_IFF.1 Simple security attributes
Notes: None.
20 of 52
4.3.10 FDP_IFC.1e Subset information flow control (Transport)
Hierarchical to: No other components.
FDP_IFC.1e.1 The TSF shall enforce the [Hub Transport SFP] on [
Subjects:
a) Hub Transport Server Role
Information:
a) email messages
Operations:
a) email transfer].
Dependencies: FDP_IFF.1 Simple security attributes
Notes: None.
4.3.11 FDP_IFF.1aSimple security attributes (Connect)
Hierarchical to: No other components.
FDP_IFF.1a.1 The TSF shall enforce the [Connection Filtering SFP] based on the following types
of subject and information security attributes: [
Subject attributes:
a) IP address of the external SMTP server
b) allow/block lists of the Edge Transport Server Role
c) list of exceptional recipients of the Edge Transport Server Role
Information attributes:
a) recipients of the e‐mail].
FDP_IFF.1a.2 The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules hold:
[None].
FDP_IFF.1a.3 The TSF shall enforce the [additional ordered rules
a) If the IP address of the sending external SMTP server is listed on a local
allow list, the message will be accepted
b) If the IP address of the sending external SMTP server is listed on a local
block list, the message will be rejected
c) If the IP address of the sending external SMTP server is listed on a
remote allow list, the message will be accepted
21 of 52
d) If one of the recipients of the e‐mail is on the local list of exceptional
recipients the message will be accepted
e) If the IP address of the sending external SMTP server is listed on a
remote block list, the message will be rejected
f) Else the message will be accepted].
FDP_IFF.1a.4 The TSF shall explicitly authorise an information flow based on the following rules:
[None].
FDP_IFF.1a.5 The TSF shall explicitly deny an information flow based on the following rules:
[None].
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
Notes: This functionality utilizes the following kinds of allow and block lists:
a) Local allow and block lists maintained by Administrators
b) Remote allow and block lists retrieved from external service providers (so
called “block list service providers”)
c) A local list of exceptional recipients.
The remote lists are not considered to be Security Attributes in the context of this
policy as they are not stored locally.
4.3.12 FDP_IFF.1b Simple security attributes (SRL)
Hierarchical to: No other components.
FDP_IFF.1b.1 The TSF shall enforce the [Sender Reputation SFP] based on the following types of
subject and information security attributes: [
Subject attributes
a) Sender Reputation Level (SRL) of the external SMTP server (calculated
by the TOE)
b) SRL Threshold
c) local list of SRL values from the Edge Transport Server Role
Information attributes:
a) None].
FDP_IFF.1b.2 The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules hold:
[None].
FDP_IFF.1b.3 The TSF shall enforce the [additional rules
22 of 52
If:
b) the local list of SRL values contains an entry for the external SMTP server
with a SRL value greater than or equal to the SRL threshold; or
a) The SRL value (calculated by the TOE) for the external SMTP server is
greater than or equals the SRL Threshold;
the server will be added to the local block list of FDP_IFF.1a (Connect) for an
Authorized Administrator configurable period of time].
FDP_IFF.1b.4 The TSF shall explicitly authorise an information flow based on the following rules:
[None].
FDP_IFF.1b.5 The TSF shall explicitly deny an information flow based on the following rules:
[None].
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
Notes: None.
4.3.13 FDP_IFF.1c Simple security attributes (Message)
Hierarchical to: No other components.
FDP_IFF.1c.1 The TSF shall enforce the [Message Filtering SFP] based on the following types of
subject and information security attributes: [
Subject attributes:
a) sender and recipient filtering lists from the Edge Transport Server Role
b) local address book4
from the Edge Transport Server Role
Information attributes:
a) MAIL FROM: field of the RFC 2821 envelope
b) RFC 2822 header
c) RCPT TO: field of the RFC 2821 envelope].
FDP_IFF.1c.2 The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules hold: [
The e‐mail will be accepted unless:
a) the sender listed in the MAIL FROM: field of the (RFC 2821) message
envelope is on the sender filtering list or
4
The local address book is a list of local SMTP addresses.
23 of 52
b) the sender in the FROM header of the message (RFC 2822) is on the
sender filtering list or
c) the MAIL FROM: field of the RFC 2821 message envelope is blank5
and
the FROM header of the message (RFC 2822) does not contain a valid e‐
mail address6
or
d) the recipient listed in the RCPT TO: field of the RFC 2821 message
envelope is on the recipient filtering list or
e) the recipient does not exist in the local address book].
FDP_IFF.1c.3 The TSF shall enforce the [None].
FDP_IFF.1c.4 The TSF shall explicitly authorise an information flow based on the following rules:
[None].
FDP_IFF.1c.5 The TSF shall explicitly deny an information flow based on the following rules:
[None].
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
Notes: None.
4.3.14 FDP_IFF.1d Simple security attributes (AttachmentFilter)
Hierarchical to: No other components.
FDP_IFF.1d.1 The TSF shall enforce the [Attachment SFP] based on the following types of
subject and information security attributes: [
Subject attributes:
a) Attachment Policy of the Edge Transport Server Role
Information attributes:
a) MIME Type
b) extension of the attachment].
FDP_IFF.1d.2 The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules hold: [
The information flow is permitted if not explicitly prohibited by the Attachment
5
As this field can never be completely empty, the term “blank” refers to a so called null address which is a MAIL FROM field
that contains the characters "<>"
6
A valid email address in this context means a string in the structure of [recipient]@[domain].[top level domain]
24 of 52
policy].
FDP_IFF.1d.3 The TSF shall enforce the [additional rule
Attachments will be stripped or emails containing attachments will be blocked
in accordance with the Attachment policy].
FDP_IFF.1d.4 The TSF shall explicitly authorise an information flow based on the following rules:
[None].
FDP_IFF.1d.5 The TSF shall explicitly deny an information flow based on the following rules:
[None].
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
Notes: The attachment policy as defined in FDP_IFF.1d (AttachmentFilter) comprises a
set of ordered rules that are defined by the administrator of the TOE. These rules
are evaluated in order to determine how an e‐mail attachment shall be handled.
The MIME type and Attachment extension information attributes are used by
these rules to define whether a rule shall be applied to an attachment. Each rule is
comprised of:
a) A set of criteria that defines the attachments to which the rule shall apply
(based on MIME type and Attachment extension).
b) A set of exceptions to which the rule shall not be applied.
c) An action to perform when an attachment meets the rule criteria.
4.3.15 FDP_IFF.1e Simple security attributes (Transport)
Hierarchical to: No other components.
FDP_IFF.1e.1 The TSF shall enforce the [Hub Transport SFP] based on the following types of
subject and information security attributes: [
subject attributes:
a) Hub Transport Policy of the Hub Transport Server Role
Information attributes:
a) Sender
b) Recipients
c) CC:
d) Subject
e) Classification
f) Header
25 of 52
g) Attachment Name
h) Attachment Size
i) Attachment extension
j) Importance
k) Key words in Subject or email body].
FDP_IFF.1e.2 The TSF shall permit an information flow between a controlled subject and
controlled information via a controlled operation if the following rules hold:
[None].
FDP_IFF.1e.3 The TSF shall enforce the [additional rule
For each email the Hub Transport policy shall be evaluated and each rule that
fits to the email shall be applied].
FDP_IFF.1e.4 The TSF shall explicitly authorise an information flow based on the following rules:
[None].
FDP_IFF.1e.5 The TSF shall explicitly deny an information flow based on the following rules:
[None].
Dependencies: FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
Notes: The Hub transport policy as defined in FDP_IFF.1e (Transport) comprises a set of
ordered rules that are defined by the administrator of the TOE. The rules are
evaluated in order to determine how an e‐mail message shall be handled. Each
rule is comprised of:
a) A set of criteria that define the mails to which the rule shall be applied
(based on the information attributes).
b) A set of exceptions to which the rule shall not be applied.
c) An action to perform when a mail meets the rule criteria.
4.3.16 FIA_SOS.1 Verification of secrets
Hierarchical to: No other components.
FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet [
Outlook Voice Access PIN quality metrics as defined by the administrator
including an Outlook Voice Access PIN of at least 8 digits].
Dependencies: No dependencies.
Notes: The Outlook Voice Access PINs are the only secrets maintained by the TOE in the
context of this requirement.
26 of 52
4.3.17 FIA_UAU.2User authentication before any action
Hierarchical to: FIA_UAU.1 Timing of authentication
FIA_UAU.2.1 The TSF shall require each user connecting via non TLS‐secured Outlook Voice
Access to be successfully authenticated before allowing any other TSF‐mediated
actions on behalf of that user.
Dependencies: FIA_UID.1 Timing of identification
Notes: The environment is responsible for user authentication prior to any action for
users connecting via RPC, SMTP, HTTP, RPC over HTTP, Web Services, TLS‐secured
OVA.
4.3.18 FIA_UID.2User identification before any action
Hierarchical to: FIA_UID.1 Timing of identification
FIA_UID.2.1 The TSF shall require each user connecting via non TLS‐secured Outlook Voice
Access to be successfully identified before allowing any other TSF‐mediated
actions on behalf of that user.
Dependencies: No dependencies.
Notes: The environment is responsible for user identification prior to any action for users
connecting via RPC, SMTP, HTTP, RPC over HTTP, Web Services, TLS‐secured OVA.
4.3.19 FIA_USB.1User‐subject binding
Hierarchical to: No other components.
FIA_USB.1.1 The TSF shall associate the following user security attributes with subjects acting
on the behalf of that user: [
a) ID (user’s identity)
b) Group Memberships].
FIA_USB.1.2 The TSF shall enforce the following rules on the initial association of user security
attributes with subjects acting on the behalf of users: [None].
FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the user security
attributes associated with subjects acting on the behalf of users: [None].
Dependencies: FIA_ATD.1 User attribute definition
Notes: None.
27 of 52
4.3.20 FMT_MOF.1 Management of security functions behaviour
(Remote Wipe)
Hierarchical to: No other components.
FMT_MOF.1.1 The TSF shall restrict the ability to [modify the behaviour of] the functions [
a) Issue the remote wipe command.
] to [Authorized Administrators].
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
Notes: None.
4.3.21 FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [
a) Management of user roles for the Discretionary Access Control SFP
(FDP_ACC.1a (Folder))
b) Management of security attributes for the Distribution Group
Restriction SFP (FDP_ACC.1b (Group))
c) Management of security attributes for the Message Filtering SFP
(FDP_IFF.1c (Message))
d) Management of security attributes for the Connection Filtering
SFP(FDP_IFF.1a (Connect))
e) Management of security attributes for the Sender Reputation SFP
(FDP_IFF.1b (SRL))
f) Management of security attributes for the Attachment SFP (FDP_IFF.1d
(AttachmentFilter))
g) Management of security attributes for the Hub Transport SFP
(FDP_IFF.1e (Transport))
h) Management of attributes for authentication via Outlook Voice Access
(FIA_UAU.2)
i) Management of quality metric for user PINs (FIA_SOS.1)
j) Issue a remote wipe command to a Windows Mobile Device
(FMT_MOF.1)].
Dependencies: No dependencies.
Notes: None.
28 of 52
4.3.22 FMT_MSA.1 Management of security attributes (Folder)
Hierarchical to: No other components.
FMT_MSA.1.1 The TSF shall enforce the [Discretionary Access Control SFP] to restrict the ability
to [query, modify] the security attributes [role based access control permissions,
Owner of the folder] to [Authorized Administrators and users with the
appropriate role].
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
Notes: None.
4.3.23 FMT_MSA.3a Static attribute initialisation (Folder)
Hierarchical to: No other components.
FMT_MSA.3a.1 The TSF shall enforce the [Discretionary Access Control SFP] to provide
[restrictive] default values for security attributes that are used to enforce the SFP.
FMT_MSA.3a.2 The TSF shall allow the [nobody] to specify alternative initial values to override
the default values when an object or information is created.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Notes: Every user with an Exchange 2010 mailbox, including administrators, is given a
role assignment policy by default. Administrators can decide which role
assignment policy should be assigned by default, choose what the default role
assignment policy should include, override the default for certain mailboxes, or
not assign role assignment policies by default at all.
29 of 52
4.3.24 FMT_MSA.3b Static attribute initialisation (Group)
Hierarchical to: No other components.
FMT_MSA.3b.1 The TSF shall enforce the [Distribution Group Restriction SFP] to provide
[administratively defined] default values for security attributes that are used to
enforce the SFP.
FMT_MSA.3b.2 The TSF shall allow the [Authorized Administrator and users with the appropriate
role] to specify alternative initial values to override the default values when an
object or information is created.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Notes: Every user with an Exchange 2010 mailbox, including administrators, is given a
role assignment policy by default. Administrators can decide which role
assignment policy should be assigned by default, choose what the default role
assignment policy should include, override the default for certain mailboxes, or
not assign role assignment policies by default at all.
4.3.25 FMT_MSA.3c Static attribute initialisation (Connect)
Hierarchical to: No other components.
FMT_MSA.3c.1 The TSF shall enforce the [Connection Filtering SFP] to provide [permissive]
default values for security attributes that are used to enforce the SFP.
FMT_MSA.3c.2 The TSF shall allow the [Authorized Administrator and users with the appropriate
role] to specify alternative initial values to override the default values when an
object or information is created.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Notes: None.
30 of 52
4.3.26 FMT_MSA.3d Static attribute initialisation (SRL)
Hierarchical to: No other components.
FMT_MSA.3d.1 The TSF shall enforce the [Sender Reputation SFP] to provide [permissive] default
values for security attributes that are used to enforce the SFP.
FMT_MSA.3d.2 The TSF shall allow the [Authorized Administrator and users with the appropriate
role] to specify alternative initial values to override the default values when an
object or information is created.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Notes: Here “permissive” means an SRL threshold of “7”.
4.3.27 FMT_MSA.3e Static attribute initialisation (Message)
Hierarchical to: No other components.
FMT_MSA.3e.1 The TSF shall enforce the [Message Filtering SFP] to provide [permissive] default
values for security attributes that are used to enforce the SFP.
FMT_MSA.3e.2 The TSF shall allow the [Authorized Administrator and users with the appropriate
role] to specify alternative initial values to override the default values when an
object or information is created.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Notes: None.
4.3.28 FMT_MSA.3f Static attribute initialisation (AttachmentFilter)
Hierarchical to: No other components.
FMT_MSA.3f.1 The TSF shall enforce the [Attachment SFP] to provide [restrictive] default values
for security attributes that are used to enforce the SFP.
FMT_MSA.3f.2 The TSF shall allow the [Authorized Administrator and users with the appropriate
role] to specify alternative initial values to override the default values when an
object or information is created.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Notes: None.
31 of 52
32 of 52
4.3.29 FMT_MSA.3g Static attribute initialisation (Transport)
Hierarchical to: No other components.
FMT_MSA.3g.1 The TSF shall enforce the [Hub Transport SFP] to provide [permissive] default
values for security attributes that are used to enforce the SFP.
FMT_MSA.3g.2 The TSF shall allow the [Authorized Administrator and users with the appropriate
role] to specify alternative initial values to override the default values when an
object or information is created.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Notes: In the context of this ST, the functionality required by FMT_MSA.3.2 shall be seen
in the way that the TOE does not provide any functionality to change the default
values rather than restricting the access to such functionality.
4.4 Dependency analysis
SFR Dependency Inclusion
FDP_ACC.1a FDP_ACF.1 Security attribute based access control FDP_ACF.1a
FDP_ACC.1b FDP_ACF.1 Security attribute based access control FDP_ACF.1b
FDP_ACF.1a FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACC.1a, FMT_MSA.3a
FDP_ACF.1b FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACC.1b, FMT_MSA.3b
FDP_IFC.1a FDP_IFF.1 Simple security attributes FDP_IFF.1a
FDP_IFC.1b FDP_IFF.1 Simple security attributes FDP_IFF.1b
FDP_IFC.1c FDP_IFF.1 Simple security attributes FDP_IFF.1c
FDP_IFC.1d FDP_IFF.1 Simple security attributes FDP_IFF.1d
FDP_IFC.1e FDP_IFF.1 Simple security attributes FDP_IFF.1e
FDP_IFF.1a FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFC.1a, FMT_MSA.3c
33 of 52
SFR Dependency Inclusion
FDP_IFF.1b FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFC.1b, FMT_MSA.3d
FDP_IFF.1c FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFC.1c, FMT_MSA.3e
FDP_IFF.1d FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFC.1d, FMT_MSA.3f
FDP_IFF.1e FDP_IFC.1 Subset information flow control
FMT_MSA.3 Static attribute initialisation
FDP_IFC.1e, FMT_MSA.3g
FIA_SOS.1 No dependencies N/A
FIA_UAU.2 FIA_UID.1 Timing of identification FIA_UID.2
FIA_UID.2 No dependencies N/A
FIA_USB.1 FIA_ATD.1 User attribute definition Not included – see rationale below
FMT_MOF.1 FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_SMF.1
FMT_SMR.1 not included – see rationale
below
FMT_SMF.1 No dependencies N/A
34 of 52
SFR Dependency Inclusion
FMT_MSA.1 [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FDP_ACC.1a, FDP_ACF.1a, FMT_SMF.1
FMT_SMR.1 not included – see rationale
below
FMT_MSA.3a FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.1
FMT_SMR.1 not included – see rationale
below
FMT_MSA.3b FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_SMR.1 and FMT_MSA.1 not included –
see rationale below
FMT_MSA.3c FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_SMR.1 and FMT_MSA.1 not included –
see rationale below.
FMT_MSA.3d FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_SMR.1 and FMT_MSA.1 not included –
see rationale below
FMT_MSA.3e FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_SMR.1 and FMT_MSA.1 not included –
see rationale below
FMT_MSA.3f FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_SMR.1 and FMT_MSA.1 not included –
see rationale below
35 of 52
36 of 52
SFR Dependency Inclusion
FMT_MSA.3g FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_SMR.1 and FMT_MSA.1 not included –
see rationale below
FIA_ATD.1, FMT_SMR.1 and FMT_MSA.1 has not been included as SFRs as the environment is responsible for performing the required
functionality as specified in OE.PLATFORM.
4.4.1 Rationale for not addressing all dependencies
4.5 TOE security assurance requirements
The assurance package for the evaluation of the TOE is Evaluation Assurance Level 1 (EAL1) augmented
with Systematic flaw remediation (ALC_FLR.3).
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.
Assurance class Assurance components
ADV: Development ADV_FSP.1 Basic functional specification
AGD_OPE.1 Operational user guidance
AGD: Guidance documents
AGD_PRE.1 Preparative procedures
ALC_CMS.1 TOE CM coverage
ALC_CMC.1 Labelling of the TOE
ALC: Life cycle support
ALC_FLR.3 Systematic flaw remediation
ASE_CCL.1 Conformance claims
ASE_ECD.1 Extended components definition
ASE_INT.1 ST Introduction
ASE_OBJ.1 Security objectives for the operational
environment
ASE: Security Target evaluation
ASE_REQ.1 Stated security requirements
37 of 52
38 of 52
Assurance class Assurance components
ASE_TSS.1 TOE summary specification
ATE: Tests ATE_IND.1 Independent testing ‐ conformance
AVA: Vulnerability assessment AVA_VAN.1 Vulnerability survey
4.6 Assurance measures
Assurance requirement Assurance
measures
Demonstration
ADV_FSP.1 Basic functional
specification
Development The development assurance measure provides all the necessary design documentation to
support the analysis of the TOE for an evaluation at EAL1.
The functional specification provides a detailed description of the security functions of
the TOE.
AGD_OPE.1 Operational user
guidance
AGD_PRE.1 Preparative
procedures
Guidance
documents
The operational user guidance documentation provides the guidance for end users,
administrators and other parties who will utilise the TOE.
These documents provide all the necessary instructions and direction for ensuring that
the TOE is installed, configured, used and administered in a secure manner.
ALC_CMC.1 Labelling of the TOE
ALC_CMS.1 TOE CM coverage
ALC_FLR.3 Systematic flaw
remediation
Life cycle support Configuration management measures provide the assurance that the TOE and supporting
evidence can be uniquely identified.
The life cycle support assurance measures provides a set of procedures aimed at the
identifying, reporting and addressing security flaws or bugs that may appear in the TOE.
ASE_CCL.1 Conformance claims
ASE_ECD.1 Extended components
definition
ASE_INT.1 ST Introduction
Security Target
evaluation
Security Target evaluation assurance measures ensure that the claim to EAL1
(augmented with ALC_FLR.3) can be accurately appraised.
39 of 52
40 of 52
Assurance requirement Assurance
measures
Demonstration
ASE_OBJ.1 Security objectives for
the operational environment
ASE_REQ.1 Stated security
requirements
ASE_TSS.1 TOE summary
specification
ATE_IND.1 Independent testing ‐
conformance
Tests The tests assurance measure ensures that the TOE has been appropriately tested for the
claimed set of security functions.
The test plans for the TOE identifies the set of security functions that are to be tested,
the procedures for establishing the test environment and also for conducting the test
cases.
The results of the tests are also recorded to provide evidence of test results.
AVA_VAN.1 Vulnerability survey Vulnerability
assessment
The TOE will be made available for vulnerability analysis and penetration testing.
5 TOE summary specification (ASE_TSS)
5.1 Overview
This section provides the TOE summary specification, a high‐level definition of the security functions
claimed to meet the functional and assurance requirements.
The TOE security functions include the following:
• Connection Filtering. The TOE protects from unwanted spam or Unsolicited Commercial E‐mail
(UCE) by blocking messages from specified IP addresses.
• Message Filtering. Filters potential spam messages based on Administrator configured SMTP
filters, including local and third party block/allow lists.
• Attachment Filtering. Provides a mechanism to filter potentially harmful attachments from
external networks.
• Transport Filtering. Allows the administrator to define mail policies to prevent specific internal
and/or external users from emailing each other.
• Access Control. Protects mailboxes and public folders from unauthorized access.
• Identification and Authentication. Provides identification and authentication mechanism for
the Outlook Voice Access functionality in cases where Outlook Voice Access is not secured by
the use of the TLS protocol.
• Distribution Group Restriction. Requires users sending mail to a distribution group to be
successfully authenticated and to be authorized.
• Remote device wipe. An Administrator can issue a command to wipe a Windows Mobile device
in the event that the device may have been compromised.
41 of 52
5.2 Connection Filtering
Exchange will reject SMTP connections based on IP address of the connecting external SMTP server7
. To
do so, Exchange references allow lists, block lists and a list of exceptional recipients. These lists which
may contain IP addresses or IP address ranges. The TOE references local and remote allow and block
lists. Local lists are defined by an authorized Administrator while remote allow and block lists are
retrieved from external service providers (so called block list service providers).
When an SMTP connection is established, Exchange enforces the following ordered rules, according to
the IP address of the external SMTP server:
• If the IP address of the sending SMTP server is listed on a local allow list, the message will be
accepted;
• If the IP address of the sending SMTP server is listed on a local block list, the message will be
rejected;
• If the IP address of the sending SMTP server is listed on a remote allow list, the message will be
accepted;
• If one of the recipients of the e‐mail is on the local list of exception recipients, the message will
be accepted;
• If the IP address of the sending SMTP server is listed on a remote block list, the message will be
rejected;
• Else the message will be accepted.
By default, the local allow and block lists that are used in this Security Function are empty.
The TOE also calculates the Sender Reputation Level (SRL) of a remote SMTP server after at least 20
mails have been received from this server. This SRL is a numeric value between 0 and 9 that serves as an
indicator of how likely the sending server is a spammer.
Further, the environment of the TOE maintains a local list of SRL values for known SMTP servers. This list
is updated on a regular basis.
7
An external SMTP server is an SMTP server logically outside the Exchange organization that connects to an Edge Server.
42 of 52
If the local SRL for a sending SMTP server or the calculated SRL has reached or exceeded an
administrator configurable value (the SRL Threshold which is 7 by default), the SMTP server will be
added to the local block list for an administrator defined period of time.
Functional Requirements Satisfied: FDP_IFC.1a (Connect), FDP_IFC.1b (SRL), FDP_IFF.1a (Connect),
FDP_IFF.1b (SRL),FMT_MSA.3c (Connect) and FMT_MSA.3d (SRL).
Security Management for Connection Filtering: The TOE will provide functionality to:
• manage local allow and block lists,
• manage the list of exceptional recipients,
• manage the use of remote block and allow lists,
• manage the use of the list of local SRL values, and
• configure SRL threshold settings and the period of time for which servers exceeding the
threshold will be added to the block list.
5.3 Message filtering
Exchange allows the administrators to configure the TOE to reduce spam received by an organization.
The Message Filter will accept or reject messages based on the rules of the following policies. By default,
messages will be accepted by this policy.
Messages will be rejected if:
• the sender listed in the MAIL FROM: field of the RFC 2821 message envelope is on the sender
filtering list, or
• the sender in the FROM header of the message (RFC 2822) is on the sender filtering list, or
• the MAIL FROM: field of the RFC 2821 message envelope is blank8
and the FROM header of the
message (RFC 2822) does not contain a valid email address, or
• the recipient listed in the RCPT TO: field of the RFC 2821 message envelope is on the recipient
filtering list, or
8
As this field can never be completely empty the term blank refers to a so called null address which is a MAIL FROM field that
contains only the characters "<>"
43 of 52
• the recipient does not exist in the local address book
Finally, the TOE evaluates the SPF record for the sending domain and stamps the result on the message.
This SPF record is published by domain servers in addition to their standard DNS information and
identifies the machines that are allowed to send emails on behalf of the domain. In this way, the SPF
record can help to identify forged addresses.
By default, the sender and recipient filtering list for this Security Function are empty.
Functional Requirements Satisfied: FDP_IFC.1c (Message), FDP_IFF.1c (Message), and FMT_MSA.3e
(Message).
Security Management for Message Filtering: The TOE will provide functionality to manage sender and
recipient filtering lists.
5.4 Attachment Filtering
The TOE applies an attachment filter to incoming mail based on the e‐mail attachments.
The TOE provides the administrator the ability to specify that messages that contain a specified
attachment or attachment type be subject to a predefined action. The Administrator can choose to
block the whole message while optionally advising the sender that the message was not delivered, or
remove the attachment and deliver the message. This policy is defined by the Administrator based on
the Attachment MIME Type or the Attachment extension.
The default policy is to remove all attachments of the following MIME types and extensions:
• MIME Type: application/x‐msdownload, message/partial, text/scriptlet, application/prg,
application/msaccess, text/javascript, application/x‐javascript, application/javascript, x‐internet‐
signup, application/hta
• Extensions: *.xnk, *.wsh, *.wsf, *.wsc, *.vbs, *.vbe, *.vb, *.url, *.shs, *.shb, *.sct, *.scr, *.scf,
*.reg, *.prg, *.prf, *.pif, *.pcd, *.ops, *.mst, *.msp, *.msi, *.psc2, *.psc1, *.ps2xml, *.ps2,
*.ps11xml, *.ps11, *.ps1xml, *.ps1, *.msc, *.mdz, *.mdw, *.mdt, *.mde, *.mdb, *.mda, *.lnk,
*.ksh, *.jse, *.js, *.isp, *.ins, *.inf, *.hta, *.hlp, *.fxp, *.exe, *.csh, *.crt, *.cpl, *.com, *.cmd,
*.chm, *.bat, *.bas, *.asx, *.app, *.adp, *.ade.
Functional Requirements Satisfied: FDP_IFC.1d (AttachmentFilter), FDP_IFF.1d (AttachmentFilter), and
FMT_MSA.3f (AttachmentFilter).
44 of 52
Security Management for Attachment Filtering: The TOE will provide functionality to manage the
Attachment Filtering Policy. This functionality will allow authorized Administrators to add or delete rules
to the Attachment Filtering Policy.
5.5 Transport Filtering
The TOE allows an administrator to configure a set of ordered rules that can be applied to all messages
passing through the Hub Transport server role. The Hub server will evaluate all the rules in order and
execute any rules that apply. By default, no rules exist for this policy initially.
The administrator can define rules for messages based on the following attributes of an email:
• Sender,
• Recipients,
• CC:,
• Subject,
• Classification,
• Header,
• Attachment name,
• Attachment size,
• Attachment extension,
• Importance, and
• Key words in Subject or email body.
Functional Requirements Satisfied: FDP_IFC.1e (Transport), FDP_IFF.1e (Transport), and FMT_MSA.3g
(Transport).
Security Management for Transport Filtering: The TOE will provide functionality to manage the Hub
Transport Policy. This functionality will allow authorized Administrators to add or delete rules to the Hub
Transport Policy.
45 of 52
5.6 Access Control
The TOE uses Role Based Access Control (RBAC) permissions for the Mailbox, Hub Transport, Unified
Messaging, and Client Access server roles. RBAC has two primary ways of assigning permissions to users
in the organization, depending on whether the user is an administrator or specialist user, or an end‐
user: management role groups and management role assignment policies. Each method associates users
with the permissions to control access to all functions and data within the TOE.
Mailbox permissions: The AccessRights parameter specifies the rights needed to perform the operation.
Valid values include:
• FullAccess
• SendAs
• ExternalAccount
• DeleteItem
• ReadPermission
• ChangePermission
• ChangeOwner
Public folders: The AccessRights parameter specifies the rights being added. This parameter accepts the
following values:
• ReadItems ‐ The user has the right to read items within the specified public folder.
• CreateItems ‐ The user has the right to create items within the specified public folder.
• EditOwnedItems ‐ The user has the right to edit the items that the user owns in the specified
public folder.
• DeleteOwnedItems ‐ The user has the right to delete items that the user owns in the specified
public folder.
• EditAllItems ‐ The user has the right to edit all items in the specified public folder.
• DeleteAllItems ‐ The user has the right to delete all items in the specified public folder.
46 of 52
• CreateSubfolders ‐ The user has the right to create subfolders in the specified public folder.
• FolderOwner ‐ The user is the owner of the specified public folder. The user has the right to
view and move the public folder and create subfolders. The user can't read items, edit items,
delete items, or create items.
• FolderContact ‐ The user is the contact for the specified public folder.
• FolderVisible ‐ The user can view the specified public folder, but can't read or edit items within
the specified public folder.
In addition to access rights, you can create rights based upon roles, which includes multiple access
rights. This parameter accepts the following values for roles:
• None ‐ FolderVisible
• Owner ‐ CreateItems, ReadItems, CreateSubfolders, FolderOwner, FolderContact, FolderVisible,
EditOwnedItems, EditAllItems, DeleteOwnedItems, DeleteAllItems
• PublishingEditor ‐ CreateItems, ReadItems, CreateSubfolders, FolderVisible, EditOwnedItems,
EditAllItems, DeleteOwnedItems, DeleteAllItems
• Editor ‐ CreateItems, ReadItems, FolderVisible, EditOwnedItems, EditAllItems,
DeleteOwnedItems, DeleteAllItems
• PublishingAuthor ‐ CreateItems, ReadItems, CreateSubfolders, FolderVisible, EditOwnedItems,
DeleteOwnedItems
• Author ‐ CreateItems, ReadItems, FolderVisible, EditOwnedItems, DeleteOwnedItems
• NonEditingAuthor ‐ CreateItems, ReadItems, FolderVisible
• Reviewer ‐ ReadItems, FolderVisible
• Contributor ‐ CreateItems, FolderVisible
Functional Requirements Satisfied: FDP_ACC.1 (Folder), FDP_ACF.1 (Folder), FMT_MSA.1 (Folder),
FMT_MSA.3 (Folder).
Security Management for Access Control: Exchange 2010 has implemented a new permissions model
termed Role Based Access Control (RBAC). The implementation of RBAC has removed the administrative
task of modifying and managing access control lists (ACLs).
47 of 52
RBAC allows administrators to control, at both broad and granular levels, what administrators and end‐
users can do. RBAC also enables administrators to more closely align the roles assigned to users and
administrators to the actual roles they hold within the organization. In Exchange 2010, RBAC now
controls both the administrative tasks that can be performed and the extent to which users can now
administer their own mailbox and distribution groups.
RBAC has two primary ways of assigning permissions to users in an organization, depending on whether
the user is an Administrator, a specialist user, or an end‐user: management role groups and
management role assignment policies. Each method associates users with the permissions they need to
perform their jobs. A third, more advanced method, direct user role assignment, can also be used.
Role groups:
• One or more Administrators can be members of a role group. They can also be members of
more than one role group.
• The role group is assigned one or more role assignments. These link the role group with one or
more administrative roles that define what tasks can be performed.
• The role assignments can contain management scopes that define where the users of the role
group can perform actions. The scopes determine where the users of the role group can modify
configuration.
Role assignment policies:
• One or more users can be associated with a role assignment policy.
• The role assignment policy is assigned one or more role assignments. These link the role
assignment policy with one or more end‐user roles. The end‐user roles define what the user can
configure on his or her mailbox.
• The role assignments between role assignment policies and roles have built‐in scopes that
restrict the scope of assignments to the user's own mailbox or distribution groups.
Direct role assignment (advanced):
• A role assignment can be created directly between a user or Universal Security Group (USG) and
one or more roles. The role defines what tasks the user or USG can perform.
• The role assignments can contain management scopes that define where the user or USG can
perform actions. The scopes determine where the user or USG can modify configuration.
48 of 52
Figure 2 – RBAC Overview
Functional Requirements Satisfied: FDP_ACC.1a (Folder), FDP_ACC.1b (Group), FDP_ACF.1a (Folder),
FDP_ACF.1b (Group), FMT_MSA.3a (Folder) FMT_MSA.3b (Group) and FMT_MSA.1 (Folder).
5.7 Identification and Authentication
The TOE will identify and authenticate all users connecting via non‐TLS secured Outlook Voice Access.
The identity of the user in the context of this Security Function is represented by the user’s mailbox
number or a telephone number that is transmitted from the PBX to the TOE (caller ID). When a user
initiates a phone call to OVA, the TOE references the associated Caller Id that is transmitted from the
PBX as an additional mechanism to identify the user. If the Caller Id matches a user, the user does not
have to enter their mailbox number, but still must enter their PIN prior to gaining access to any TOE
resources9
. If the Caller ID is not transmitted or the transmitted number has not been assigned to a
mailbox, the user is asked to enter their mailbox number. After this identification, the user is asked to
enter their PIN for authentication. After successful authentication, the TOE associates the calling user
with their corresponding Windows user account and the corresponding roles.
Please note that if the PBX establishes a connection over mutually authenticated TLS the authentication
is not enforced as the environment is responsible for user authentication in this case.
9
Please note that the caller ID and the mailbox number are only mechanisms for the TOE to map the calling user to their
corresponding ID.
49 of 52
Further, the TOE will ensure that PINs generated by administrators, the user or the TOE itself meet a
quality metric as defined by the administrator based on:
• the number of digits of the PIN,
• the history of the last PINs, and
• common patterns.
The TOE specifically ensures that a PIN has at least a length of 8 digits.
After the user has been successfully authenticated, the user’s identity is used to control the user’s
access to data to ensure that one user cannot access other user’s data via this interface.
Functional Requirements Satisfied: FIA_SOS.1, FIA_UAU.2, FIA_UID.2, and FIA_USB.1.
Security Management for Identification and Authentication: The TOE will provide functionality to
manage the attributes of users for Outlook Voice Access. Specifically this will allow Authorized
Administrators to manage the quality metric for Outlook Voice Access PINs.
5.8 Distribution Group Restriction
Exchange 2010 can place restrictions on how messages are delivered to individual recipients. Message
delivery restrictions apply to all recipient types and are used for controlling access to specific recipients.
An administrator can configure the following message delivery restrictions for a distribution group:
• Accept messages from a specific list of senders ‐ Specify a list of senders from which to accept
messages, the recipient will receive messages only from those senders. By default, all recipients
are configured to accept messages from all senders.
• Reject messages from a specific list of senders ‐ Specify a list of senders from which to reject
messages, the recipient will reject messages from those senders. By default, all recipients are
configured not to reject messages from any senders (this list has priority over the accept list).
• Require that all senders are authenticated – Setting that requires that all senders are
authenticated; any messages from senders that don't have valid logon credentials will be
rejected.
Functional Requirements Satisfied: FDP_ACC.1b (Group), FDP_ACF.1b (Group), FMT_MSA.3b (Group).
50 of 52
Security Management for Distribution Group Restriction: The TOE will provide functionality to:
• create and delete distribution groups, and
• configure message delivery restrictions.
5.9 Remote Wipe
Microsoft Exchange 2010 enables administrators to send a command to a mobile phone that will
perform a wipe of that phone. This process, known as a remote device wipe, clears all Exchange
information that's stored on the mobile phone.
The Remote Wipe function is implemented through the Exchange ActiveSync protocol, which is
established over HTTP by a managed mobile device connecting to the Exchange Server. In addition to
the Remote Wipe functionality, Exchange ActiveSync also provides mailbox synchronization, a suite of
additional auxiliary commands and the provisioning or establishment of policies on a mobile device.
In order for the Remote Wipe function to work, a device must support the Provision command
introduced in version 2.5 of the Exchange Active Sync protocol. For devices that do not support
Provision or the claimed ability to support policies, a remote wipe command essentially blocks the
device from syncing with Exchange Server.
Initiating remote wipe sets the following information in the device’s sync state that resides in the user’s
mailbox:
• WipeRequestTime: Current date/time
• WipeSendTime: Null
• WipeAckTime: Null
• LastDeviceWipeRequestor: SMTP address of cmdlet executor
• WipeConfirmationAddresses: SMTP Addresses specified in ‐NotificationEmailAddresses
parameter or Null if not present
Remote wipe initiation also causes any “hanging” command to complete by artificially deleting a custom
folder within the user’s mailbox thereby immediately returning a response to the device.
Any subsequent commands by a provisionable device will result in a response from the server with the
unique HTTP status code 449 telling the device to send up a Provision request. The server will respond
51 of 52
to this request with a status telling the device to remote wipe. At this time, WipeSendTime will be set to
the current data/time in the device’s sync state that resides in the user’s mailbox.
A non‐provisionable device, if allowed to sync by policy, will receive an HTTP status code of 403
(Forbidden) for all subsequent requests.
Upon receiving the status to remote wipe from the server, the device should send up its
acknowledgement Provision request with a remote wipe status value of 1 then promptly clear its
memory. When the server receives this acknowledgement request, it sets the WipeAckTime to the
current data/time in the device’s sync state that resides in the user’s mailbox.
Device wipe can be cancelled by a permissioned user with the Clear‐ActiveSyncDevice –Cancel
cmdlet/paramenter combination. The command is only valid if the server has not sent a Provision
response asking the device to wipe. This state is indicated by a valid WipeRequestTime date/time stamp
but a null value for WipeSendTIme in the device’s sync state that resides in the user’s mailbox.
Functional Requirements Satisfied: FMT_MOF.1 (Remote Wipe).
Security Management for Mobile Device Wipe: Through either the Exchange Management Console
(EMC) or Exchange Management Shell administrators can issue remote wipe commands.
52 of 52