CyberSecurity Corporate Policies

OMNI.PRO
(ATM SERVICES CORPORATION, S.A)
CYBERSECURITY CORPORATE POLICIES
(Last Update Status: Updated MARCH 2019)

Scope

This policy must be read and verified by all employees, contractors, volunteers and anyone who has permanent or temporary access to our systems and hardware. All are required to recertify their compliance to Omni.Pro’s Cybersecurity Corporate Policies on an annual basis.

Responsible Team

The Information Security Team (InfoSec Team) will verify compliance to these policies through various methods, including but not limited to, business tool reports, internal and external audits, and feedback. This team is headed by Omni.Pro’s Information Systems Manager, ANGEL CAMPOS.

I. Ethics Policy

1. Overview

Omni.Pro is committed to protecting employees, partners, vendors and the company from illegal or damaging actions by individuals, either knowingly or unknowingly. When Omni.Pro addresses issues proactively and uses correct judgment, it will help set us apart from competitors.
Omni.Pro will not tolerate any wrongdoing or impropriety at any time. Omni.Pro will take the appropriate measures act quickly in correcting the issue if the ethical code is broken.

2. Purpose

The purpose of this policy is to establish a culture of openness, trust and to emphasize the employee’s and consumer’s expectation to be treated to fair business practices. This policy will serve to guide business behavior to ensure ethical conduct. Effective ethics is a team effort involving the participation and support of every Omni.Pro employee. All employees should familiarize themselves with the ethics guidelines that follow this introduction.

3. Scope

This policy applies to employees, contractors, consultants, temporaries, and other workers at Omni.Pro, including all personnel affiliated with third parties.

4. Policy

4.1 Executive Commitment to Ethics

4.1.1 Senior leaders and executives within Omni.Pro must set a prime example. In any business practice, honesty and integrity must be top priority for executives.

4.1.2 Executives must have an open door policy and welcome suggestions and concerns from employees. This will allow employees to feel comfortable discussing any issues and will alert executives to concerns within the work force.

4.1.3 Executives must disclose any conflict of interests regard their position within Omni.Pro.

4.2 Employee Commitment to Ethics

4.2.1 Omni.Pro employees will treat everyone fairly, have mutual respect, promote a team environment and avoid the intent and appearance of unethical or compromising practices.

4.2.2 Every employee needs to apply effort and intelligence in maintaining ethics value.

4.2.3 Employees must disclose any conflict of interests regard their position within Omni.Pro.

4.2.4 Employees will help Omni.Pro to increase customer and vendor satisfaction by providing quality product s and timely response to inquiries.

4.2.5 Employees should consider the following questions to themselves when any behavior is questionable:

· Is the behavior legal?

· Does the behavior comply with all appropriate Omni.Pro policies?

· Does the behavior reflect Omni.Pro values and culture?

· Could the behavior adversely affect company stakeholders?

· Would you feel personally concerned if the behavior appeared in a news headline?

· Could the behavior adversely affect Omni.Pro if all employees did it?

4.3 Company Awareness

4.3.1 Promotion of ethical conduct within interpersonal communications of employees will be rewarded.

4.3.2 Omni.Pro will promote a trustworthy and honest atmosphere to reinforce the vision of ethics within the company.

4.4 Maintaining Ethical Practices

4.4.1 Omni.Pro will reinforce the importance of the integrity message and the tone will start at the top. Every employee, manager, director needs consistently maintain an ethical stance and support ethical behavior.

4.4.2 Employees at Omni.Pro should encourage open dialogue, get honest feedback and treat everyone fairly, with honesty and objectivity.

4.4.3 Employees are required to recertify their compliance to Ethics Policy on an annual basis.

4.5 Unethical Behavior

4.5.1 Omni.Pro will avoid the intent and appearance of unethical or compromising practice in relationships, actions and communications.

4.5.2 Omni.Pro will not tolerate harassment or discrimination.

4.5.3 Unauthorized use of company trade secrets & marketing, operational, personnel, financial, source code, & technical information integral to the success of our company will not be tolerated.

4.5.4 Omni.Pro will not permit impropriety at any time and we will act ethically and responsibly in accordance with laws.

4.5.5 Omni.Pro employees will not use corporate assets or business relationships for personal use or gain.

5. Policy Compliance

5.1 Compliance Measurement

The InfoSec Team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback.

5.2 Exceptions

None.

5.3 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

II. Password Protection Policy

1. Overview

Passwords are an important aspect of computer security. A poorly chosen password may result in unauthorized access and/or exploitation of Omni.Pro’s resources. All users, including contractors and vendors with access to Omni.Pro systems, are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.

2. Purpose

The purpose of this policy is to establish a standard for creation of strong passwords, the protection of those passwords, and the frequency of change.

3. Scope

The scope of this policy includes all personnel who have or are responsible for an account (or any form of access that supports or requires a password) on any system that resides at any Omni.Pro facility, has access to the Omni.Pro network, or stores any non-public Omni.Pro information.

4. Policy

4.1 Password Creation

4.1.1 Users must not use the same password for Omni.Pro accounts as for other non-Omni.Pro access.

4.1.2 Where possible, users must not use the same password for various Omni.Pro access needs.

4.1.3 User accounts that have system-level privileges granted through group memberships or programs such as sudo must have a unique password from all other accounts held by that user to access system-level privileges.

4.2 Password Change

4.2.1 All system-level passwords (for example, root, enable, NT admin, application administration accounts, and so on) must be changed on at least a quarterly basis.

4.2.2 All user-level passwords (for example, email, web, desktop computer, and so on) must be changed at least every six months. The recommended change interval is every four months.

4.2.3 Password cracking or guessing may be performed on a periodic or random basis by the Infosec Team or its delegates. If a password is guessed or cracked during one of these scans, the user will be required to change it to be in compliance with the Password Construction Guidelines.

4.3 Password Protection

4.3.1 Passwords must not be shared with anyone. All passwords are to be treated as sensitive, Confidential Omni.Pro information. Corporate Information Security recognizes that legacy applications do not support proxy systems in place. Please refer to the technical reference for additional details.

4.3.2 Passwords must not be inserted into email messages, Alliance cases or other forms of electronic communication.

4.3.3 Passwords must not be revealed over the phone to anyone.

4.3.4 Do not reveal a password on questionnaires or security forms.

4.3.5 Do not hint at the format of a password (for example, “my family name”).

4.3.6 Do not share Omni.Pro passwords with anyone, including administrative assistants, secretaries, managers, co-workers while on vacation, and family members.

4.3.7 Do not write passwords down and store them anywhere in your office. Do not store passwords in a file on a computer system or mobile devices (phone, tablet) without encryption.

4.3.8 Do not use the “Remember Password” feature of applications (for example, web browsers).

4.3.9 Any user suspecting that his/her password may have been compromised must report the incident and change all passwords.

4.4 Application Development

Application developers must ensure that their programs contain the following security precautions:

4.4.1 Applications must support authentication of individual users, not groups.

4.4.2 Applications must not store passwords in clear text or in any easily reversible form.

4.4.3 Applications must not transmit passwords in clear text over the network.

4.4.4 Applications must provide for some sort of role management, such that one user can take over the functions of another without having to know the other’s password.

5. Policy Compliance

5.1 Compliance Measurement

The Infosec team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner.

5.2 Exceptions

Any exception to the policy must be approved by the Infosec Team in advance.

5.3 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

III. Disaster Recovery Plan Policy

1. Overview

It is important to realize that having a contingency plan in the event of a disaster gives Omni.Pro a competitive advantage. This policy requires management to financially support and diligently attend to disaster contingency planning efforts. Disasters are not limited to adverse weather conditions. Any event that could likely cause an extended delay of service should be considered

2. Purpose

This policy defines the requirement for a baseline disaster recovery plan to be developed and implemented by Omni.Pro that will describe the process to recover IT Systems, Applications and Data from any type of disaster that causes a major outage.

3. Scope

This policy is directed to the IT Management Staff who is accountable to ensure the plan is developed, tested and kept up-to-date. This policy is solely to state the requirement to have a disaster recovery plan, it does not provide requirement around what goes into the plan or sub-plans.

4. Policy

4.1 Contingency Plans

· In the event of an emergency, please contact the following people:

o Jose Fábrega: + 507 66718902

o Rubén García: + 507 6658 8989

o Angel Campos: + 507 6946 3934

· Data Backup and Restoration Plan: All Data & applications are backed up on the following server (with redundancy):

o AWS https://omnipro.signin.aws.amazon.com/console user “monitor”, Account ID omnipro

o With data centers in Regions all around the world, AWS provides a set of cloud-based disaster recovery services that enable rapid recovery of our IT infrastructure and data. ( https://aws.amazon.com/about-aws/global-infrastructure/ )

· Should the primary office on PH Ocean Business Plaza 1303 Calle Aquilino de la Guardia not be Accessible, all personnel are required to meet at Omni.Pro’s secondary location on Calle 39 Este, Edf. Doña Raquel, Piso 5.

  • Equipment Replacement Plan: Should our staff’s individual computers not be accessible, 15 laptops with following specifications must be ordered from the Panafoto location on Calle 50 on Omni.Pro’s Corporate account.

o Processor: Intel Core i7 or higher

o Operating System: Windows 10 Pro

o RAM: 8GB or higher

o Hard Drive: 500 GB or higher

  • Mass Media Management: All media inquiries must be channeled through either Jose Fábrega, or Rubén García.

5. Policy Compliance

5.4 Compliance Measurement

The Infosec team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, and internal and external audits.

5.5 Exceptions

Any exception to the policy must be approved by the Infosec Team in advance.

5.6 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

IV. Database Credentials Coding Policy

1. Overview

Database authentication credentials are a necessary part of authorizing application to connect to internal databases. However, incorrect use, storage and transmission of such credentials could lead to compromise of very sensitive assets and be a springboard to wider compromise within the organization.

2. Purpose

This policy states the requirements for securely storing and retrieving database usernames and passwords (i.e., database credentials) for use by a program that will access a database running on one of Omni.Pro’s networks.

Software applications running on Omni.Pro’s networks may require access to one of the many internal database servers. In order to access these databases, a program must authenticate to the database by presenting acceptable credentials. If the credentials are improperly stored, the credentials may be compromised leading to a compromise of the database.

3. Scope

This policy is directed at all system implementer and/or software engineers who may be coding applications that will access a production database server on the Omni.Pro Network. This policy applies to all software (programs, modules, libraries or APIS that will access a Omni.Pro, multi-user production database. It is recommended that similar requirements be in place for non-production servers and lap environments since they don’t always use sanitized information.

4. Policy

General

In order to maintain the security of Omni.Pro’s internal databases, access by software programs must be granted only after authentication with credentials. The credentials used for this authentication must not reside in the main, executing body of the program’s source code in clear text. Database credentials must not be stored in a location that can be accessed through a web server.

Specific Requirements

Storage of Data Base User Names and Passwords

· Database user names and passwords may be stored in a file separate from the executing body of the program’s code. This file must not be world readable or writeable.

· Database credentials may reside on the database server. In this case, a hash function number identifying the credentials may be stored in the executing body of the program’s code.

· Database credentials may be stored as part of an authentication server (i.e., an entitlement directory), such as an LDAP server used for user authentication. Database authentication may occur on behalf of a program as part of the user authentication process at the authentication server. In this case, there is no need for programmatic use of database credentials.

· Database credentials may not reside in the documents tree of a web server.

· Pass through authentication must not allow access to the database based solely upon a remote user’s authentication on the remote host.

· Passwords or pass phrases used to access a database must adhere to the Password Policy.

Retrieval of Database User Names and Passwords

· If stored in a file that is not source code, then database user names and passwords must be read from the file immediately prior to use. Immediately following database authentication, the memory containing the user name and password must be released or cleared.

· The scope into which you may store database credentials must be physically separated from the other areas of your code, e.g., the credentials must be in a separate source file. The file that contains the credentials must contain no other code but the credentials (i.e., the user name and password) and any functions, routines, or methods that will be used to access the credentials.

· For languages that execute from source code, the credentials’ source file must not reside in the same browseable or executable file directory tree in which the executing body of code resides.

Access to Database User Names and Passwords

· Every program or every collection of programs implementing a single business function must have unique database credentials. Sharing of credentials between programs is not allowed.

· Database passwords used by programs are system-level passwords as defined by the Password Policy.

· Developer groups must have a process in place to ensure that database passwords are controlled and changed in accordance with the Password Policy. This process must include a method for restricting knowledge of database passwords to a need-to-know basis.

Upon termination of an employee or other person with access, the manager of Information Systems will immediately take the following actions:

· Revoke access privileges, such as user IDs and passwords, to system and data resources and secure areas.

· Retrieve all hardware, software, data, access control items, and documentation issued to or otherwise in the possession of the data user.

· Arrange for an exit briefing to verify retrieval of all items, to discuss any security/confidentiality concerns with the data user, and to remind the data user of the continuing need to protect data security and patient confidentiality.

· Notify human resources of completion of the termination procedure so that the data user can receive any final pay due.

· Keep records of the termination procedure for each such person, including the retrieval of security related items, such as passwords, and information system assets, for not less than six years from the termination date.

· When necessary, the manager of Information Systems, the manager of Health Information Management, a facility administrator or director of Human Resources will arrange for security escort of terminated personnel from the facility and for an immediate audit of their accounts to detect any security or confidentiality threats or breaches.

5. Policy Compliance

5.1. Compliance Measurement

5.1.1. The Infosec team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

5.2. Exceptions

5.2.1. Any exception to the policy must be approved by the Infosec team in advance.

5.3. Non-Compliance

5.3.1. An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

5.3.2. A violation of this policy by a temporary worker, contractor or vendor may result in the termination of their contract or assignment with Omni.Pro.

5.3.3. Any program code or application that is found to violate this policy must be remediated within a 90 day period.

V. Software Installation Policy

1. Overview

Allowing employees to install software on company computing devices opens the organization up to unnecessary exposure. Conflicting file versions or DLLs which can prevent programs from running, the introduction of malware from infected installation software, unlicensed software which could be discovered during audit, and programs which can be used to hack the organization’s network are examples of the problems that can be introduced when employees install software on company equipment.

2. Purpose

The purpose of this policy is to outline the requirements around installation software on Omni.Pro owned computing devices. To minimize the risk of loss of program functionality, the exposure of sensitive information contained within Omni.Pro’s computing network, the risk of introducing malware, and the legal exposure of running unlicensed software.

3. Scope

This policy applies to all Omni.Pro employees, contractors, vendors and agents with a Omni.Pro-owned mobile devices. This policy covers all computers, servers, smartphones, tablets and other computing devices operating within Omni.Pro.

4. Policy

· Employees may not install software on Omni.Pro’s computing devices operated within the Omni.Pro network.

· Software requests must first be approved by the requester’s manager and then be made to the Information Technology department or Help Desk in writing or via email.

· Software must be selected from an approved software list, maintained by the Information Technology department, unless no selection on the list meets the requester’s need.

· The Information Technology Department will obtain and track the licenses, test new software for conflict and compatibility, and perform the installation.

5. Policy Compliance

5.7 Compliance Measurement

The Infosec team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner.

5.8 Exceptions

Any exception to the policy must be approved by the Infosec team in advance.

5.9 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

VI. Acceptable Encryption Policy

1. Purpose

The purpose of this policy is to provide guidance that limits the use of encryption to those algorithms that have received substantial public review and have been proven to work effectively.

2. Scope

This policy applies to all Omni.Pro employees and affiliates.

3. Policy

4.1 Algorithm Requirements

4.1.1 Ciphers in use must meet or exceed the set defined as “AES-compatible” or “partially AES-compatible” according to the set defined for use in the United States National Institute of Standards and Technology (NIST) publication FIPS 140-2 (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2010.htm). The use of the Advanced Encryption Standard (AES) is strongly recommended for symmetric encryption.

4.1.2 Algorithms in use must meet the standards defined for use in NIST publication FIPS 140-2 (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2010.htm) or any superseding document, according to date of implementation.

4.2 Hash Function Requirements

In general, Omni.Pro adheres to the NIST Policy on Hash Functions (http://csrc.nist.gov/groups/ST/hash/policy.html

4.2.1 End points must be authenticated prior to the exchange or derivation of session keys.

4.2.2 Public keys used to establish trust must be authenticated prior to use. Examples of authentication include transmission via cryptographically signed message or manual verification of the public key hash.

4.2.3 All servers used for authentication must have installed a valid certificate signed by a known trusted provider.

4.2.4 All servers and applications using SSL or TLS must have the certificates signed by a known, trusted provider.

4.3 Key Generation

4.3.1 Cryptographic keys must be generated and stored in a secure manner that prevents loss, theft, or compromise.

4.3.2 Key generation must be seeded from an industry standard random number generator (RNG).

4. Policy Compliance

5.10 Compliance Measurement

The InfoSec team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner.

5.11 Exceptions

Any exception to the policy must be approved by the Infosec team in advance.

5.12 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

VII. Separation of Duties Policy

1. Purpose

Separation of Duties is an attempt to ensure that no single individual has the capability of executing a particular task/set of tasks.

2. Policy

· Development staff should not have access to production data, unless specifically authorized by the functional data owner to repair a limited number of records.

· Development staff should not access system level technology or database management systems.

· End users should not have access to production data except through the features and functions of the administrative applications; in particular, they should not have the ability to bypass or circumvent the applications’ validation and audit procedures.

  • Functional users should not access or modify application code.
  • Systems programmers should not access application code.

· Accounts should be approved by the data steward and subsequently created by a separate, independent system security administrator.

· Access to system logs and system audits should be limited to the system security analysts, and all such access should be reviewed by IT management.

· Access to firewalls and other network security systems should be limited to the network security analysts, and all such access should be reviewed by IT management.

3. Policy Compliance

5.13 Compliance Measurement

The Infosec team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, and internal and external audits.

5.14 Exceptions

Any exception to the policy must be approved by the Infosec Team in advance.

5.15 Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.