Commit 67bc55da authored by Marcello Evangelista's avatar Marcello Evangelista

Merge branch 'm-considerations' into 'master'

Security Policy, 20% Project and minor remarks around the playbook.

See merge request !22
parents d872e9c0 2ac9f8e3
File added
# 20% project
Related to the previous item, we have a 20% rule that was copied from Google's engineering team: you are allowed to spend 20% of your time (effectively one day a week) on some project that is not highest priority, and it can be anything you come up with, as long as there is some perspective of usefulness for OlinData (in the widest sense of the word). For instance (and this is just an example), Walter happened to have registered a domain called <http://divesitebuddy.com> years ago, which in his mind was going to be a tripadvisor for divesites worldwide. If you think that that is what you would love to spend some time on, you could do that for your 20% work. Also, the 20% project is optional. If you feel like you want to not make use of the opportunity, that's cool too.
We have a 20% rule that was copied from Google's engineering team: you are allowed to spend 20% of your time (effectively one day a week) on some project that is not highest priority, and it can be anything you come up with, as long as there is some perspective of usefulness for OlinData (in the widest sense of the word). For instance (and this is just an example), Walter happened to have registered a domain called <http://divesitebuddy.com> years ago, which in his mind was going to be a tripadvisor for divesites worldwide. Richard, our Drupal expert back then took on himself to start designing and building this website and he blogged about his experiences weekly. Go and search back in the blog history if you want to see some of the results. If you think that that is what you would love to spend some time on, you could do that for your 20% work. Also, the 20% project is optional. If you feel like you want to not make use of the opportunity, that's cool too.
You're free to divide the number of hours assigned anyway you want. If you want to work 8 20-hour days per month that is fine with the management (although we don't think it's a great plan productivity wise ;) ) That said, it would be nice if you spread things out a bit so you'd be available at least a few hours during most weekdays. If you work better in evenings, mornings, weekends, etc. That is fine with us. The communication part we listed in one of the items below should make it possible for us to work asynchronously.
You're free to divide the number of hours assigned anyway you want. That said, it would be nice if you spread things out a bit. If you work better in evenings, mornings, weekends, etc. That is fine with us. The communication part we listed in [culture] should make it possible for us to work asynchronously.
# How do we organise this?
It is important to us that you take the maximum advantage of the 20% rule and we are very interested in helping you to achieve this. Before you can get started with your project, we ask that you write up a small proposal on what you aim to work on. Discuss that with your direct lead for approval so we can determine together if and how this would work. We do this using periodic meetings where we discuss your next 20% project or follow up on your current progress. These meetings are used to set short-term goals regarding the 20% project. The meeting frequency is open to personal preference but we advise to have, at least, one each trimester.
# Goal Setting
We use Bamboo's functionality to keep track of the current progress, it is very important that you take your time to update your progress frequently. In Bamboo it is also possible to write comments about your goal.
# Content production
One of the greatest overall perks of the 20% project is to have a shareable outcome, perhaps in the form of blog content. This content can also be a knowledge sharing session, a mini-project or even internal wiki track about the topic.
......@@ -6,7 +6,7 @@ SRCS= 20percent.md LICENSE README.md \
onboarding/* recruitment.md \
security-policy.md software-and-saas.md \
time-off.md travel.md \
whoswho.md
whoswho.md security-policy/*
all: handbook.md handbook.html
......
......@@ -13,12 +13,11 @@ next story:
* Making a particular script/playbook/class truly idempotent
* Experiences containerising large software
* How gathering and visualing data finally led to fixing that one
* How gathering and visualising data finally led to fixing that one
thing that was being ignored
* Why changing from tool X to tool Y led to significant decrease in build
times
[odblog]: https://olindata.com/blog
* Why changing from tool X to tool Y led to significant decrease in build times
* Experiences in conferences and relevant events
* Reviews on books, certifications and training material
As a company dedicated to open source software we recognise the
importance of contributing to projects' documentation. We don't want
......@@ -39,4 +38,4 @@ https://calendar.google.com/calendar/embed?src=olindata.com_al1t8ln0iqmolkkd9diq
The current maintainer of olindata.com/blog is oliver at olindata.com.
See [internal/www](https://gitlab.olindata.com/internal/www) for more
tech detail on how articles are posted, formatted etc.
tech detail on how articles are posted, formatted etc.
\ No newline at end of file
......@@ -9,7 +9,7 @@ Most importantly, check that you can log in to these using your
- [Slack][slack]
- [BambooHR][bamboo]
- [OD Gitlab](https://gitlab.olindata.com)
- [OD Gitlab][gitlab]
If you encounter issues with any of the above please feel free to contact Walter or Mine.
......@@ -27,6 +27,9 @@ you.
1. Click "Edit". You will be directed to a page to fill in your basic information in each column accordingly, upload your photo and write a short biography about yourself.
1. Click “Save” at the bottom left
### Professional Profile
In order to offer your skills to our customers, we need you to create your professional profile. The profile is composed by a model CV we use and a small slides presentation. You can find the templates at OD Google Drive. For more information ask Jonah or Mine
### Contact directory
Update your contact information in our
[Google address book](https://mail.google.com/mail/u/0/#contacts).
......@@ -38,3 +41,4 @@ in touch with Walter or Mine.
[slack]: https://olindata.slack.com
[bamboo]: https://olindata.bamboohr.co.uk
[gitlab]: https://gitlab.olindata.com
\ No newline at end of file
......@@ -18,6 +18,8 @@ The office is a space we will have to share so it is important to be mindful of
- No smoking inside the office
- Make sure you don´t have an overpowering odor (good or bad)
- Be weary with loud or smelly food
- Be careful with playing music loudly. If you want to listen to loud music please use headphones.
- Be careful with the oven. Seriously.
### Etiquette
- Respect co-worker´s and company´s property
......@@ -27,11 +29,9 @@ The office is a space we will have to share so it is important to be mindful of
### Handeling Conflicts
As said before the office is a shared space. We hope no conflicts will arise. If there are any issues that could cause conflicts to arise, please try to resolve the issue in a mindful manner. If this does not work talk to Walter, Jonah or Mine.
## Suggesting changes or improvements
The office is a new environment for all of us. If you have any idea´s to improve the workspace or want to see change in something go and talk to Walter, Mine or Noor.
## Requesting Equipment
We are arranging an IT asset management program in which we can see what assets we have and where you can request or maybe already find the items you need. Until that is arranged go to Walter, Mine or Noor to request equipment.
......
# 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 Marcello, our Internal Security 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](https://csrc.nist.gov/publications/detail/fips/140/2/final), 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](https://csrc.nist.gov/Projects/Hash-Functions/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. For more information see [cipherli.st][cipherlist]
# 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.
[cipherlist]: https://cipherli.st
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 sight. 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 restarted 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 portable media 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.
# 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.
1. Information Transfer
The SRP communication must outline applied services (Manual or Automatic scanning) but will not prize information. Confidential information regarding systems and impacted services or applications will only be distributed through secure channels and only after verification of the contact.
# 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
Other than the providers mentioned above, OlinData BV also has part of its internal infrastructure deployed at the following providers:
* DigitalOcean
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 Database 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][passwordpolicy].
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][passwordpolicy].
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.
[passwordpolicy]: security-policy/general-guidelines/password-construction.md
\ No newline at end of file
# Purpose
The purpose of this policy is to establish a solid and consistent patching routine to be used across the whole company including, and not limited to, vendor solutions such as hardware, XaaS and/or any external extensions of OlinData's infrastructure.
# 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 and/or used to deliver work on behalf of the company.
# Policy
1. Personal Hardware
1. Personal-level hardware should be patched accordingly to the definitions from the Infosec Team. Bulletins will be made available on Slack and Email regarding critical threats or news regarding the schedule.
1. The preferred patching day for Personal-level hardware is Friday, during the OlinData Day. This can be temporarily changed if a critical CVE is published or any internal breach happens.
1. The patching will be inspected by Stethoscope and the non-compliance with the patching schedule will represent a break of policy and may result in subsequent warnings.
1. All patching related to personal hardware should be carried by the owner with prior instruction from the Infosec Team Bulletins.
1. Cloud Infrastructure
1. All assets from the infrastructure should be deployed as code and follow the paradigm of immutable infrastructure.
1. The patching routine for infrastructure deployed over the cloud is to have the complete resource re-deployed. This should be the default behaviour for any resource deployed on thirdy-party platform providers.
1. The patching will be inspected by [Stethoscope](https://github.com/Netflix/stethoscope) and the non-compliance with the patching schedule will represent a break of policy and may result in subsequent warnings.
1. All patching related to infrastructure deployed on thirdy-party platform providers will be done by the Infosec Team.
# 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.
\ No newline at end of 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.