A. Introduction and Objectives
Cendyn has implemented corporate information security practices and standards that are designed to safeguard Cendyn corporate environment and to address business objectives across information security, system and asset management, development, and governance.
These practices and standards are approved Cendyn executive management and are periodically reviewed and updated where necessary, as such this document and its objectives may change accordingly.
A-1 Technical Organization Measures
As stated in Article 32 of the GDPR under “Security of processing” it is required “the controller and the processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk”.
We as Cendyn identified the existing data privacy challenges and used the following reasonable subtopics:
- Organizational control
- Physical access control
- System access control
- Data access control
- System security control
A-2 Structure of the Document
This document is divided into three sections, first the document structure topics, second the Management initiatives and third the TOM structured categories outlined above.
This document outlines the security policies, practices, and controls in place for Cendyn platforms and applications.
B-2 Target Groups and Audiences
This document is mandatory directed to all employees of Cendyn. Employees are bound to the requirements based on this document. Externals and Partners must apply to this regulation.
B-3 Trust Commitment
Cendyn is committed to protecting the data that our customers have entrusted us with. Safeguarding the private information of individuals is also paramount. Cendyn warrants that it has in place physical, administrative safeguards and procedures to protect the confidentiality of all confidential information of a customer. Cendyn maintains an Information Security Management System (ISMS) that addresses
- User access and identity management
- Vulnerability management
- Change management
- Business continuity
- Physical security
- Network management
- Human resources
- Incident response
Data privacy documents are reviewed in yearly iterations or with required changes, whatever applies first. All data privacy related documents are reviewed and accepted by our DPO.
C. General Security Management
C-1 Risk Management
The Cendyn Risk Management program is divided into four phases:
- Risk Program executive-level authorization
- Authorization and Support for beginning the risk management process.
- Determine Risk context (external and internal threats, existing controls, risk acceptance criteria)
- Risk identification
- Identify the criticality of each asset group and impact of loss
- Determine risk owners and identify the risks applicable to each asset group.
- Select the mitigation controls for each risk and their maturity level.
- Risk analysis and evaluation
- Determine the level of risk, depending on the asset impact and risk likelihood.
- Risk treatment
- Select the risk treatment options considering the risk assessment results and the risk acceptance criteria.
C-2 Data Residency
Cendyn’s platforms are hosted and running on servers and hardware that we own and/or cloud technology we fully manage. For hardware we own: we house our equipment in a Tier 5 facility owned and managed by 365 Data Centers located at 3500NW Boca Raton Blvd, Building 900, Boca Raton, FL 33431. For Cloud technology, we leverage Azure or AWS in the USA, EU, and APAC regions.
C-3 Audits and Certifications
Cendyn requires that 365 Data Center maintain SOC2 audit standards.
Facility information can be reviewed here
Azure Compliance offerings
AWS Compliance offerings
C-4 Security Policies and Procedures
Cendyn adheres to a comprehensive security policy framework. This framework includes standards for access control, HR processes, environmental/physical security, communications and network security, cryptography, software development, incident management, business continuity, vulnerability management, and data privacy. Cendyn’s security policy framework is reviewed on a regular basis.
C-5 HR Policies
A Cendyn HR Specialist conducts background investigation for all new hires as well as existing personnel in critical roles or those who have access to sensitive information. The background check includes employment verification, educational and license or credential verification, criminal history, reference checks, and other pertinent information.
Employees are required to sign an employee contract, Code of Conduct, Employee Handbook, and participate in security awareness training.
New employee (Onboarding)
Cendyn follows the principle of least privilege. As new employees are onboarded only the required set of system permissions are granted. Authorization badges and/or keys are handed over by HR and/or the responsible department.
Termination of employee (Offboarding)
All permissions granted are terminated and login access is inactivated on the last day of employment or when their contract ends – whatever comes first. Access badges, keys, IT equipment and any other company assets returned to HR and IT.
Job role and responsibilities changes
All permissions required for the previous role are rejected as the job change takes place.
Received access badges and keys must be authorized by HR on necessity for the new role. All permissions required for the new role and responsibility are granted by the time the previous permissions are taken.
C-6 Secure Supplier Evaluation
Cendyn conducts a review of service providers periodically. This review evaluates the security, privacy, service levels, and IT controls.
D. System Security Management
D-1 Data Classification and Handling
Cendyn’s Data Classification and Handling policy define a set of rules that help safeguard information confidentiality within Cendyn. The rules set in the policy describe several methods to protect data, such as controlling the access to sensitive and confidential information and protect sensitive or confidential information. It is the responsibility of all Cendyn employees to classify their information and ensure appropriate measures to handle and protect data. The information lifecycle consists of:
- Labeling: Categorization of Private, sensitive, public or unclassified
- Usage scope: Cendyn Internal or Client Data by application use
- Method of Transfer and encryption requirements
D-2 Change Management
Cendyn leverages documented processes and systems-based Microsoft Operations Framework to ensure that all environmental changes are documented, tested, reviewed, and approved. A defined maintenance window is used for applying changes to systems in the environment, along with a communication plan informing all stakeholders of pending changes. System rollback procedures include backups before making any changes in addition to the regular nightly backups. The Change Management process involves four phases to deploy updates or fixes to the production environment.
- The technical owner proposing changes documents the change, including the requested change date, deployment owner and deployment manager.
- The deployment steps are outlined with detailed steps to deploy changes to the application or environment.
- The test plan describes the steps to take in order to confirm the changes have completed successfully. If the test plan fails, the technical owner determines whether to roll back the changes or continue troubleshooting.
- The rollback plan describes the steps to revert the changes using a backup or snapshot created in the deployment phase.
Cendyn only makes changes to Cendyn Applications during scheduled maintenance windows.
D-3 Software Development Lifecycle
The Cendyn Software Development Lifecycle (SDLC) describes the processes in place to develop software in a secure manner. The SDLC model consists of several distinct stages including planning, design, building, testing, and deployment with security throughout the development process. Below is an outline of how we handle updates to Cendyn products.
- Planning and Requirements Analysis
- Requirement analysis is performed by the senior members of the team with inputs from the customer and product subject matter expert. This information is then used to plan the basic project approach.
- Planning for the quality assurance requirements and identification of the risks associated with the project is also done in the planning stage.
- Defining Requirements
- Once the requirement analysis is done the next step is to clearly define and document the product requirements and get them approved from the Customer and/or the product manager. This is done through an BRD (Business Requirements Document) or other agile artifacts which consists of all the product requirements to be designed and developed during the project life cycle.
- Designing the change to product architecture (if required)
- BRD is the reference for product architects to come out with the best architecture updates, if required. The design approach for the updated architecture is proposed and documented in a DDS – Design Document Specification.
- This DDS is reviewed by all the important stakeholders and based on various parameters as risk assessment, product robustness, design modularity, budget and time constraints, the best design approach is selected for the product.
- A design approach clearly defines all the architectural modules of the product along with its communication and data flow representation with the external and third-party modules (if any). The internal design of all the modules of the proposed architecture should be clearly defined with the minutest of the details in DDS.
- Building or Developing the Product
- In this stage of SDLC the actual development starts utilizing the Agile Model and product changes commence. The programming code is generated as per DDS during this stage.
- Developers will follow Cendyn development guidelines.
- Testing the Product
- While all stages have testing, this stage refers to the testing only stage of the product where product defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the BRD.
- Deployment and Maintenance
Once the update is tested and ready to be deployed it is released formally in production with communication sent to clients
D-4 Patch Management
Cendyn patch policy utilizes three tools to automate our patch management program. Each server is updated monthly.
- VMware provides scheduled snapshots of the server before a patch
- Kaseya automates the approved patch utilizing a Patch Policy Membership that each server is assigned.
- PDQ is used to confirm that new patches have been installed.
- Cloud based systems provide for automated regular patching cycles
D-5 Vulnerability Management
Cendyn corporate policy outlines the process and procedures to be followed when implementing a vulnerability management program. The policy is documented and divided into sections that identify, classify, remediate and mitigate vulnerabilities.
The core vulnerability management requirements:
- Documenting the roles and responsibilities associated with technical vulnerability management, including asset inventory, vulnerability monitoring, vulnerability risk assessment, remediation and mitigation, and any coordination responsibilities required.
- Performing vulnerability scanning to detect vulnerabilities.
- Classifying, remediating and mitigating the identified technical vulnerabilities.
- Implementing vulnerability management prior to enabling internet facing infrastructure or web applications.
- Implementing vulnerability management for major changes to the environment.
- Reporting status to management.
- Ensuring the vulnerability management procedure is an auditable process.
Vulnerability Scans are run monthly.
D-7 Penetration Test Management
Cendyn will perform penetration testing annually utilizing a trusted third-party vendor. Identified vulnerabilities will be addressed following the Cendyn vulnerability management program to identify, classify, remediate and mitigate vulnerabilities. Patch management is a component of the remediation plan within the vulnerability management policies. Patches are deployed to systems with the highest level of exposure and potential impact. All patches are deployed to development, QA, staging and finally production once all testing has been completed.
Targeted Vulnerability Scan and Penetration Testing Remediation Timeframes:
|Critical||Fix or find remediation within two to four weeks from the date it was found|
|High||Fix or find remediation within two months from the date it was found|
|Medium||Fix or find remediation within 3 to 6 months from the date it was found|
|Low||At the discretion of the representative: no action, fix or find remediation within 6 to 12 months from the date it was found|
|Info||No action unless representative has a different reason/opinion|
D-8 Incident Management
The Cendyn Incident Response Plan provides guidance for handling and communicating computer security incident responses at Cendyn. The Cendyn Incident Response Plan will be activated whenever a security incident occurs and guides the responses to all incidents whose severity is such that they could affect Cendyn’s ability to do business, undermine its reputation or result in a financial impact to the company. It is the responsibility of every employee and contractor of Cendyn to immediately report any security incident to the Support.
Cendyn will notify the Customer within 72 hours after confirmation of a security incident such as suspected unauthorized disclosure of the Customer’s data or its agents. Cendyn Support will work to resolve issues with maliciously or unintentional alteration of data.
Intrusion Detection System
- Cendyn has implemented the Cisco FireSIGHT module at the ASA Firewalls which record all permitted and denied Intrusion Detection/Prevention events as determined by the Cisco Sourcefire IDS/IPS ruleset. The Cisco FireSIGHT module also does Application Firewall protections (i.e. SQL Injection, cross site scripting, etc.) for known and unknown vulnerabilities.
- Cendyn has also enabled the threat detection & protection feature at the Cisco ASA perimeter firewalls to help mitigate DoS and other mass bot-net attacks. If the scanning threat rate is exceeded, then the ASA sends a system message, and shuns (blocks) the attacker for 30 minutes.
- We have a centralized log correlation via TrustedMetrics Services; alerts go out for suspicious activity at the network level and proper personnel take proper action and/or follow up. We also block IPs by monitoring load balancer logs to determine Suspicious activity and if a pattern for non-trusted IPs is triggered; initiate the auto-shun (block) of such IPs at the Firewall.
- URl Filtering / URL Blocking: Cendyn has enabled The Cisco URL filtering feature at the firewall level to identify and control access to web (HTTP and HTTPS) traffic.
- FIM Alerts: changes to specific directories/shares, including new files, deleted files and modified files.
|Name/Team||Role/Title||Role and Responsibility of the Incident Response Team|
|Trusted Metrics||Cendyn Partner||Review of Logs (Security & Others) Always watching for anomalous behavior, so when things seem out of the ordinary, alerts go out.|
|Cendyn Support Team||Support Team||Responsible to audit alerts from multiple monitoring systems to analyze and validate a threat, error, etc. Once an issue is validated; escalate, triage & follow up until proper resolution is found|
|IT Management||Senior Director, IT||Ensure Incident Response Plan is executed correctly. If there are any incidents, communicate with VP and executive teams|
|IT Department||IT Team||Assist with investigation/remediation of incident|
|DEV Department||DEV Team per Product||Assist with investigation/remediation of incident|
|VPs||Company VPs||Correspond with clients as necessary and provide Support to VP of IT as needed.|
The following documented response mechanisms serve as the Standard Operating Procedures for responding to any incident within the organization:
- 1. For any incident that has been detected, the Incident Response Team is to be immediately notified via Text Service and Communication Bridge opened.
- 2. The Incident Response Team is to formally assume control and to identify the threat and its severity to the organization’s information systems.
- 3. In identifying the threat, the Incident Response Team is to specifically identify which resources, both internal and external, are at risk and which harmful processes are currently running on resources that have been identified as at risk.
- 4. The Incident Response Team is to determine whether the resources at risk (hardware, software, etc.) require physical or logical removal. Resources posing a significant threat to the continuity of the business are to be immediately removed or isolated, either physically or logically. Resources that may require physical or logical removal or isolation may include, but are not limited to, the following:
- All IP addresses in use
- Routers and switches
- Intrusion Detection Systems (IDS)/Intrusion Prevention Systems (IPS)
- Any enterprise-wide applications (CRM systems, etc.)
- Remote access
- Point-to-point secure data transmission methods used for data traversing back and forth on the network
- Wireless networking or networks
- Authentication servers (RADIUS)
- Web servers
- Proxy servers
- File servers
- Email servers
- DNS servers
- Operating systems
- 5. If the incident is identified as a DDoS attack, Cendyn should first contact R2 and then the ISP per the incident response plan.
- 6. If the incident has affected the PCI environment in any way, and has impacted the system components within this environment, Cendyn must immediately report the incident, its severity and other essential information to the major credit card payment brands (Ovations only).
- 7. Notify affected client contacts immediately after discovery of a breach, serious attempt to breach, unauthorized disclosure, or security incident which would compromise personally identifying information or other sensitive information such as payment card data. Do not notify or contact any customers directly without the authorization of the client.
- 8. If the incident has in any way resulted in a criminal matter that may be readily identified, Cendyn must immediately report it to law enforcement officials, such as the following:
- 1. Local law enforcement
- 2. The United States Secret Service (for credit card fraud)
- 3. The Federal Bureau of Investigation (FBI)
- 9. Investigating the incident is also a critical process within the Incident Response plan. Proper investigative techniques are to include, but are not limited to, the following:
- 1. Understanding how the incident occurred and what led to the compromise
- 2. Reviewing all necessary system documentation such as logs, audit trails, rule sets, configuration and hardening standards and all other supporting documentation
- 3. Interviewing personnel as needed
- 4. Examining any third-party providers and their respective products and services that are utilized within Cendyn’s network architecture
- 6. If warranted, a third-party resource for assisting in the investigation of the incident may be utilized (this will be done at the management’s discretion)
Recovery from an Incident
Recovery procedures will include but are not limited to the following:
- Restoring systems from clean backups (a trusted source only)
- Completely rebuilding systems as needed and warranted
- Replacing systems as needed (this includes all system components within the personally identifying information or cardholder data environment and any other IT resources deemed critical by Cendyn)
- Reconfiguring network security (stronger, more adaptive configuration and hardening rules) for all system components within the personally identifying information or cardholder data environment and any other IT resources deemed critical by Cendyn
The recovery procedures will be commensurate with the incident that has occurred. This will be conducted on a case-by-case basis with all aspects of the recovery process fully documented.
Post-Incident Activities and Awareness
A formal and documented Root Cause Analysis (RCA) is to be compiled and given to management of Cendyn within an acceptable timeframe following the incident. The RCA must contain the following elements:
- What happened: a detailed description of the incident
- Root cause: a description of the root cause.
- Resolution: steps taken for restoring affected systems
- Timeline: timestamps from start to finish, including all important times from the incident
- Impact: specific systems, accounts, and users affected by the challenge
- Communication: reporting of the incident for all relevant third parties as needed
- Lessons to Learn: A list of items, positive or learning touch points, from which Cendyn can take to improve systems and process and hopefully eliminate the likelihood of future incidents
All RCA Documents will be stored in Salesforce and reviewed monthly by the INFOSEC Committee.
D-9 Disaster Recovery and Business Continuity
Cendyn participates in a corporate-wide program for business continuity planning. Critical business processes and the resources required to support those processes are inventoried. For each process and resource, an alternative is identified, such as a corresponding team at another site that can provide Support in the case of a business interruption until service is restored. Gaps are identified and addressed according to the documented process.
1. Organizational Control
1-1 Contractual Base
Cendyn offers services on basis of standardized contracts which fits exactly our service design and the legal requirements.
The contracts are changed on behalf of changes in the applicable law or on behalf of changes in the general service design / technical functions. Changes are communicated transparent with the customer.
Terms & Conditions
The general Terms & Conditions define more specific how the SaaS service is delivered, and which arrangements apply. Changes are communicated transparent with the customer.
Service Level Agreements
The SLAs defines in a specific form the reaction and support levels on basis of the severity of requests and escalation. Changes are communicated transparent with the customer.
Data Processing Addendum
The DPA defines in a standardized form the handling of customers data, especially with PII. Changes are communicated transparent with the customer.
1-2 General Data Usage
Cendyn does internally not process PII without a previous given consent by the owner. Cendyn requires customers to gain the consent for the submitted data which is specified in the contracts. Customers and or Partners utilizing Cendyn Services are required to obtain consent for the data to be processed.
1-3 Defined Overview of Subprocessors
Active service providing partners are added to a sub processors overview list.
1-4 Security Awareness Training
All Cendyn employees are required to attend annual mandatory security awareness training. Training includes awareness of data privacy policies and issues, safe email and browsing habits, phishing and social engineering, and proper procedures for reporting security issues. Additionally, development staff are required to attend annual mandatory Secure Code Training
In addition to mandatory training, Cendyn employees receive weekly security notices outlining recent known threats on the internet and also receive test phishing emails biweekly. Failure of the phishing test requires additional training.
2. Physical Control
We as Cendyn defined appropriate organizational (accompanying externals) and technical measures (key card token system) to protect against unauthorized physical access.
2-1 Definition of Security Areas
General areas can be accessed by all employees with their authorization badge.
The access is always bound to the exact location of employment.
Restricted areas can only be accessed by authorized employees with separated access mechanisms (e.g. different authorization badges, keys)
365 Data Center physical access to the facility by requiring ID badges that are scanned for entry. Visitors require advance notice and proper ID and must enter through a reception area. They are required to sign in, and ID is matched to the advance reservation.
3. System / Data Access Control
We as Cendyn defined appropriate technical (e.g. login credentials) and technical organizational measures (e.g. access permissions through group policy based on AD groups) to protect against unauthorized system access.
3-1 Architecture and Data Segregation
Cendyn production and non-production environments are separated as required by policy. The systems exposed to the internet are kept isolated from internal systems that process and store data. The internal systems have several layers of protection including multiple firewall devices, access control lists, and intrusion detection systems. Access to network devices for management purposes are only provided through a logically and separate administration network.
Cendyn separates development, QA, staging, and production networks to reduce the risk of unauthorized access to, or changes in production. Segregation of duties is implemented to minimize the risk of negligence and to prevent intentional abuse of systems.
Cendyn customer data is separated by server and logical controls within the application.
Client data is retained per client request. All client data is routinely saved until the client is no longer contracted with Cendyn when it is purged and deleted. Some clients prefer a systematic purge and delete which can be set up and run to the client specifications.
3-2 Access Management
Cendyn corporate policies provide guidelines for managing access management, privileged access, and handling initial passwords.
Cendyn corporate policies provide guidelines to manage the identity lifecycle, access management, privileged access, handling of initial passwords, and identity de-registration:
Formal access management processes and procedures are required to allocate the lowest level of system access rights required to allow the user to fulfill the assigned duties.
Formal processes and procedures are required for the secure usage of privileged access. Management is responsible for the setup and operation of every user account with privileged access rights. The approval and usage of privileged accounts is based on need-to-use, need-to-handle, and least privilege principles. Users with privileged accounts are kept to a minimum. Multifactor authentication is enabled and implemented to get access to more critical infrastructure and/or secure environments.
Product Access – Hotel Users
Admin Role has single property access to all functionality plus access to add/remove users and to view all users and proposals.
Non-Admin Role has access to all functionality for themselves only.
Handling of Initial Passwords
A formal password provisioning procedure is required to securely allocate initial passwords to users. Every Cendyn user account must have a unique initial password assigned to the user and must be communicated to the user in a secure manner. The initial password is only temporary and must be changed by the user upon first logon.
Admin user password security
Cannot be all digits
Cannot be all lowercase letters
Cannot be all Uppercase letters
Cannot be all Mix letters
Cannot be all Uppercase letters (this includes numbers)
Cannot be all lowercase letters (this includes numbers)
Must be more than 6 characters
Must be less than 15 characters
Cannot contain ‘password’, including leet variants
Cannot contain ‘qwerty’, including leet variants
Cannot be simple word with 123…
Cannot be simple word with 123 or 1234… prepended
Cannot be simple word with 1’s appended
Cannot be simple word with 1’s prepended
User is locked out after 5 incorrect tries
Cendyn corporate policies define security mechanism requirements for accessing Cendyn systems and applications to avoid or impede unauthorized access. The policy outlines the controls in place including secure log-on procedures, password management systems, use of privileged utility programs, and access control to program source code.
Secure log-on procedures
Systems and technical owners implement and manage secure log-on procedures/measures to support control and minimize access to Cendyn systems. Examples would include:
- The number of unsuccessful log-on attempts is limited to a maximum of five attempts.
- The passwords are not transmitted in plain text over any network.
Password Management Systems
- The password procedure enforces complex passwords.
Access control to program source code
- Technical owners implement and manage procedures for access to the source code to prevent the introduction of unauthorized functionality and to avoid unintentional changes, access to the program source code.
- All changes to the application are strictly controlled and follow the appropriate change process.
- Access to the source code and associated items (e.g. designs, specifications, verification plans, validation plans, etc.), are granted on a need to know basis and strictly controlled.
The source code is centrally managed, and access is logged.
4. System Security Control
Cendyn corporate policies define the requirements for cryptographic algorithms, protocols, and handling the underlying cryptographic keys (generation, use, protection, selection, and lifetime). The requirements are based on industry best practices. Various methods are being utilized to secure data at rest and in transit.
Cendyn Products provide a minimum of TLS 1.2 to encrypt data in motion and industry-standard AES 256 or higher for data at rest. Regarding data backup, we use Dell/EMC SAN devices in our 100% Virtual Infrastructure where data is stored, and these devices natively run (AES-XTS) 256 encryption.
4-2 Anti Malware
The Cendyn corporate policy framework defines procedures and controls for handling the protection of systems from malware. Cendyn systems are protected to prevent, detect and remove malware and ensure that users are aware of the risks that might arise.
Cendyn employees are made aware of the risks that malware might cause and which preventive measures they can take via annual training and weekly security updates. Examples of potential risks include:
- Installing software on Cendyn managed software
- Downloading files
- Attachments to suspicious emails.
- Use of removable media
- Reporting suspicious or possible malware infection.
- USB Drop Tests
Cendyn systems are automatically and regularly inspected for malware. At least the following elements are inspected:
- Emails and attachments transferred via Cendyn emails systems before use.
- Files received by any medium, before use.
- Content published on the Intranet and Internet.
- Access to websites
- All data, software and other files from removable storage.
Logging and Monitoring
Cendyn uses a combination of tools to monitor our Applications Availability, Logs and Performance. We have procedures and tools for the following activities:
- Infrastructure performance and monitoring
- Application code and errors monitoring.
- Site monitoring and availability metrics
- Security events correlation using a SIEM tool