Cloud & Data Security Policy - clientsss.com
650
page-template-default,page,page-id-650,sswcmaat tabs-default,woocommerce-no-js,ajax_fade,page_not_loaded,,qode_grid_1300,footer_responsive_adv,qode-content-sidebar-responsive,columns-4,qode-child-theme-ver-1.0.0,qode-theme-ver-16.8,qode-theme-bridge,disabled_footer_bottom,qode_header_in_grid,wpb-js-composer js-comp-ver-5.6,vc_responsive

Employyy By Teknocrat Pty Ltd – Cloud Application & Data Security Policy – SaaS

 

Table of Contents

 

Data Modelling and Levelling ………………………………………………………………………………………….3

1)    Authentication and Administration……………………………………………………………………………..4

1.1)     Authentication …………………………………………………………………………………………………..

1.2)     Account Provisioning………………………………………………………………………………………….

1.3)     Account Access Termination……………………………………………………………………………….

1.4)     Account Deprovisioning ……………………………………………………………………………………..

1.5)     Roles and Authorization (User Control Consolidation) ……………………………………………

1.6)     Access Control Granularity ………………………………………………………………………………..

2)     Auditing………………………………………………………………………………………………………………….8

2.1)     Logging ……………………………………………………………………………………………………………

2.2)     Teknocrat Monitoring, Reporting, and Alerting………………………………………………………….

2.3)     Internal Monitoring, Reporting, and Alerting…………………………………………………………..

2.4)     Internal Application Database………………………………………………………………………………

3)     Business Continuity………………………………………………………………………………………………12

3.1)     Interoperability and Portability…………………………………………………………………………..

3.2)     Backup………………………………………………………………………………………………………….

3.3)     Disaster Recovery…………………………………………………………………………………………..

4)     Data Security………………………………………………………………………………………………………14

4.1)     Response Expectations ……………………………………………………………………………………

5)     Communication Security…………………………………………………………………………………………15

5.2)     Teknocrat Network Security Testing……………………………………………………………………..

5.3)     Teknocrat Application Security Testing …………………………………………………………………

5.4)     Thick-Client or Physical Appliance Security…………………………………………………………

5.5)     Mobile Client Security ………………………………………………………………………………………

5.6)     Data Loss Prevention……………………………………………………………………………………….

5.7)     3rd Party Application Interoperability ………………………………………………………………….

5.8)     Virtualization……………………………………………………………………………………………………

5.9)     Storage at Rest……………………………………………………………………………………………….

6)     Teknocrat Governance………………………………………………………………………………………….. 20

6.1)     Teknocrat Policy and Standards Assurance…………………………………………………………..

6.2)     Incident Response …………………………………………………………………………………………..

7)     Brand Reputation…………………………………………………………………………………………………..21

7.1)     Contract Considerations……………………………………………………………………………………

7.2)     Discovery ……………………………………………………………………………………………………….

7.3)     Subpoena……………………………………………………………………………………………………….

7.4)     Email Integration……………………………………………………………………………………………..
Appendix A: Application SSO Classes ……………………………………………………………………………23

 

 

 

 

Data Modelling and Levelling

 

POTENTIAL IMPACT
Security Objective LOW (Level 1) MODERATE (Level 2) HIGH (Level 3)
Confidentiality

Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.

 

The unauthorized disclosure of information could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. The unauthorized disclosure of information could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. The unauthorized disclosure of information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.
Integrity

Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity.

The unauthorized modification or destruction of information could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. The unauthorized modification or destruction of information could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. The unauthorized modification or destruction of information could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.
Availability

Ensuring timely and reliable access to and use of information.

The disruption of access to or use of information or an information system could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. The disruption of access to or use of information or an information system could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. The disruption of access to or use of information or an information system could be expected to have a severe or catastrophic adverse effect on organizational operations, organizational assets, or individuals.

 

1) Authentication and Administration

 

1.1) Authentication

Authentication is defined as validating a user’s identity and basic-level authorization through determining if a user is allowed to access a system.

 

1.1.1)Base Requirements

Client will maintain an in-house centralized and authoritative authentication store that can be integrated with third-party services through industry standard protocols. This authentication store is described in the Application Classes section of Appendix A: Application SSO Classes. There are four classes of Authentication levels, ranging from a secure password store to fully integrated authentication & account provisioning/deprovisioning. Client will also maintain a two-factor authentication platform utilizing time-based one-time passwords, which will be integrated with the authentication store. At no time are third-party OAuth access methods to be used on any Client-approved cloud applications (i.e. logging in with your personal social network account is forbidden).

 

1.1.2)Level 1

The service should integrate with Client’s primary authentication service, but it is not required. If user credentials are stored in the service, they must be stored using industry standard cryptographic hashes and hash salting. If the application integrated with SSO, it is

expected to be run at a Class 0 or 1 level.

 

1.1.3)Level 2

The service must integrate with Client’s primary authentication service at a Class 2 level or above. Exceptions will be granted for services that support 10 users or less if the following criteria are met

  • Multifactor Authentication is enabled for all accounts using the service
  • There is a documented user provisioning and de-provisioning procedure with a named manager who accepts ownership of the process

 

1.1.4)Level 3

The service must integrate with Client’s primary authentication service at a Class 3 level or above. Users must authenticate with a second factor when connecting with a new client and again after an interval determined by security during the application assessment.

 

Additional roles and features within a Level 3 application may require multifactor authentication for each use, as required by security. Where necessary, exceptions will be granted as per the rules stated for Level 2 applications.

 

1.1.5)Notes

Application-specific passwords will be permitted for mobile clients that do not support multifactor authentication. These passwords must be strong, and rotated at least every 3 months.

 

1.2) Account Provisioning

Account Provisioning consists of the creation of the user account in the hosted system, which in many cases is performed separately from adding the user to the Identity and Access Management system.

 

1.2.1)Level 1

Automated account provisioning is preferred, but not required. Automated account provisioning consists of on-demand provisioning through the SAML request, or support for an automated feed of a delimited file format through a secure channel such as SFTP.

 

1.2.2)Level 2

Automated account provisioning through a SAML request, an API call, or an automated feed of a delimited file format through a secure channel is required. If an API is not available for automation, there must be a documented user provisioning and deprovisioning process with a named manager who accepts ownership of the process.

 

1.2.3)Level 3

The application must support the ability to query the account provisioning status through an API and report back to a provisioning system.

 

1.2.4)Notes

The requirements defined in this section refer to Employees and Contractors who have a Client network account. Contractors who do not have a Client network account are supported in limited cases for applications up to Level 2. There must be a documented provisioning and deprovisioning process with a named manager who accepts ownership of the process.

 

1.3) Account Access Termination

Account Access Termination is separate from Account Deprovisioning, as in many cases access to the account is separate from the disposition of the account and user-generated content in an application. Access Termination relates only to preventing access to an application after a user role change.

 

1.3.1)Level 1

A process must be documented that supports termination of access within 24 hours of a receipt of a termination request, including documented confirmation of completion. Ideally this will be supported by an automated process through the IAM system, but this is not required.

 

1.3.2)Level 2

A process must be documented that supports termination of access within 1 hour of the receipt of a termination request, including documented confirmation of completion. Ideally this will be supported by an automated process through the IAM system, but this is not required.

 

1.3.3)Level 3

Accounts must be immediately terminated upon receipt of a termination request by an automated process. When an account is terminated, the application must close any open sessions owned by that account. Manual processes are only allowed as part of a variance granted to applications that have 10 users or less.

 

1.4) Account Deprovisioning

Account Deprovisioning details the disposition of the account in the service, and management of the user-generated data (if any) related to the account.

 

1.4.1)Level 1

Accounts must be able to be deprovisioned through a manual or automatic practice. A documented process is not required.

 

1.4.2)Level 2

Accounts must be able to be deprovisioned through an API call or a delimited file transferred through a secure upload method. A written process must be maintained by the application owner that defines a disposition strategy for content attached to a user’s account.

 

1.4.3)Level 3

Accounts must be able to be automatically deprovisioned through an API by a Client-managed deprovisioning system. A written disposition strategy must be maintained by the application owner and validated by security for content attached to a user’s account.

 

1.5) Roles and Authorization (User Control Consolidation)

 

1.5.1)Base Requirements

The application platform must provide the application administrator the ability to restrict access through the designation of various roles and functions. The application must provide the means to authorize users through the least privilege model.

 

1.5.2)Level 1

The service must provide the administrator the ability to distinguish “administrator users” and “regular users”. The “regular users” shall be given authorization to the cloud service capabilities by “administrator users.”

 

1.5.3)Level 2

The service must provide the administrator the ability to create user roles and explicitly grant authorization to data and capabilities following the least privilege model based on role and/or function. By default a user should have no access. Authorization for additional permissions must be granted by the administrator with the appropriate access controls, and be performed in an audited manner. Additional authentication mechanisms such as 2FA or one time-limited use passwords should be available.

 

The following administrative roles are considered a minimum set that must be available for a Level 2 application

  • Super Administrator
  • User create / modify / update / delete
  • Read-Only Administrator or Log / Audit Read-Only role

 

1.5.4)Level 3

The system must provide a role-based access control model enabling the following additional roles above a Level 2 application

  • Administrator w/o access to view content (Admin Audit Account)

Third party access requests, including invitations to share content with end users, must be directed to and approved by an application administrator. These access requests must respect the Client Change Management workflow in order to ensure organizational compliance.

 

1.5.5)Notes

If an administrator applies specific access controls to a group owner account, the group owner should not have the ability to grant permissions above that assigned to the group. Subsequent accounts should either match the group owner controls or be more restrictive.

 

 

1.6) Access Control Granularity

 

1.6.1)Level 1

The service must provide the administrator the ability to distinguish “administrator users” and “regular users”. The “regular users” shall be given authorization to the cloud service capabilities by “administrator users.”

 

1.6.2)Level 2

The service must provide the administrator the ability to assign users the appropriate granular access control levels based on roles and/or function. The application owner must document a workflow process by which users can request additional access. This request must be verified by the administrator or group owner. This process must be auditable.

 

1.6.3)Level 3

The service must provide the administrator total control on the creation of granular user access controls, including access control lists for individual applications and users.

 

2) Auditing

 

2.1) Logging

 

2.1.1)Base requirements

Client will maintain a central Security Event and Information Management (SEIM) solution, allowing for the storing, collection and parsing of log data. In order to be compatible with the SEIM, the service must

  • Adhere to industry log format standards
  • Have a time service synchronized to a common worldwide time source
  • Have log data defined in UTC. If this is not possible, the UTC skew must be documented

If the application cannot provide this level of logging, integration with the cloud security monitoring system must be individually reviewed.

 

2.1.2)Level 1

Teknocrat must collect the following data ·         Application User Logs

o Log In / Log Off

o Session Creation / Session Termination o Password Change

  • Application Audit Logs

o User Create / Update / Delete actions

o Application Events as defined by Teknocrat

Logs must be maintained for a minimum of one year, and available by an administrator request. Real-time event logging to the Client SEIM is not required.

 

2.1.3)Level 2

In addition to the requirements defined for Level 1 applications, Teknocrat must collect the following

  • Application User Logs

o Failed Login Attempts ·    Application Audit Logs

o Document or Object Create / Read / Update / Delete actions o Metadata Create / Read / Update / Delete actions

All logs must also include the source IP address of the actor. Logs must be maintained for a minimum of one year, and available through the application web interface. Logs must be exportable into a format accessible by Client’s SEIM tool. Real-time reporting is preferred, but not required.

 

PaaS/IaaS: Teknocrat must include log data about the physical location of resources, including event logs when those resources change

 

2.1.4)Level 3

In addition to the requirements defined for Level 1 and Level 2 applications, Teknocrat must collect the following

  • Application User Logs

o All Administrative actions performed ·     Application Audit Logs

o Identifying users and the actions they performed ·         Performance Data Logs

  • Security Event Logs

o Brute Force Attempts ·     Network Logs

o Geo Location IP Logging o Firewall Deny Logging

  • Transaction Logs
  • Creation and Destruction for system-level objects as required for PCI compliant applications only

 

Logs must be exported in real-time to Client’s SEIM. Logs must also be maintained by Teknocrat for one year and encrypted at rest.

 

PaaS/IaaS: Teknocrat must also include the Hypervisor Logs.

 

2.2) Teknocrat Monitoring, Reporting, and Alerting

 

2.2.1)Base Requirements

Teknocrat must demonstrate to security that monitoring and reporting of infrastructure supporting the instance of the hosted service is being performed.

 

Teknocrat must have a contact and escalation process for alerting of scheduled and unscheduled application downtime. This process will be captured in the application database entry.

 

2.2.2)Level 1

Teknocrat must demonstrate the ability to be alerted to application downtime of the Client instance within 1 hour of the beginning of the downtime event.

 

2.2.3)Level 2

Teknocrat must provide additional availability reporting as required to validate the negotiated Service Level Agreement.

 

2.2.4)Level 3

Teknocrat must provide alerting and reporting of unusual events, as defined as being outside of a baseline usage pattern determined by Teknocrat through analytics of a user’s normal usage patterns.

 

2.2.5)Notes

The application and network monitoring can be performed by a third party partner of Teknocrat’s. In general, monitoring should detect unusual or unauthorized application and network activities, system usage, network usage, port scanning activities, packet sniffing by other tenants, etc.

 

2.3) Internal Monitoring, Reporting, and Alerting

 

2.3.1)Base Requirements

Our Client shall demonstrate the ability to perform security monitoring, defined as the ability to take internal network data, infrastructure data, system action data, and external vulnerability information, to monitor for abnormalities, unauthorized usage, or access. Regulatory compliance, if applicable, must be maintained for all data. The monitoring and alerting may leverage Teknocrat’s platform and various internal capabilities.

 

Our Client must also monitor and alert on Client-initiated application changes. These changes should be apart of a cloud application / service change management process and these actions logged.

 

2.3.2)Level 1

Our Client shall demonstrate the ability to monitor account logons and account logouts by request or on demand and time availability.

 

2.3.3)Level 2

Our Client shall demonstrate the ability to detect unauthorized account usage and unauthorized data access.

 

2.3.4)Level 3

Our Client must demonstrate the ability to provide comprehensive security monitoring on data residing in the cloud.

 

2.3.5)Notes

It is understood that we may have to develop custom tools in order to perform monitoring and compliance.

 

2.4) Internal Application Database

 

2.4.1)Base Requirements

In order to store critical application information, we will maintain a database of applications that have been reviewed according to the assurance criteria. The database will include the data described below. Both current and pending applications will be registered.

 

Ownership Data Application Owner

Application Support / On-Call Contact

Application Service Level Agreement and Recovery Time Objective

 

Application Data

Application SSO Class, as defined in Appendix A

Hosted Data Classification, as determined by the application owner At Rest data encryption state

 

Policy Data

Incident notification policy and last review date Backup policy and last review date

Account Access Termination Policy and last review date Account Deprovisioning Policy and last review date Business Continuity Runbook and test date

Last known Penetration Test / Security Test (3rd Party External)

 

2.4.2)Level 1

This registration must be validated every 12 months.

 

2.4.3)Level 2

This registration must be validated every 6 months.

 

2.4.4)Level 3

This registration must be validated every 3 months.

 

3) Business Continuity

 

3.1) Interoperability and Portability

 

3.1.1)Level 1

Unstructured data must be able to be exported into a non-proprietary format, either by the user or Teknocrat. Automated export processes are not required. Databases must be able to be exported into a non-proprietary format, either by the user or the service

provider. Automated export processes are not required. Service level agreements must exist to ensure data is available when the Client needs it, preventing a “run-on-the-bank” scenario.

 

3.1.2)Level 2

Unstructured data files must be able to be exported in bulk into a non-proprietary format by a service user or administrator.

 

PaaS/IaaS: Services must use a standards-based virtualization format, or allow for Virtual Machine export in OVF format. Teknocrat must document any non-standard customizations or differences that would impact deploying a Virtual Machine onto a new hypervisor. Any custom APIs developed by Teknocrat should be abstracted from Client-developed code in order to allow for quick porting of applications to Teknocrat.

 

3.1.3)Level 3

Unstructured data files must be able to be exported in bulk with metadata and security ACLs attached.

 

3.2) Backup

Data Backup is defined as maintaining one or more versions of content in a physically and logically separate system. This data is meant to be quickly accessed to replace content that is damaged, corrupted, or accidentally deleted. Data Replication must not be confused with backup, as replication cannot handle restoration from corrupted data. Recovery time objectives and recovery point objectives described are maximum values – the business may set more stringent RTO and RPO targets based on the value of the data.

 

3.2.1)Level 1

The business customer is strongly encouraged to define a backup strategy for content. A formal backup strategy is not required.

 

3.2.2)Level 2

There must be a documented backup policy for all data hosted on a Level 2 system. If the backups are hosted, the backup system must be maintained by a different provider. Steps must be taken to ensure the backup is not hosted on the same PaaS/IaaS infrastructure as the primary data. 14 days of backup must be maintained, with a 24 hour recovery time objective and 24 hour recovery point objective.

 

Note: Backups hosted on a different cloud infrastructure, but managed by Teknocrat meet this requirement. For example, Teknocrat maintains an encrypted content backup on AWS. Because this exists on a different cloud infrastructure from the production system, it meets Level 2 requirements.

 

3.2.3)Level 3

There must be a documented backup policy for all data hosted on a Level 3 system. In addition to the requirements documented for Level 2 applications, 30 days of backup must

be maintained, with a 12 hour recovery time objective, and 24 hour recovery point objective.

 

3.3) Disaster Recovery

Disaster Recovery is defined as maintaining availability of all data managed by a service. Restoring data from a DR system may take longer than restoring from backup, and is typically more involved.

 

3.3.1)Level 1

A disaster recovery plan is not required for Level 1 applications.

 

3.3.2)Level 2

Teknocrat must provide business continuity and disaster recovery documentation for the hosted service. The application owner must provide a business continuity runbook that defines the length of time the system is allowed to be inaccessible before a business continuity event is initiated, the process for restoration, and the ownership of the process. This document must be updated every 6 months and be attached to the application’s registry in the hosted service database.

 

3.3.3)Level 3

Teknocrat can, if required, either directly or via assignation to the end service provider, provide a tour of a representative facility that will be hosting Client data, enabling Client to evaluate the physical suitability of the site

  • Physical and Environmental Security · Fire Protection
  • Protection from Natural Disaster · Policy Enforcement

The tour will be attended by ·      IT specialist

  • Information Security specialist · Physical Security specialist
  • Director-level or above stakeholder

 

In addition to the requirements for a Level 2 application, the Disaster Recovery document must be reviewed every 3 months and be attached to the application’s registry in the hosted service database. The Disaster Recovery strategy must be tested no less than once per year.

 

4) Data Security

 

4.1) Response Expectations

 

4.1.1)Base Requirements

The following sections set requirements for the protection of Client data. Vulnerabilities may be found by the Client, the application vendor – ie Teknocrat, or a third party. Once the vulnerability has been disclosed to Teknocrat, the following service levels are expected

  •   Critical: Remediation on the same day ·     High: Remediation in 5 business days
  • Medium: Remediation in 15 business days · Low: Remediation in 30 business days

Generally, vulnerability scoring is performed by the risk assessor, and are based on their scoring criteria. Lacking that, High-risk vulnerabilities can be described as:

  • Any bug that allows for circumvention of the authentication mechanism
  • Any bug that enables disclosure of credential information, including but not limited to: usernames, passwords, or API tokens
  • Any bug that allows for an attacker to run arbitrary code, including but not limited to: SQL injection, Cross-Site Scripting (XSS) Cross-Site Request Forgery (CSRF), and Remote Code Execution
  •   Any report of the application logging confidential data including but not limited to: confidential data not required for the log’s purpose, passwords, or API tokens
  • Any bug that affects log data or enables an attacker to destroy existing log data or prevent logging of their actions

We reserve the right to determine vulnerability severity based on internal standards, or vulnerabilities will be classed at a mutually agreed-upon severity.

 

4.1.2)Level 2

Teknocrat is expected to be able to disable Client’s instance of the hosted application immediately upon request in response to a vulnerability.

 

5) Communication Security

 

5.1) Transport Layer Protection

 

5.1.1)Base Requirements

The cloud service platform shall use Transport Layer Security (TLS) for all user authentication, credential, and data transfer. SSL v3 is to be disabled.

 

Certificates must not be self signed and come from established and reliable independent CAs.

 

Strong ciphers must be utilized and key management process should be documented.

 

 

5.2) Provider Network Security Testing

 

5.2.1)Base Requirements

Teknocrat or a reputable third-party shall perform network security penetration testing on the Client hosted instance using an industry-standard methodology and furnish a report. The network traffic generated by Client’s instance should be defensible from tenant port scanning and packet sniffing.

 

5.2.2)Level 1

The network security penetration test must be performed at least annually. An executive summary shall be provided to Client for review.

 

5.2.3)Level 2

The network security penetration test must be performed at least every 6 months, or after a significant change has been made to the system. An executive summary shall be provided to Client for review, if additional information is needed Client shall make a request.

 

Client shall have the ability to perform one external network security penetration scan annually and will provide findings to Teknocrat for response and remediation.

 

5.2.4)Level 3

The network security penetration test must be performed at least quarterly, or after a significant change has been made to the system. An executive summary and detailed report shall be provided to Client for review.

 

Client shall have the ability to perform at least one external network security penetration scan annually and will provide findings to Teknocrat for response and remediation.

 

5.3) Provider Application Security Testing

 

5.3.1)Base Requirements

Teknocrat or a reputable third-party shall perform application security penetration testing using an industry-standard methodology and furnish a report.

 

5.3.2)Level 1

The application security penetration test must be performed at least annually. An executive summary shall be provided to Client for review.

 

5.3.3)Level 2

The application security penetration test must be performed at least every 6 months, or after a significant change has been made to the system. An executive summary shall be provided to Client for review, if additional information is needed Client shall make a request.

 

Client shall have the ability to perform an application security penetration assessment annually and provide findings to Teknocrat for response and remediation.

 

5.3.4)Level 3

The application security penetration test must be performed at least quarterly, or after a significant change has been made to the system. An executive summary and detailed report shall be provided to Client for review, if additional information is needed Client shall make a request. Teknocrat shall provide documentation about the software quality assurance and software development lifecycle for the application.

 

Client shall have the ability to perform an application security penetration assessment annually and will provide findings to Teknocrat for response and remediation.

 

5.4) Thick-Client or Physical Appliance Security

Some hosted applications include software or hardware that must be installed on Client networks in order to support the application. This includes, but is not limited to, desktop sync products, Active Directory sync agents, or display controllers.

 

5.4.1)Base Requirements

The application shall use secure communications to transmit data. User authentication may be performed with an application-specific password managed through the enterprise administration console. A third-party security assessment using an industry-standard methodology of the application must be performed and the results available to Client. If the application is a physical or virtual appliance, it should be placed on a secured subnet where access to other Client resources is not available.

 

5.4.2)Level 1

No additional client security requirements.

 

5.4.3)Level 2

No additional client security requirements.

 

5.4.4)Level 3

The application shall have the ability to perform device pinning, where the administrator has the ability to limit the number and type of devices the end user can connect with. The application shall perform token-based authentication and have the ability to locally log operational and security events.

 

5.4.5)Notes

Internal security may perform penetration testing to determine usage and enterprise risk.

 

5.5) Mobile Client Security

 

5.5.1)Base Requirements

The mobile client application should use secure communication methods such as SSL/TLS for all data transmission.

 

5.5.2)Level 1

No additional mobile client security requirements.

 

5.5.3)Level 2

The mobile client application may create an encrypted directory on the device for the storage and synchronization of files. The mobile client shall leverage a pull-based content setup and synchronization shall be configurable by the administrator. User authentication shall be performed by a token instead of saved username / password.

 

5.5.4)Level 3

The application must have an authentication structure that allows Client to enforce the use of an MDM solution to access data. The mobile client application must also have the option of only allowing the saving of data onto the mobile device if the device is encrypted. The application must also have the ability to manage and remove content from a compromised device.

 

5.5.5)Notes

Internal security may perform penetration testing on the mobile client to determine usage and enterprise risk.

 

5.6) Data Loss Prevention

 

5.6.1)Base Requirements

The service must employ a firewall that does not permit the application from sending traffic with a source IP or MAC address other than its own.

 

5.6.2)Level 1

PaaS/IaaS: Volume-level encryption must be available to protect data against snapshot cloning, or protect each piece of content if using Object-based storage.

 

5.6.3)Level 2

The application should provide the ability to filter requests by IP, enabling Client to limit traffic to trusted networks. The service should have basic Data Loss Prevention mechanisms, such as traffic reporting and alerting of traffic spikes above a set threshold or a provider-determined baseline.

 

5.6.4)Level 3

The application must provide the ability to filter requests by IP, enabling Client to limit traffic to trusted networks. In addition, the applications must have robust Data Loss Prevention Mechanisms including Database / File Activity Monitoring, traffic and usage baselining, and alerting. If these services cannot be provided by Teknocrat, Teknocrat must provide the log information required for Client to develop the baseline and alerting toolset in-house.

 

5.7) 3rd Party Application Interoperability

3rd Party Application Interoperability is defined as accessory hosted applications that use APIs to act on data hosted by Teknocrat. An example would be an application that uses Google Drive APIs to store project files in a user’s Drive storage space.

 

5.7.1)Level 1

There are no additional requirements for Level 1 applications.

 

5.7.2)Level 2

The system must allow the administrator to control if OAuth or other API access is allowed on a per-application level. The service should provide the administrator the ability to create time sensitive access control criteria for third party applications.

 

Any actions taken by a third party application must be logged. In addition to the standard log data requirements, the log must contain an identifier to the application and the user context the application was authorized under.

 

5.7.3)Level 3

The system must allow the administrator to control if OAuth or other API access is allowed on a per-application, per-user basis, and restrict types of content from being accessed via API.

 

5.8) Virtualization

 

5.8.1)Base Requirements

PaaS/Iaas: A virtual machine cannot be moved from a less-trusted environment to a more-trusted environment. The data should be exported and the application built from the ground up on a trusted platform.

 

5.8.2)Level 1

There are no additional requirements for Level 1 applications.

 

5.8.3)Level 2

Virtual machines that host any service should be encrypted at rest.

 

Paas/IaaS: Any Virtual Machine migration, including vMotion moves, must be logged and captured in the operational log that is transmitted to the Client central log management system.

 

5.8.4)Level 3

Virtual machines must be encrypted at rest. Mixed-mode (systems that support PCI-protected data and non-PCI protected data on the same hypervisor) are not allowed by Teknocrat.

 

PaaS / IaaS:

Teknocrat must host Client’s content on a separate network segment and on a dedicated hypervisor. Teknocrat must offer a software-defined firewall. If the OS / Application layer is managed by Teknocrat, they must provide an update / patch cycle document.

 

5.9) Storage at Rest

 

5.9.1)Base Requirements

Teknocrat must provide the ability for the Client to store data in an encrypted format if required by privacy regulations such as the EU DPD or SOX.

 

5.9.2)Level 1

There are no additional requirements for Level 1 applications.

 

5.9.3)Level 2

There are no additional requirements for Level 2 applications.

 

5.9.4)Level 3

Teknocrat must store all data at rest in an encrypted format. The cloud provider should not have any requirements that would prevent the use of a gateway encryption service or an application to encrypt data before reaching the service.

 

PaaS/IaaS: Any Virtual Machine “snapshots” or similar capability must be stored on an encrypted file system.

 

6) Teknocrat Governance

 

6.1) Provider Policy and Standards Assurance

 

6.1.1)Base requirements

Teknocrat must show that an Information Security Management Program (ISMP) has been developed, documented, approved, and implemented that includes administrative, technical, and physical safeguards to protect assets and data from loss, misuse, unauthorized access, disclosure, alteration, and destruction. In addition, change management documentation must exist.

 

6.1.2)Level 1

Teknocrat must have the information security policies described above.

 

6.1.3)Level 2

Teknocrat must provide an audit report. The audit report shall be SAS70 Type II, SSAE 16 SOC2, ISAE3402, or similar third party audit report. Level 2 providers should perform the Cloud Security Alliance Cloud Controls Matrix (CMM) self-assessment. These documents will be reviewed by Client annually.

 

6.1.4)Level 3

Level 3 providers must perform the Cloud Security Alliance Cloud Controls Matrix (CMM) self-assessment. The findings must be made available for annual review. In addition, the implementation of a Level 3 application at Client should be able to pass our PCI audit. The cloud provider must provide a current change management policy document.

 

6.2) Incident Response

 

6.2.1)Base Requirements

The responding CSIRT team will have the ability to review Teknocrat’s incident response and triage process. We recommend that Teknocrat leverage industry best practices such as NIST 800-61, the Computer Security Incident Handling Guide.

 

6.2.2)Level 1

No additional Incident Response requirements.

 

6.2.3)Level 2

Teknocrat must provide a documented incident response policy including ·     Defined point of contact and Out-Of-Band communications channel ·       Incident definition and notification criteria

  • Definition of roles & responsibilities during an incident
  • Specification of post-mortem activities and resolution timelines · Specification of Incident Response testing

 

6.2.4)Level 3

Through security monitoring of the infrastructure Teknocrat / provider shall share threat intelligence data with Client Security Team.

 

 

7) Brand Reputation

 

7.1) Contract Considerations

 

7.1.1)Level 1

  • Teknocrat must include an exit / termination clause if an assessment finds a vulnerability that is not remediated within the expected timeframe, without penalty
  • Teknocrat must agree to provide Client notification of confirmed security incidents that affect Client’s data (confidential and non-confidential) within 24 hours of their discovery
  • Teknocrat must agree to provide Client notification of warrants, subpoenas, or other legal action that involve Client data (confidential and non-confidential) with appropriate time for Client to react
  • Teknocrat must provide Service Level Agreements for availability, including reputational availability (example: blacklist of IPs due to tenant sending SPAM)
  • Teknocrat must agree to reasonably cooperate in a discovery event

 

7.1.2)Level 2

  • Teknocrat must agree to Client’s right to audit
  • Teknocrat must clearly document any tenant relationships or dependencies
  • Teknocrat must provide written attestation that Client data has been removed when the contract is terminated
  • If there is a bandwidth, usage, or API cap placed on Client’s usage of the service, Teknocrat must lift this cap during Client’s response to litigation

 

7.1.3)Level 3

  • Teknocrat must provide Client with notification of both known and potential breaches of any customer’s data. This data may be anonymized.

 

 

7.2) Discovery

 

7.2.1)Level 1

Ability to export all data owned or generated by any specific user of the system in any format.

 

7.2.2)Level 2

Ability to export all data owned or generated by any specific user of the system in a format readily accessible by Client’s eDiscovery platform.

Ability to execute a litigation hold of content in-place. Ability to create and remove litigation hold via API.

 

7.2.3)Level 3

Ability to perform detailed keyword searches and generate output in a format readily accessible by Client’s eDiscovery platform.

 

7.2.4)Notes

The contract should address the temporary bandwidth increase required to pull discovery data. The content should be accessed in a collection of files reasonable in number and size (1,000 10MB PST files for a user covering 2 years would not be reasonable). If the bandwidth is unable to be provided, the cloud provider should provide a solution in which storage can be shipped while maintaining a chain of custody.

 

7.3) Subpoena

 

7.3.1)Base Requirements

Teknocrat must notify Client in a timely manner if they receive a Subpoena, Warrant, or any other legal request for Client’s data and give Client appropriate time to respond to the request.

 

7.4) Email Integration

 

7.4.1)Base Requirements

If the service needs to send email that appears to be coming from a Client-managed email address, Teknocrat must support Client’s email security strategy to ensure the message is legitimate. Cloud provider hyperlinked marketing and advertising will not be embedded within email communication.

 

Appendix A: Application SSO Classes

Implementations of Single Sign-On can vary significantly between providers, and this variation can have a profound effect on the security benefit provided by the SSO integration. In order to provide a standard method of describing these benefits, the following class structure has been developed. A SSO implementation can be compared against the class descriptions provided in order to determine the security posture provided by the integration.

 

Class 0

 

Class 0 applications do not have a SSO integration, and are provided through a Saved-Password mechanism. Using this strategy, the Identity Provider securely stores the user name and password, and feeds it to the app, typically through a browser plugin. This design is easily circumventable so the access logs stored in the Identity Provider should not be considered accurate. Account provisioning and deprovisioning are performed through a secondary channel. Since disabling the account within the Identity Provider does not prevent access to the application, Class 0 applications are preferable if the user may need to access the application after they have terminated employment. An example would be a 401k benefits portal.

 

Class 1

 

Class 1 applications provide convenience to the end users, but do not add any application security. These applications support SSO access through the Identity Provider, but allow the user to maintain a separate username / password that can be used through the application’s login panel or mobile application. Since the user can access the application directly without going through the Identity Provider, IdP access logs should not be considered accurate. Account provisioning and deprovisioning in this class of application is performed through a secondary channel, either automatically (secure data feed through web API or file transfer), or manually. Since disabling the account in the Identity Provider does not prevent access to the application, the application administrator is responsible for ensuring deprovisioning is performed in a timely manner.

 

Class 2

 

Class 2 applications enforce SSO access through an Identity Provider only. The user does not have a separate username / password for the application. Access is granted to the application through IdP-initiated connections, or by passing credentials through a trusted channel to the IdP (delegated authentication). Account provisioning and deprovisioning is performed through a secondary channel, either automatically (secure data feed through web API or file transfer), or manually. Because all access is controlled by the Identity Provider, the application administrator does not have to act quickly to a termination event.

 

Class 3

 

Like a Class 2 application, Class 3 applications enforce SSO access through an Identity

Provider only. Account provisioning for these applications is performed automatically through the SAML assertion or in real-time by an API integration with the IdP. Account deprovisioning is performed through a secondary channel, preferably through an automated task using an API. Because all access is controlled by the Identity Provider, the application administrator does not have to act quickly to a termination event.