Gebhard's Site
Gebhard's ramblings and content links.

Operations and Security of ownCloud

gebhard ,

Preface

This is an English summary of the German paper "Betrieb und Sicherheit von ownCloud" (V1.0 2015-06-16) of "Bundesamt für Sicherheit in der Informationstechnik" (Federal Office for Information Security Germany) available for download here. Please note that this English translation is my own (so all errors and language issues in this post are also my own šŸ˜‰ ) and that I have the approval of writing this summary by BSI (2015-06-22).

The content of some external references to the BSI Grundschutz is still German – sorry for that. The English version of the catalogue ("IT-Grundschutz-Catalogues") can be found here (attention – big file, >4000 pages), the numbers below correspond to the pages in this PDF.

The focus of this blog post was to create something like a bullet-point summary out of the very comprehensive publication. Readers who understand the German language are encouraged to also read the original paper. This is not a security concept nor a risk analysis (see e.g. [de]: BSI-Standard 100-3 / [en]: BSI Standard 100-3: Risk Analysis based on IT-Grundschutz). The focus is on the main file sharing functionality, not on the apps which can be added (e.g. calendar, contacts, …).

Before using ownCloud (or any other cloud or web application) make sure to think about the future operation model and the risks associated with it:

  • on premise vs. hosted
  • ownCloud architecture
  • storage
  • operation model
  • user directory
  • risks and risk analysis
  • etc.

General Threats: Operation Models

Operated on Premise with Internal Employees

same threats as for other applications on servers (data center operations), e.g.

Operated on Premise with External Employees

  • additional risks, e.g.:

    • other / more external administrators (no direct control)
    • more (uncontrolled) maintenance access paths
    • risk imposed by other IT systems / networks also operated by the service partner
    • no direct control over processes, IT systems, interfaces of the service partner
  • main issues:

    • outage of a network (WAN)
    • contractual issues
    • unauthorized contracts with (other) external service partners (sub contractors)
  • see also [de]: "B 1.11 Outsourcing" / [en]: "M 1.11 Outsourcing" (p. 86)

Externally Hosted

  • additional issue: uncontrolled environment
  • main issues:

    • outage of a network (WAN)
    • contractual issues
    • unauthorized contracts with (other) external service partners (sub contractors)
    • connection to internal directory / file services
    • trust relationships between internal and external IT systems
  • see also

Cloud

  • main risks as hosted solution
  • but often no real "private" networks, only based on protocol security
  • often directly accessible from the Internet w/o restrictions
  • this is also true for internal resources needed (e.g. SharePoints, directory services, file services, …)
  • if directly accessible from the Internet: this highly increases the probability of occurence for some risks
  • see also

ownCloud Specific Threads

  • independent of the operation model
  • see also [de]: "B 5.3 Groupware" / [en]: "M 5.3 Groupware" (p. 329)

Disclosure of Sensitive Information

  • exchange of files with all users of the service
  • internal users as well as external users
  • risk of orphaned users (not within the organization anymore)
  • risk of disclosure to other internal users who should not get access to the files
  • cause of disclosure:

    • unintentional / accidential action of user
    • intentional action of user
    • unintentional / accidential configuration error
    • software bug

Malicious Software

  • distribution of malicious software
  • execution on internal devices

Unauthorized Usage

  • user administration is essential
  • service is available in general and accessable for internal and external users
  • risk of users, who don't need access anymore, but still having access to sensitive information
  • internal access management process has to be extended to also include external users
  • example: external consultants only need access during the project and assignment time span
  • remember: the sharing service is normally reachable from the Internet so access management is the only barrier
  • probability of occurence is very high; amount of damage may also be very high

Security Measures

  • security of an application is generally dependent on:

    • security measures on all IT systems
    • security measures of the infrastructure
    • trustworthiness of the adminstrators and users
  • the following points are thought to be applied for the operation of ownCloud for

  • the maximum level of all considered protection requirements has to be taken into account
  • not every organization can implement all measures
  • the threat can't be eliminated by a measure, but the probability of occurence and / or the extend of damage can be lowered

Planning of Operation and Protection

  • sharing application has to comply with technical and organizational dependencies and regulations
  • the planning has to be carried out with all involved teams in advance
  • questions to be answered during the analysis:

    • what is the objective for operating this service?
    • what is the expected load regarding data and access requests?
    • what is the protection level of the data?
    • which teams and persons are allowed to access the service?
    • what availability is needed?
    • what expertise is internally available and which should be built up?
  • questiions to be answered for operation:

    • what is the operation model?
    • how many servers are needed (data bases, storage systems, web servers, load balancers, etc.)?
    • should the service be distributed over several places?
    • access via VPN or directly from the Internet?
    • in which network segment should which parts of the service be placed?
    • should external storage (Amazon, Google, Dropbox, …) be connected?
    • which internal storage (Shares, SAN, SharePoints, …) should be connected?
    • which authorization concept should be used, e.g. what user groups should be set up to allow only the really needed access?
    • which additional apps are required?
    • are adoptions to the out of the box service needed (e.g. self maintained apps)?
  • the answers to these questions are the groundwork for the catalog of requirements
  • the implementation of the resulting security measures has to be ensured
  • see also

Regulations for Usage and Security

  • the defined requirements for security and the planned usage result in a obligatory policy for administrators and users
  • the policy should contain:

    • who is authorized to use the service
    • which security measures have to be followed
    • no usage of the service without authorization and authentication
    • how to handle sharing links (with or without password)
    • which data is allowed ot be distributed
    • who is eligible recipient of data
    • who is to be informed of deliberate or accidential transfer of data to unauthorited parties
  • see also [de]: "M 2.455 Festlegung einer Sicherheitsrichtlinie für Groupware" / [en]: "S 2.455 Defining a security policy for Groupware" (p. 2284)

Planning of App-Usage

  • during planning phase it should be decided which apps are needed for functionality and security reasons
  • requirements for apps:

    • only required apps are allowed to be installed
    • minimize the count of apps installed
    • prefer apps of ownCloud vendor over open source / externally developed apps
    • if apps from other vendors are required:

      • apps must be checked for security
      • there must be a process for notification of new versions
    • self developed apps must be created obeying rules of secure software development and checked for security

Authorization for Sharing Data

  • only admins are allowed to assign or remove authorization
  • authorization to share data should be minimized
  • all authorizations must be documented separately because ownCloud doesn't offer this functionality
  • the authorization has to be justified by an internal employee
  • the authorizations must be reviewed regularly (e.g. every two years)
  • not required authorizations must be revoked and removed
  • admins can configure authorization in the following ways:

    • users are allowed to share data (e.g. based on group membership)
    • users are allowed to share data publically
    • users must set up an expiration date for shared data and / or set up password protection
    • limitation of re-sharing
    • users may allow upload for third parties
    • users may set up email notifications
  • IT security has to approve authorization to share data externally by request of internal users and has to review approvals at least once a year

Training of Users

  • before usage of the service training of functionality, risks and regulations is necessary
  • training material should be accessible at all times (not only during training itself)
  • content of trainings:

    • usage of the service
    • purpose and scope of the service within the organization
    • regulation / policy of secure usage
    • how data is classified so that respective rules from the policy can be applied
  • see also [de]: "M 3.45 Planung von Schulungsinhalten zur Informationssicherheit" / [en]: "S 3.45 Planning training contents on information security" (p. 2504)

Architecture and Security Gateways

  • architecture should take into consideration future usage
  • requirements regarding availability, sizing, speed and security must be defined and obeyed (e.g. by setting up redundancy)
  • network best practices (implementation of segmentation, security devices, …) have to be followed
  • shared usage of IT components must obey the protection levels of the respective data
  • see also

Roles and Rights Management

  • rights are definied by group membership (manually or via directory service)
  • admins plan and implement the necessary roles based on requirements
  • a compromise should be agreed on between "too many roles" vs. "too much power"
  • roles and their implementation must be reviewed regularly
  • see also

Local Authentication

  • only in very small implementation local authentication (within ownCloud itseld) is recommended
  • see also [de]: "M 4.392 Authentisierung bei Webanwendungen" / [en]: "S 4.392 Authentication for web applications" (p. 3447)

Authentication using Directory Service

  • users, which are authenticated by a directory service (e.g. LDAP) are locally created by ownCloud during first logon
  • deletions / deactivations in the directory service are not automatically replicated into ownCloud
  • so regular deletion of users within ownCloud is necessary
  • this can be automated if LDAP is used, see configuration directive ldapUserCleanupInterval
  • important: if users are deleted, then their directories / files are deleted, too
  • make sure to use a technical user for ownCloud to access the LDAP with necessary rights (e.g. search has to be allowed)
  • communication to directory services must be encrypted; certificates must be checked
  • caching of successful logins should be considered (e.g. for one hour) to reduce load
  • the approval to use ownCloud is to be defined using an LDAP attribute (e.g. by member-of-overlay or filter)
  • group membership in ownCloud is defined by LDAP groups (e.g. by attributes in LDAP or predefined groups in ownCloud)
  • be careful if connecting ownCloud to more than one directory: the uniqueness of users must be ensured even when duplicate user IDs are possible in the different user directories
  • take LDAP clustering into consideration if high availability is required
  • usage of other directories (e.g. IMAP, SMB, FTP, …) is discouraged because extended attributes (e.g. groups, roles, … ) and / or encryption of the connection is not supported

Authentication using Federated-ID

  • scenario: connect persons outside of the organization
  • user administraion for other organizations within ownCloud itself is discouraged because of maintenance problems (e.g. access revocations)
  • alternative: use Federated-ID service and connect directories of other organizations (e.g. Shibboleth and other IDPs (SAML 2.0))
  • the same issues as with LDAP occur (local users are created during first login, no local user deleted if deleted in directory, etc.)
  • make sure to test and verify trust relationships (tokens)
  • a contract defining the policy of user creation, authorization, etc. is needed for the external organization

Use of Encryption

  • communication: TLS on the web server (make sure to keep an eye of the ever changing security situation in this field)
  • data at rest on the server (ownCloud as encryption gateway):

    • data is encrypted at rest (e.g. on the storage system), but user receives unencrypted content
    • only the data is encrypted; meta-data (e.g. file name) is still in plain text
    • asymetric encryption (public and private key per user)
    • public key is used to encrypt data
    • generated private key (for decryption) is encrypted using a password derived from the user's password
    • this implies: no encryption possible if tokens (federated-ID authentication) are used tor user authentication
  • encryption policy should be defined and implemented
  • data at rest outside the organization should be encrypted
  • see also [de]: "M 5.66 Verwendung von TLS/SSL" / [en]: "S 5.66 Use of TSL/SSL" (p. 3693)

Secure Configuration

Usage of External Storage

  • examples: Dropbox, Google Drive, Amazon S3
  • make sure to obey the respective data protection levels and internal IT security policies
  • if external storage is used, external networks are utilized which are not within control of the organization
  • the usage of a security gateway is therefor necessary
  • only admins should have the right to connect external storage
  • a user of the storage provider should be set up as a non-personal technial account and used for this purpose
  • make sure to use a complex password and change it on a regular basis
  • set up monitoring for the external storage
  • make sure to understand limitations of data encryption on the external storage

Connection to SharePoint

  • SharePoint lists can be integrated in ownCloud and are shown as directories to the user
  • user credentials or a technical account can be used to authenticate to SharePoint (on a per list basis)
  • no encryption possible if using tokens (federated-ID authentication)
  • technical user can't be used if the SharePoint list uses per-user views or per-user authentication
  • if a per-user authentication to SharePoint is used: the directory servics (for ownClound (e.g. LDAP) and for SharePoint (AD)) must be in sync

Home Directories

  • usage of home directories is possible (in an LDAP – AD configuration)
  • this should be decided and regulated in advance

Virus Scanning

  • ClamAV integration is possible out of the box
  • due to limitations of this software the integration of a commercial product (possible since version 7 using the anti-virus app) is recommended
  • see also [de]: "M 4.3 Einsatz von Viren-Schutzprogrammen" / [en]: "S 4.3 Use of virus protection programs" (p. 2639)

Creation of Directories

  • users and admins can create directories
  • if a user is deleted, all directories which are owned by the user are deleted as well
  • therefor directories should be created centrally by admins
  • make sure to use a dedicated, non-personal account for this to prevend unintended deletion of directories

"Firewall"

  • ownCloud can further restrict the distribution (share / transfer) of files
  • the mechanism is analogous to a firewall and is done in the central configuration file
  • dependend on the required protection level this should be considered, documented, planned and implemented
  • starting with ownCloud 8 the configuration can be done from within the web interface based on the following attributes:

    • IP address
    • file name including path
    • subnet
    • up- or download
    • user / group
    • time
    • size
  • see also [de]: "M 2.71 Festlegung einer Policy für ein Sicherheitsgateway" / [en]: "S 2.71 Determination of a security gateway policy" (p. 1383)

Server-to-Server Sharing

  • the connection to another ownCloud server should only be allowed for admins
  • make sure to double check the necessity and protection class of the data before implementing
  • if possible make use of password protection for each server shared directory
  • restrict the right to set up connections esp. for non-password protected server shares
  • document the life time and access rights for each server share
  • make sure the protection class is visible for / transparent to the user
  • server shares should be reviewed and the password should be changed on a regular basis
  • if the link travels public networks: transport encryption must be used and certificates checked

Logging and Monitoring

  • availability and resources of the ownCloud servers should be monitored
  • web server and ownCloud logs should be stored locally or better transferred to a central logging server and analyzed for anomalies
  • make sure to obey data protection laws
  • see also

Connection to Access Management

  • ownCloud has an API for provisioning of local users
  • so ownCloud can be integrated into organization wide IAM systems and processes
  • this is especially recommended if no directory service (like LDAP) is used

Measures Depenent on the Operation Model

Operated on Premise with Internal Employees

  • the organization is solely and completely responsible for the security of the service, the data and IT systems
  • ownCloud should be managed within an ISMS

Operated on Premise with External Employees

  • the responsibility stays within the organization
  • only the implementation is transferred to the external partner
  • therefor it is essential to have a contract defining security targets and specific requirements based on the needed protection level
  • especially important:

    • processes for seamless integration of user management
    • rights assignment for directories is regulated
    • connection of internal and external storage is clearly definied
  • see also [de]: "B 1.11 Outsourcing" / [en]: "M 1.11 Outsourcing" (p. 86)

Externally Hosted

  • the responsibility stays within the organization
  • only the implementation is transferred to the external partner
  • therefor it is essential to have a contract defining security targets and specific requirements based on the needed protection level
  • see also [de]: "B 1.11 Outsourcing" / [en]: "M 1.11 Outsourcing" (p. 86)

Cloud

  • SaaS: the organization is only user of a fully externally defined and operated environment
  • nevertheless the responsibility regarding data security (protection, availability, …) stays within the organization
  • the requirements regarding architecture, security and technical implementation must be defined by the organization (see above "Operated on Premise with External Employees")
  • normally there won't be many options regarding implementation of requirements, only standard packages are available
  • so the most fitting contract partner must be chosen
  • the contract must reflect all necessary requirements (e.g. ISO 27001 or ISO 22301 certification is a good start)
  • see also "Cloud Bausteine IT-Grundschutz"

Conclusion

  • to set up a sharing service with ownCloud can be very useful and effective
  • keep an eye on possibilities and limitations
  • functionality of ownCloud still limited when compared to commercial solutions (but this isn't necessarily a limitation because more functions can make things more complex for operation and administration)
  • make sure to wisely decide which operation model fits your needs best
  • obey the data protection levels needed and define which data may be transferred where – or not
  • decide which techniques and tools should be used
  • user administration besides the internal users is still a challenge; plan wisely and implement detailed to avoid data leaks and undetected access to your data