| Version: | $Revision: 1.3 $ (Draft) |
|---|---|
| Date: | 2003-07-16 |
| Author: | Steve Alexander <steve@catbox.net> |
| Author: | Christian Theune <ct@gocept.com> |
| DocumentID: | ST_ZOPE_001 |
Version Date Change Editor 0.1 First draft Christian Theune
| Document Title: | Zope X3, Security target |
|---|---|
| Document ID: | ST_ZOPE_001 |
| Document Version: | |
| $Version$ | |
| Origin: | |
| TOE Reference: | Zope X3 |
| TOE Commercial Name: | |
| Zope X3 | |
| TOE Short Description: | |
| Platform independent, Python, XXX feature article from zope.org | |
| Product Type: | Web Application Server |
| Evaluation Body: | |
| Evaluation Body of TUV Informationstechnik GmbH, Germany | |
| Certification Body: | |
| Certification Body of TUV Informationstechnik GmbH, Germany | |
This ST is based upon Common Criteria, Version 2.1 ([CC]). The TOE consists of the following component:
Component Version Supplier Zope X3 Zope Corporation
The main objectives of this Security Target are:
- To describe the Target of Evaluation (TOE).
- To describe the security environment of the TOE including the assets to be protected and the threats to be countered by the TOE and its environment.
- To describe the security objectives of the TOE and its supporting environment.
- To specify the Security Requirements, which include the TOE security functional requirements as of CC, part 2 and the assurance requirements as of CC, part 3.
- To set up the TOE summary specification, which includes the TOE security functions specifications and the assurance measures.
This ST is claimed to be conformant with the ISO/IEC 15408:1999 (Common Criteria, Version 2.1 with final interpretations, see [CC]) and its following parts:
- Part 2 and
- Part 3, EAL1.
The assurance level is EAL 1.
For b uilding Web application, framework, ... Functionality should be provided, main structure
Product type: Web application server software that provides functionality for restricting operations on objects based on permissions declared to protect those operations.
Principals are granted permissions both statically via configuration files and dynamically via settings in the object database.
You can use roles to mediate between principals and permissions.
Principals are authenticated in various way depending on the means of connection to a server. Authentication usually envolves a username-password such as for FTP-Authentication and HTTP-Basic-Authentication. Other authentication mechanisms are possible.
Only authorised persons can modify the Zope source code.
The official / canonical version of Zope is held by Zope Corporation (ZC) in the ZC the repository.
The certified version is held as a named branch in the ZC repository.
Open source
All changes to source code and other files in the repository are reported publically to interested persons including those persons that are responsible for overseeing the quality and direction of parts of Zope.
Any change to a file in the repository causes that file to have a new version number and the exact change is recorded.
describe releases here
The whole Zope package.
Access Control functionality.
Default username-password authentication mechanism.
Publishing mechanism.
The following assets have been identified:
Asset Name Description Content-Objects Operations Principals Principals Role grants Permission grants Audit data
Outside of Zope the "system-administrator" configures the Config-files as an initial step before the first starting of Zope occurs.
Subjects are instantiated principals.
Principals are represented by a unique ID, credentials and metadata.
Credentials are identification and authentication data like username and password.
Metadata are related information of the principal, just additional information to the principal.
The ID is the data the system internally identifies the user.
There are two kinds of principals: The anybody-user and the authenticated user.
If a principal has the permission to grant permissions/roles he can grant permissions/roles to himself and other principals.
Roles are used in applications of Zope to express the different tasks and responsibilities of users. Permissions are granted to roles and roles are granted to principals. Therefore roles serve as an indirect means of granting permissions to principals. Permissions can also be granted directly to principals.
Permissions guard operations on objects. A permission has an unique ID.
Operations are performed on objects. They are defined in an objects class. A class is defined in the Python programming language and is identified by a fully qualified name.
A operation is a name defined in a class. It may take a form of an attribute, a method or some other related python thing.
There are two possible kinds of access to an operation: Reading such as reading an attribute or calling a method. Writing such as setting or deleting an attribute. Reading is guarded with a different permission than writing.
The following assumptions need to be made about the TOE environment:
Assumption Name Description A.OS The machine and the operating system Zope is running on is physical secure. A.Admin The "system-administrator" of the above mentioned machine is trustworthy. A.Network A network connection to the Zope services is present. All The other network connection are secure in such a way that the integrity of the machine and operating system is preserved. A.Client The connection between client and Zope server is secure in a sense the the identification and authentication data is not monitored or interfered. A.Credential The user is keeping the credential to authenticate secret. A.Integrity The system is administrated such that the system is free from malicious software like viruses and Trojan horses.
The following threat agents have been identified:
- Users having correct authentication credentials who might try to acquire more permission or role grants to get access to operations they shall not.
- Users without correct authentication credentials for a certain principal trying to authenticate as this.
The following threats against the assets have been identified:
Threat Threat description Asset T.IA An attacker might impersonate an authorised principal without providing the necessary credentials. Principal T.PermRole A principal changes the role grants or permission grants without having that right. Permission grants, Role grants T.Operation A principal performs an operation on an object without having the correct permission. Operation, Object
Threat proposed threats T.AuditDOS An attacker might misuse the audit data generation functions to flood the server with data resulting in the denial of service. T.AuditFake An attacker might convince the audit data generation functions to log false information (date, time, type of event, outcome, user) T.Import An attacker might try to make the system interprete imported security attributes in a not intended way to acquire a higher level of access to the system. T.RIP An attacker might try to make the system use residual information for deciding to allow or deny access to an operation to gain more access than intended. T.Transaction An attacker might try to perform commit or abort operations on foreign transactions to perform operations on the behalf of other users. T.Rollback An attacker might try to perform a rollback to invalid revisions. T.USB An attacker might try to use executable code which runs on behalf of another user to perform unauthorised operations and maybe hide his traces. T.Timestamps An attacker might try to hide his actions by making the system create false timestamps which would result in wrong association to a user on dynamic ip address ranges. T.TrustedPath An attacker might try to use "user data import" or "user data export" without beeing a local user and using the trusted path.
The following OSP have been identified:
OSP Description OSP.Source_code_changes Changes to source code can only be made by persons who have signed an agreement with Zope Corporation, Virginia USA. They must preserve a cryptographic key in order to change code. OSP.Version_number Released versions of Zope cannot be modified. Any modification would imply a new release number.
The following security objectives have been defined for the TOE:
Objective Name Description O.IA All principals must be identified and authenticated with the exception of "anybody"-principal. O.Objects A principal can perform an operation on an object only if he has the permission. O.Grants Only principals having the permission to change permission/role grants can change the permission/role grants. O.Access Access to objects is only possible via operations.
The following security objectives have been defined for the TOE environment:
Assumption Name Description OE.OS The machine and the operating system Zope is running on is physical secure. OE.Admin The "system-administrator" of the above mentioned machine is trustworthy. OE.Network A network connection to the Zope services is present. All The other network connection are secure in such a way that the integrity of the machien and operating system is preserved. OE.Client The connection between client and Zope server is secure in a sense the the identification and authentication data is not monitored or interfered. OE.Credential The user is keeping the credential to authenticate secret. OE.Integrity The system is administrated such that the system is free from malicious software like viruses and Trojan horses.
Operating System, Python Version, Browsers (Can't assure about browser behaviour), ZODB Storage
The following functional requirements identify the TOE functional requirements. They have beend drawn from the CC Part 2 functional requirements components.
The TSF shall be able to generate an audit record of the following auditable events:
The TSF shall record within each audit record at least the following information:
The TSF shall allow [only those operations granted to the anonymous principal] on behalf of the user before the [principal] is authenticated.
[Note: It is possible to deny all operations to the anonymous principal. This means that a user must login before any operations may be performed on their behalf. This fullfills the terms of FIA_UAU.2]
The TSF shall allow [only those operations granted to the anonymous principal] on behalf of the user before the [principal] is identified.
[Note: It is possible to deny all operations to the anonymous principal. This means that a user must login before any operations may be performed on their behalf. This fullfills the terms of FIA_UID.2]
The TSF shall associate the appropriate user security attributes with subjects acting on behalf of that user.
[Note: This has to do with ownership in the sense of responsibility for executable code.]
This is currently not sure if it is going to be implemented. Ask someone who knows.
FIA_SOS.1 FIA_AFL.1
The Evaluation Assurance Level chosen for this Evaluation is EAL 1.
The following TOE assurance requirements drawn from CC Part 3 are valid:
Identification Description Direct dependencies ACM Configuration management (CM) ACM_CAP.1 Version numbers None ADO Delivery and Operation ADO_IGS.1 Installation, generation and start-up AGD_ADM.1 ADV Development ADV_FSP.1 Informal Functional specification ADV_RCR.1 ADV_RCR.1 Representation correspondence: Information correspondence demonstration None AGD Guidance documents AGD_ADM.1 Administrator guidance ADV_FSP.1 AGD_USR.1 User guidance ADV_FSP.1 ATE ATE_IND.1 Independent testing - conformance ADV_FSP.1 AGD_ADM.1 AGD_USR.1
The following security requirements exist for the IT environment:
The following security requirements exist for the IT environment:
The following security functions have been determined:
TSF Description TSF_AUD Audit TSF_DATA Data im-/export TSF_RIP Residual information protection TSF_IA Identification and authentication TSF_ACC Access control TSF_ROLL Rollback
example The TSF does not allow any kind of transactions until the principal has presented his username and password. The length of the password is at least 6 characters.
A functional specification and a RCR document will be provided.
No deliverable. Only independend testing from the evaluator is needed. Operating Environment Boundaries:
There are no PP claims.
There is no SOF claim here for EAL 1.
The choice of assurance requirements is based on the analysis of the security objectives for the TOE and on functional requirements defined to meet these objectives.
The assurance level is EAL 1.
XXX review this paragraph please.
The Zope development community recognizes the need of mature and well defined security functions by its users.
Therefore to meet this requirements the decision for an entry level evaluation was made in respect to the resource constraints of available developers and budget.
Additionally an entry level evaluation gives a glance to the community how certification may effect Zopes degree of documentation and stabilize the good security history even more, maybe raising the interest for projects that require good security behaviour and seek free alternatives.
It is intended to show that mature open source projects can outperform proprietary systems not only on pure functional and monetary aspects but also in domains that are typically governed by proprietary systems.
- Bibliographic references
- Numbering of sections would be fine
- Threat agents
- TOE description
- TOE security functions
- Rationale
What about the "nice to have" functions?
- What does FDP_ETC.2.3 mean?
- Are DOS within the range of possible threats?
- Review threats/threat agents