From ImageWeb

UNDER CONSTRUCTION - comments to graham dot klyne at zoo.ox.ac.uk please.

Contents 1 Security model 1.1 User security and confidentiality requirements 1.1.1 Security policy (Silk Group) 1.1.2 Security policy (Development Group) 1.2 Assets and principals 1.3 Threats 1.4 Architecture 1.4.1 Physical 1.4.2 Logical 1.4.3 LSDS Internal 1.5 Technical capabilities susceptible to subversion 1.6 Trust claims and assumptions 1.7 Threat mitigation options 1.7.1 Accidental disclosure by validly accredited user 1.7.2 Accidental corruption or deletion by validly accredited user 1.7.3 Technical mechanisms allow agent without credentials to access data 1.7.4 Attacker obtains legitimate user credentials through deceit or brute-force attack 1.7.5 Attacker without credentials gains access to data by subverting technical mechanisms 1.7.6 Attacker without credentials gains access to credentials by subverting technical mechanisms 1.7.7 General 1.8 Authentication mechanisms 1.9 Access control mechanisms 1.10 Functional (observable) security requirements 2 Notes 3 Comments

Security model

User security and confidentiality requirements

General desiderata:

• As a top priority, saved data must be protected from corruption or loss - i.e. unauthorized modification or deletion
• As a secondary priority, saved data must be protected from leakage - i.e. unauthorized disclosure
• Only authorized users may access data
• Only authorized users may create data files
• Only authorized users may modify or delete data files
• The research group leader can always access data created by other group members
• Data created by one group member may be kept confidential from other users, at the discretion of the group leader
• Access to data may be allowed to selected external collaborators (for read, create and/or modify+delete)

The following sections attempt to render the above to a "security policy" for each of the research groups we are dealing with, along the lines of Andserson p170, etc., and is organized around broadly similar headings.

Security policy (Silk Group)

This security policy reflects requirements of the Silk Group

• Resources: the protected resources are data files stored by the Admiral system.
• Ownership: each data file is considered to be owned by the researcher who created it. Ownership of a file is not transferrable.
• Access: the owner of a file, and the research group leader, may access a file.
• Copying: anyone who can access a file can create a copy in a group shared area where other group members also may access it.
• Sharing: anyone who can access a file can create a copy in a collaborators shared area where other selected external collaborators may also access it.
• Modification: only the owner of a file may modify its content.
• Persistence: only the owner of a data file may delete it. If the owner becomes unavailable, this element of control transfers to the research group leader.
• Attribution: the creator of any data file shall be clearly identified (this follow from the preceding policy statements).
• Aggregation: anyone who can access the data may combine it with other data in any way they choose.

The intent here is to ensure that, in the normal course, only the creator of some data may delete it. In extremis, that responsibility may pass to the research group leader. The intended mechanism for transferring control of some data to another researcher is to make a copy which is then owned by the second researcher. This hopefully avoids confused provenance of a given data file.

Security policy (Development Group)

This security policy reflects requirements of the Development Group

• Resources: the protected resources are data files stored by the Admiral system.
• Ownership: each data file is considered to be owned by the researcher who created it. Ownership of a file is not transferrable.
• Access: the owner of a file, other research group members, and the research group leader, may access a file. Selected files created by the research group leader are not accessible by other research group members. File access may be as a local network file share, or as a Web resource.
• Copying: anyone who can access a file can create a copy in a group shared area where other group members also may access it.
• Sharing: anyone who can access a file can create a copy in a collaborators shared area where other selected external collaborators may also access it.
• Modification: only the owner of a file may modify its content. When a file is copied, the copy is considered to be owned by the person who makes such copy.
• Persistence: only the owner of a data file may delete it. If the owner becomes unavailable, this element of control transfers to the research group leader.
• Attribution: the creator of any data file shall be clearly identified (this follows from the preceding policy statements).
• Aggregation: anyone who can access the data may combine it with other data in any way they choose.

The intent here is to ensure that, in the normal course, only the creator of some data may modify or delete it. In extremis, that responsibility may pass to the research group leader. The intended mechanism for transferring control of some data to another researcher is to make a copy which is then owned by the second researcher. This hopefully avoids confused provenance of a given data file.

Assets and principals

The primary asset is research data.

Secondary assets are personal information and credentials.

Principals:

• IT support
• Research group leader
• Research group member
• Research group collaborator
• Research LSDS environment system
• Virtual hosting environment
• Local user systems
• Remote user systems

Threats

Broadly, we are concerned with protecting against two threats:

• Unauthorized creation, modification or deletion of research data or credentials
• Unauthorized disclosure of research data or credentials

More detailed instances of these include:

• Accidental disclosure by validly accredited user
• Accidental corruption or deletion by validly accredited user
• Technical mechanisms allow agent without credentials to access data
• Attacker obtains user credentials through deceit or brute-force attack
• Attacker is able to access data without credentials by subverting technical mechanisms
• Attacker obtains user credentials by subverting technical mechanisms

The technical mechanisms concerned are discussed later.

Architecture

Physical

Logical

LSDS Internal

Technical capabilities susceptible to subversion

This is intended to induce consideration of a range of possibilities, and should not be considered exhaustive.

• Network: traffic monitoring
• Network: traffic injection/replay
• User system: capture of credentials
• User system: diversion of data
• User system: modification of data
• Server system: defeat authentication mechanism
• Server system: authentication supplies wrong UID/GID
• Server system: defeat HTTP/Apache access control authorization
• Server system: defeat CIFS/Samba access control authorization
• Server system: defeat file system UID/GID access controls
• Server system: file system uses incorrect UID/GIUD when creating files
• Server system: local applications run with wrong process UID/GID
• Virtual hosting system protection mechanisms bypassed

Trust claims and assumptions

• IT support are the sole keepers of virtualization platform access credentials, and are both trustworthy and competent.
• The virtualization host environment is secure, and effectively isolates the different virtual systems that it hosts
• Each research group uses a separate virtual machine, and hence in an administrative domain that only they control
• Authority for granting access to data is vested in the research group leaders, who may delegate day-to-day management and control.
• Server systems are generally trustworthy and behave as configured with regard to access control
• Standard software components use authentication and authorization service returns correctly (e.g. Samba applies the right UID/GID when accessing files).
• Local user systems are generally considered to be trustworthy, to the extent that software on them is assumed to handle credentials in a proper fashion

• The local network is NOT secure: non-authorized persons may observe or insert traffic
• Remote user systems are generally considered to be untrustworthy; credential-handling mechanisms could be subverted

Threat mitigation options

Accidental disclosure by validly accredited user

• Accidental disclosure of individual files is probably not possible to prevent without placing undue constraints on day-to-day working, as files will frequently be copied in the normal course of events.
• Encryption might help, but is likely to be too much effort for most files.
• For particularly valuable or sensitive data, independently-keyed encryption might be considered.
• The likelihood of accidental disclosure en mass can be reduced by using a fixed access control framework with very clear, well-understood effects.
• Restrict access to underlying access control mechanisms so that users can't subvert the access control mechanisms through ill-considered changes (e.g. restrict use of setfacl)

Accidental corruption or deletion by validly accredited user

• Backup
• Versioning

Technical mechanisms allow agent without credentials to access data

• Review security model
• Monitor access and flag unexpected (unauthenticated) access
• Regular testing that functional requirements are satisfied

Attacker obtains legitimate user credentials through deceit or brute-force attack

• Normal procedures for education and maintaining user awareness of the range of threats
• Periodic change of credentials
• Lock-out mechanisms in the event of repeated authentication failures

Attacker without credentials gains access to data by subverting technical mechanisms

These mechanisms should work for all kinds of access: read, modification and deletion.

• Network endpoints are mutually authenticated, and traffic encrypted
• User systems should observe normal security precautions (anti-virus, firewalls, etc.)
• Proven and maintained authentication mechanisms should be used, preferably widely used and open source
• Linkage between authentication mechanism and access control mechanisms should be tested regularly tested, especially in new software releases
• Linkage between authentication mechanism and ownership of newly created files should be tested regularly tested, especially in new software releases
• Proven virtual hosting system, preferably widely used and open source, and well-understood by IT support
• Virtual hosting system housed in physical space with restricted access

Attacker without credentials gains access to credentials by subverting technical mechanisms

All the mechanisms for protecting data apply here.

Also:

• Restricted access to credentials
• Try to limit occasions on which credentials must be presented
• Limit the range of circumstances under which credentials may be modified.
• For remote access, use a one-time credential mechanism (time-based, challenge-response, etc.)

General

• System monitoring and "tripwire" mechanisms
• Automatic application of system security updates

Authentication mechanisms

Research group members and the leader each have personal credentials for identifying themselves to the system.

Research group collaborators may authenticate using individual or a common credential shared by multiple collaborators.

Authentication is provided primarily by LDAP, using locally managed credentials.

We would prefer to use the University Kerberos service for this, but have found that client support is rather patchy, and also that the Kerberos support in Apache WebDAV is rather unreliable.

Kerberos support for WebAuth HTTP access works well enough.

Later, we may try to re-introduce Kerberos authentication alongside LDAP. We would still rely on LDAP for mapping to local UIS/GID values, and also for other authorization data.

Access control mechanisms

There are two modes of operation for access control:

• Mapping to local UID/GID values, then using local system access control mechanisms. This covers access via CIFS and SSH (including SCP/SFTP).
• Access via HTTP and the Apache server, which in turn is granted full access to all data areas. We rely on Apache imposing the correct access controls based on information maintained in the LDAP directory.

We use Linux ACL support to achieve this. A fuller discussion of the access control mechanisms and configuration is at http://imageweb.zoo.ox.ac.uk/wiki/index.php/ADMIRAL_ACL_file_access_control. This script @@ref is used to add new users and data areas, and performs the necessary steps to set up the access lists appropriately.

Note that, while the initial ACL setup is handled by the script, the mechanisms can be subverted if users override the access controls. Our expectation is that, as long as the system just works as intended, they won't be motivated to do this. This is, however, a security risk.

Functional (observable) security requirements

@@TODO review, and consider functional requirements for collaborators

• One virtual machine per research group: rely on VM isolation to enforce distinct security administration domains, and to prevent leakage of credentials and data between groups
• Data modification or deletion should be restricted from remote systems: irrevocable modification or deletion is achievable only through local mechanisms
• Each research group member is allocated a data storage directory, which they may organize as they see fit. Only the owner may create, modify or delete files in this area.
• A separate file area, in which all research group members may create, modify and access files (how is file ownership handled?)
• A public file area, in which all group members may create, modify and access files, and external collaborators with appropriate credentials may read data files.
• Only designated users may modify access control permissions and allocate or delete user credentials

Unresolved possibilities, assumed to be non-requirements for now:

• Collaborative data areas, where a small subset of researchers can all create and modify data. How to control access?
• How to track provenance in shared file areas?
• Ownership/provenance tracking for files created via HTTP.

Notes

A number of sources were used to guide the construction of this security model, probably in rather haphazard fashion. For more information, see Security Modelling Notes.

Comments

bencc @gklyne Also, I'd be concerned that apache user appears to have a lot of access in that model, unless I'm missing something?

bencc @gklyne Is malicious disclosure by validly accredited user likely to be something you should consider?