Commit 732ccfcd authored by Marcello Evangelista's avatar Marcello Evangelista

security policy fixed upload

parent bf103d85
No preview for this file type
# Welcome to OlinData's Security Policy repo
This repository contains the current security policy in place. Please keep in mind that we will consistently update this repo to make our practices on par with the most recent security trends and compliance standards.
We are open to listen your suggestions and you're free to branch this repo should you want to contribute. No master commits should be done without proper review.
--
OlinData SecOps Team
# Purpose
The purpose of this policy is to define web application security assessments within OlinData BV. Web application assessments are performed to identify potential or realised weaknesses as a result of inadvertent mis-configuration, weak authentication, insufficient error handling, sensitive information leakage, etc. Discovery and subsequent mitigation of these issues will limit the attack surface of OlinData BV services available both internally and externally as well as satisfy compliance with any relevant policies in place.
# Scope
This policy covers all web application security assessments requested by any individual, group or department for the purposes of maintaining the security posture, compliance, risk management, and change control of technologies in use at OlinData BV.
All web application security assessments will be performed by delegated security personnel either employed or contracted by OlinData BV. All findings are considered confidential and are to be distributed to persons on a “need to know” basis. Distribution of any findings outside of OlinData BV is strictly prohibited unless approved by the Chief Information Officer.
Any relationships within multi-tiered applications found during the scoping phase will be included in the assessment unless explicitly limited. Limitations and subsequent justification will be documented prior to the start of the assessment.
# Policy
1. Web applications are subject to security assessments based on the following criteria:
* New or Major Application Release – will be subject to a full assessment prior to approval of the change control documentation and/or release into the live environment.
* Third Party or Acquired Web Application – will be subject to full assessment after which it will be bound to policy requirements.
* Point Releases – will be subject to an appropriate assessment level based on the risk of the changes in the application functionality and/or architecture.
* Patch Releases – will be subject to an appropriate assessment level based on the risk of the changes to the application functionality and/or architecture
* Emergency Releases – An emergency release will be allowed to forgo security assessments and carry the assumed risk until such time that a proper assessment can be carried out. Emergency releases will be designated as such by the Chief Information Officer or an appropriate manager who has been delegated this authority.
1. All security issues that are discovered during assessments must be mitigated based upon the following risk levels. The Risk Levels are based on the OWASP Risk Rating Methodology. Remediation validation testing will be required to validate fix and/or mitigation strategies for any discovered issues of Medium risk level or greater.
* High – Any high risk issue must be fixed immediately or other mitigation strategies must be put in place to limit exposure before deployment. Applications with high risk issues are subject to being taken off-line or denied release into the live environment.
* Medium – Medium risk issues should be reviewed to determine what is required to mitigate and scheduled accordingly. Applications with medium risk issues may be taken off-line or denied release into the live environment based on the number of issues and if multiple issues increase the risk to an unacceptable level. Issues should be fixed in a patch/point release unless other mitigation strategies will limit exposure.
* Low – Issue should be reviewed to determine what is required to correct the issue and scheduled accordingly.
1. The following security assessment levels shall be established by the InfoSec organisation or other designated organisation that will be performing the assessments.
* Full – A full assessment is comprised of tests for all known web application vulnerabilities using both automated and manual tools based on the OWASP Testing Guide. A full assessment will use manual penetration testing techniques to validate discovered vulnerabilities to determine the overall risk of any and all discovered.
* Quick – A quick assessment will consist of a (typically) automated scan of an application for the OWASP Top Ten web application security risks at a minimum.
* Targeted – A targeted assessment is performed to verify vulnerability remediation changes or new application functionality.
1. The current approved web application security assessment tools in use which will be used for testing are:
* Nessus
* OpenVas
* Burp Suite
* OWASP Zap
# Policy Compliance
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.
1. Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
1. Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
# Revision History
Please check the commit history for this file.
# Purpose
The purpose of this document is to serve as a guideline to all upcoming audits and it should be enforced at every assessment.
# Scope
This policy applies to all OlinData BV employees and affiliates.
# Policy
1. Periodic Audits
Twice a year a full audit will happen under the effort to maintain a sane ISMS and a safe environment. The periodic audits will also be used as an assessment point of the current state of the Business Continuity Plan and, if needed, serve as evidence of changes.
The Periodic Audits will cover the following:
1. State of the current active assets.
This assessment involves:
* Self-assessment and reporting of individual assets provided by OlinData BV or used to fulfil work in behalf of the company.
1. State of hosted applications and infrastructure.
This assessment involves:
* Evaluation of the current applied technology.
* Applied patches and corrections.
* Automated scanning/port-scanning.
* Manual testing.
1. State of vendors technology.
This assessment involves:
* Evaluation of the current vendors regarding recent incidents, breaches and 0-days.
* Evaluate the current environment and check which solutions could/should be removed from the ecosystem.
1. State of guidelines adherence.
This assessment involves:
* Check how compliant the company is to the general guidelines and assess possible improvements.
# Policy Compliance
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.
1. Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
1. Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
# Revision History
Please check the commit history for this file.
# 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.
# Scope
This policy applies to all OlinData BV employees and affiliates.
# Policy
1. Algorithm Requirements
1. Ciphers in use must meet or exceed the set defined as "AES-compatible" or "partially AES-compatible" according to the IETF/IRTF Cipher Catalog, or the set defined for use in the United States National Institute of Standards and Technology (NIST) publication FIPS 140-2, or any superseding documents according to the date of implementation. The use of the Advanced Encryption Standard (AES) is strongly recommended for symmetric encryption.
1. Algorithms in use must meet the standards defined for use in NIST publication FIPS 140-2 or any superseding document, according to date of implementation. The use of the RSA and Elliptic Curve Cryptography (ECC) algorithms is strongly recommended for asymmetric encryption.
1. Signature Algorithms
| Algorithm | Key (min) | Additional Comment |
| ------------- |:-------------:| -----:|
| ECDSA | P-256 | Check the compliances involved before |
| RSA | 2048 | Must use the a secure padding |
| LDWM | SHA256 | Check the internal standard of usage |
1. Hash Function Requirements
In general, OlinData BV adheres to the NIST Policy on Hash Functions.
1. Key Agreement and Authentication
1. Key exchanges must use one of the following cryptographic protocols: Diffie-Hellman, IKE, or Elliptic curve Diffie-Hellman (ECDH).
1. End points must be authenticated prior to the exchange or derivation of session keys.
1. 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.
1. All servers used for authentication must have installed a valid certificate signed by a known trusted provider.
1. All servers and applications using SSL or TLS must have the certificates signed by a known, trusted provider and completely avoid the usage of RC4-based certificates.
1. Key Generation
1. Cryptographic keys must be generated and stored in a secure manner that prevents loss, theft, or compromise.
1. Key generation must be seeded from an industry standard random number generator (RNG). For examples, see NIST Annex C: Approved Random Number Generators for FIPS PUB 140-2.
# Policy Compliance
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.
1. Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
1. Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
# Revision History
Please check the commit history for this file.
This diff is collapsed.
# Purpose
The purpose for this policy is to establish the minimum requirements for maintaining a “clean desk” – where sensitive/critical information about our employees, our intellectual property, our customers and our vendors is secure in locked areas and out of site. A Clean Desk policy is not only ISO 27001/17799 compliant, but it is also part of standard basic privacy controls.
# Scope
This policy applies to all OlinData BV employees and affiliates
# Policy
1. Employees are required to ensure that all sensitive/confidential information in hardcopy or electronic form is secure in their work area at the end of the day and when they are expected to be gone for an extended period.
1. Computer workstations must be locked when workspace is unoccupied.
1. Computer workstations must be shut completely down at the end of the work day.
1. Any Restricted or Sensitive information must be removed from the desk and locked in a drawer when the desk is unoccupied and at the end of the work day.
1. File cabinets containing Restricted or Sensitive information must be kept closed and locked when not in use or when not attended.
1. Keys used for access to Restricted or Sensitive information must not be left at an unattended desk.
1. Laptops must be either locked with a locking cable or locked away in a drawer.
1. Passwords may not be left on sticky notes posted on or under a computer, nor may they be left written down in an accessible location.
1. Printouts containing Restricted or Sensitive information should be immediately removed from the printer.
1. Upon disposal Restricted and/or Sensitive documents should be shredded in the official shredder bins or placed in the lock confidential disposal bins.
1. Whiteboards containing Restricted and/or Sensitive information should be erased.
1. Lock away portable computing devices such as laptops and tablets.
1. Treat mass storage devices such as CDROM, DVD or USB drives as sensitive and secure them in a locked drawer
1. All printers and fax machines should be cleared of papers as soon as they are printed; this helps ensure that sensitive documents are not left in printer trays for the wrong person to pick up.
# Policy Compliance
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.
1. Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
1. Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
# Revision History
Please check the commit history for this file.
# Purpose
The purpose of this email policy is to ensure the proper use of OlinData BV email system and make users aware of what OlinData BV deems as acceptable and unacceptable use of its email system. This policy outlines the minimum requirements for use of email within OlinData BV Network.
# Scope
This policy covers appropriate use of any email sent from a OlinData BV email address and applies to all employees, vendors, and agents operating on behalf of OlinData BV.
# Policy
1. All use of email must be consistent with OlinData BV policies and procedures of ethical conduct, safety, compliance with applicable laws and proper business practices. 
1. OlinData BV email account should be used primarily for OlinData BV business-related purposes; personal communication is permitted on a limited basis, but non-OlinData BV related commercial uses are prohibited.
1. All OlinData BV data contained within an email message or an attachment must be secured according to the Data Protection Standard.
1. Email should be retained only if it qualifies as a OlinData BV business record. Email is a OlinData BV business record if there exists a legitimate and ongoing business reason to preserve the information contained in the email.
1. Email that is identified as a OlinData BV business record shall be retained according to OlinData BV Record Retention Schedule.
1. The OlinData BV email system shall not to be used for the creation or distribution of any disruptive or offensive messages, including offensive comments about race, gender, hair color, disabilities, age, sexual orientation, pornography, religious beliefs and practice, political beliefs, or national origin. Employees who receive any emails with this content from any OlinData BV employee should report the matter to their supervisor immediately.
1. Users are prohibited from automatically forwarding OlinData BV email to a third party email system (noted in 4.8 below). Individual messages which are forwarded by the user must not contain OlinData BV confidential or above information.
1. Users are prohibited from using third-party email systems and storage servers such as Google, Yahoo, and MSN Hotmail etc. to conduct OlinData BV business, to create or memorialise any binding transactions, or to store or retain email on behalf of OlinData BV.  Such communications and transactions should be conducted through proper channels using OlinData BV-approved documentation. 
1. Using a reasonable amount of OlinData BV resources for personal emails is acceptable, but non-work related email shall be saved in a separate folder from work related email. Sending chain letters or joke emails from a OlinData BV email account is prohibited.
1. OlinData BV employees shall have no expectation of privacy in anything they store, send or receive on the company’s email system.
1. OlinData BV may monitor messages without prior notice. OlinData BV is not obliged to monitor email messages.
# Policy Compliance
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.
1. Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
1. Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
# Revision History
Please check the commit history for this file.
# 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.
# 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 OlinData BV facility, has access to the OlinData BV network, or stores any non- public OlinData BV information.
# Policy
1. Password Creation
All passwords/Passphrases should meet or exceed the following guidelines:
1. Contain at least 12 alphanumeric characters.
1. Contain both upper and lower case letters.
1. Contain at least one number (for example, 0-9).
1. Contain at least one special character.
1. Should not be found in a dictionary, including foreign language, or exist in a language slang, dialect, or jargon.
1. Should not contain personal information such as birthdates, addresses, phone numbers or any other easy-to-find information.
1. Should not contain work-related information such as building names, system commands, sites, companies, hardware or software.
1. Should not contain easy alphanumeric patterns.
1. Should not contain common words spelled backwards, preceded or followed by a number.
1. Passwords/Passphrases Changes
1. Passwords/Passphrases should not be written down or shared under any circumstances. All passwords are to be treated as sensitive, confidential OlinData BV information.
1. Passwords/Passphrases must not be inserted into email messages, Alliance cases or other forms of electronic communication.
1. Passwords/Passphrases must not be revealed over the phone to anyone.
1. Passwords/Passphrases should not be revealed over questionnaires or security forms. Do not reveal a password on questionnaires or security forms.
1. Passwords/Passphrases hints should not be shared.
1. No passwords/passphrases from OlinData BV are meant to be shared internally.
1. Under suspicion of breach/leak, the occurrence should be shared with the Infosec Team and all passwords/passphrases should be changed.
# Policy Compliance
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.
1. Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
1. Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
# Revision History
Please check the commit history for this file.
# Purpose
The purpose of this policy is to establish the requirement that all business units supported by the Infosec team develop and maintain a security response plan. This ensures that security incident management team has all the necessary information to formulate a successful response should a specific security incident occur.
# Scope
This policy applies any established and defined business unity or entity within the OlinData BV.
# Policy
The development, implementation, and execution of a Security Response Plan (SRP) are the primary responsibility of the specific business unit for whom the SRP is being developed in cooperation with the Infosec Team. Business units are expected to properly facilitate the SRP for applicable to the service or products they are held accountable. The business unit security coordinator or champion is further expected to work with the SecOps Team in the development and maintenance of a Security Response Plan.
1. Service or Product Description
The product description in an SRP must clearly define the service or application to be deployed with additional attention to data flows, logical diagrams, architecture considered highly useful.
1. Contact Information
The SRP must include contact information for dedicated team members to be available during non-business hours should an incident occur and escalation be required. This may be a 24/7 requirement depending on the defined business value of the service or product, coupled with the impact to customer. The SRP document must include all phone numbers and email addresses for the dedicated team member(s).
1. Triage
The SRP must define triage steps to be coordinated with the security incident management team in a cooperative manner with the intended goal of swift security vulnerability mitigation. This step typically includes validating the reported vulnerability or compromise.
1. Identified Mitigations and Testing
The SRP must include a defined process for identifying and testing mitigations prior to deployment. These details should include both short-term mitigations as well as the remediation process.
1. Mitigation and Remediation Timelines
The SRP must include levels of response to identified vulnerabilities that define the expected timelines for repair based on severity and impact to consumer, brand, and company. These response guidelines should be carefully mapped to level of severity determined for the reported vulnerability.
# Policy Compliance
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.
1. Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
1. Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
# Revision History
Please check the commit history for this file.
# Purpose
This policy is a way to standardise our internal usage of the currently hired cloud providers and any others we may use in the future.
# Scope
This policy applies to the engineering team and any other technical bodies from the company.
# Policy
1. Vendor Qualification
At this moment, OlinData BV only uses Major Cloud Providers internally due to their compliant platforms and well-established technical policies. The following providers are currently used:
* Amazon Web Services
* Microsoft Azure
* Google Cloud Platform
As general practice, OlinData BV does not deal with minor providers internally in order to maintain the best level of Compliance, Availability and Usability. In case of need, the Infosec Team and Management should advise.
1. General Procedures
1. All users should be gauged with minimal viable access and administrative access is reserved to Lead Engineers and Management.
1. Multi-factor Authentication should be set as a standard procedure for login and critical changes.
1. Token-based usage should be tracked and only granted with a justification.
1. Non-used resources should be eliminated and not maintained in halt state.
1. All disk resources involved in sensitive data processing should be encrypted not only in transit but also at rest.
1. Buckets should be private by standard and public buckets should be justified.
1. Buckets should have deletion-protection and versioning enabled by default. Any alterations to this should be justified.
1. In case of a multi-account setup, access should be centralised in a single account and then allowed to access any sub-accounts.
1. The platforms should use an automated form of constant assessment of best practices provided by the Infosec team.
1. Test environments should be isolated from Production environments and both are susceptible to audits.
# Policy Compliance
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.
1. Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
1. Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
# Revision History
Please check the commit history for this file.
# 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 OlinData BV's networks.
Software applications running on OlinData BV'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.
# 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 OlinData BV Network. This policy applies to all software (programs, modules, libraries or APIS that will access a OlinData BV, 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 sanitised information.
# Policy
1. General
In order to maintain the security of OlinData BV'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.
1. Specific Requirements
1. TBD
1. Storage of Data Base User Names and Passwords
1. 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.
1. 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.
1. 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.
1. Database credentials may not reside in the documents tree of a web server.
1. Pass through authentication (i.e., Oracle OPS$ authentication) must not allow access to the database based solely upon a remote user's authentication on the remote host.
1. Passwords or pass phrases used to access a database must adhere to the Password Policy.
1. Retrieval of Database User Names and Passwords
1. 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.
1. 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.
1. 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.
1. Access to Database User Names and Passwords
1. 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.
1. Database passwords used by programs are system-level passwords as defined by the Password Policy.
1. 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.
1. Coding Techniques for implementing this policy
1. TBD
# Policy Compliance
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.
1. Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
1. Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
# Revision History
Please check the commit history for this file.
# Purpose
The purpose of this policy is to define rules and requirements for connecting to OlinData BV's network from any host. These rules and requirements are designed to minimise the potential exposure to OlinData BV from damages which may result from unauthorised use of OlinData BV resources. Damages include the loss of sensitive or company confidential data, intellectual property, damage to public image, damage to critical OlinData BV internal systems, and fines or other financial liabilities incurred as a result of those losses.
# Scope
This policy applies to all OlinData BV employees, contractors, vendors and agents with a OlinData BV-owned or personally-owned computer or workstation used to connect to the OlinData BV network. This policy applies to remote access connections used to do work on behalf of OlinData BV, including reading or sending email and viewing intranet web resources. This policy covers any and all technical implementations of remote access used to connect to OlinData BV networks.
# Policy
It is the responsibility of OlinData BV employees, contractors, vendors and agents with remote access privileges to OlinData BV's corporate network to ensure that their remote access connection is given the same consideration as the user's on-site connection to OlinData BV.
General access to the Internet for recreational use through the OlinData BV network is strictly limited to OlinData BV employees, contractors, vendors and agents (hereafter referred to as “Authorised Users”). When accessing the OlinData BV network from a personal computer, Authorized Users are responsible for preventing access to any OlinData BV computer resources or data by non-authorised Users. Performance of illegal activities through the OlinData BV network by any user (Authorised or otherwise) is prohibited. The Authorised User bears responsibility for and consequences of misuse of the Authorised User’s access. For further information and definitions, see the Acceptable Use Policy.
Authorised Users will not use OlinData BV networks to access the Internet for outside business interests.
For additional information regarding OlinData BV's remote access connection options, including how to obtain a remote access login, free anti-virus software, troubleshooting, etc., go to the Remote Access Services website (company url).
1. Requirements
1. Secure remote access must be strictly controlled with encryption (i.e., Virtual Private Networks (VPNs)) and strong pass-phrases. For further information see the Acceptable Encryption Policy and the Password Policy.
1. Authorised Users shall protect their login and password, even from family members.
1. While using a OlinData BV-owned computer to remotely connect to OlinData BV's corporate network, Authorised Users shall ensure the remote host is not connected to any other network at the same time, with the exception of personal networks that are under their complete control or under the complete control of an Authorised User or Third Party.
1. Use of external resources to conduct OlinData BV business must be approved in advance by InfoSec and the appropriate business unit manager.
1. All hosts that are connected to OlinData BV internal networks via remote access technologies must use the most up-to-date anti-virus software (place url to corporate software site here), this includes personal computers. Third party connections must comply with requirements as stated in the Third Party Agreement.
1. Personal equipment used to connect to OlinData BV's networks must meet the requirements of OlinData BV-owned equipment for remote access as stated in the Hardware and Software Configuration Standards for Remote Access to OlinData BV Networks.
# Policy Compliance
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.
1. Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
1. Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
# Revision History
Please check the commit history for this file.
# Purpose
The purpose of this policy is to establish standards for the base configuration of internal server equipment that is owned and/or operated by OlinData BV. Effective implementation of this policy will minimise unauthorised access to OlinData BV proprietary information and technology.
# Scope
All employees, contractors, consultants, temporary and other workers at OlinData BV and its subsidiaries must adhere to this policy. This policy applies to server equipment that is owned, operated, or leased by OlinData BV or registered under a OlinData BV-owned internal network domain.
This policy specifies requirements for equipment on the internal OlinData BV network. For secure configuration of equipment external to OlinData BV on the DMZ, see the Internet DMZ Equipment Policy.
# Policy
1. General Requirements
1. All internal servers deployed at OlinData BV must be owned by an operational group that is responsible for system administration. Approved server configuration guides must be established and maintained by each operational group, based on business needs and approved by InfoSec. Operational groups should monitor configuration compliance and implement an exception policy tailored to their environment. Each operational group must establish a process for changing the configuration guides, which includes review and approval by InfoSec. The following items must be met:
* Servers must be registered within the corporate enterprise management system. At a minimum, the following information is required to positively identify the point of contact:
* Server contact(s) and location, and a backup contact
* Hardware and Operating System/Version
* Main functions and applications, if applicable
* Information in the corporate enterprise management system must be kept up-to-date.
* Configuration changes for production servers must follow the appropriate change management procedures
1. For security, compliance, and maintenance purposes, authorised personnel may monitor and audit equipment, systems, processes, and network traffic per the Audit Policy.
1. Configuration Requirements
1. Operating System configuration should be in accordance with approved InfoSec guidelines.
1. Services and applications that will not be used must be disabled where practical.
1. Access to services should be logged and/or protected through access-control methods such as a web application firewall, if possible.
1. The most recent security patches must be installed on the system as soon as practical, the only exception being when immediate application would interfere with business requirements.
1. Trust relationships between systems are a security risk, and their use should be avoided. Do not use a trust relationship when some other method of communication is sufficient.
1. Always use standard security principles of least required access to perform a function. Do not use root when a non-privileged account will do.
1. If a methodology for secure channel connection is available (i.e., technically feasible), privileged access must be performed over secure channels, (e.g., encrypted network connections using SSH or IPSec).
1. Servers should be physically located in an access-controlled environment.
1. Servers are specifically prohibited from operating from uncontrolled cubicle areas.
1. Monitoring
1. All security-related events on critical or sensitive systems must be logged and audit trails saved as follows:
* All security related logs will be kept online for a minimum of 1 week.
* Daily incremental tape backups will be retained for at least 1 month.
* Weekly full tape backups of logs will be retained for at least 1 month.
* Monthly full backups will be retained for a minimum of 2 years.
1. Security-related events will be reported to InfoSec, who will review logs and report incidents to IT management. Corrective measures will be prescribed as needed. Security-related events include, but are not limited to:
* Port-scan attacks
* Evidence of unauthorised access to privileged accounts
* Anomalous occurrences that are not related to specific applications on the host.
# Policy Compliance
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.
1. Exceptions
Any exception to the policy must be approved by the Infosec team in advance.
1. Non-Compliance
An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.
# Revision History
Please check the commit history for this file.
# Purpose
The purpose of this policy is to provide guidelines for Remote Access IPSec or L2TP Virtual Private Network (VPN) connections to the OlinData BV corporate network.
# Scope
This policy applies to all OlinData BV employees, contractors, consultants, temporaries, and other workers including all personnel affiliated with third parties utilising VPNs to access the OlinData BV network. This policy applies to implementations of VPN that are directed through an IPSec Concentrator.
# Policy
Approved OlinData BV employees and authorised third parties (customers, vendors, etc.) may utilise the benefits of VPNs, which are a "user managed" service. This means that the user is responsible for selecting an Internet Service Provider (ISP), coordinating installation, installing any required software, and paying associated fees
1. It is the responsibility of employees with VPN privileges to ensure that unauthorised users are not allowed access to OlinData BV internal networks.
1. VPN use is to be controlled using either a one-time password authentication such as a token device or a public/private key system with a strong passphrase.
1. When actively connected to the corporate network, VPNs will force all traffic to and from the PC over the VPN tunnel: all other traffic will be dropped.
1. Dual (split) tunnelling is NOT permitted; only one network connection is allowed.
1. VPN gateways will be set up and managed by OlinData BV network operational groups.
1. All computers connected to OlinData BV internal networks via VPN or any other technology must use the most up-to-date anti-virus software that is the corporate standard (provide URL to this software); this includes personal computers.
1. VPN users will be automatically disconnected from OlinData BV's network after thirty minutes of inactivity. The user must then logon again to reconnect to the network. Pings or other artificial network processes are not to be used to keep the connection open.
1. The VPN concentrator is limited to an absolute connection time of 24 hours.
1. Users of computers that are not OlinData BV-owned equipment must configure the equipment to comply with OlinData BV's VPN and Network policies.
1. Only Infosec-approved VPN clients may be used. Check with the Infosec Team for a list regarding the approved clients.
1. By using VPN technology with personal equipment, users must understand that their machines are a de facto extension of OlinData BV's network, and as such are subject to the same rules and regulations that apply to OlinData BV-owned equipment, i.e., their machines must be configured to comply with Infosec's Security Policies.
# Policy Compliance
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.