Skip to content

Commit

Permalink
Added security policy.
Browse files Browse the repository at this point in the history
  • Loading branch information
evilon committed Jul 1, 2024
1 parent 54c5d5f commit 2459fff
Showing 1 changed file with 80 additions and 0 deletions.
80 changes: 80 additions & 0 deletions docs/securitypolicy.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,80 @@
# Security Policy

Badrap Oy

## Purpose and motivation

Purpose of this security policy is to help Badrap’s team and contractors to protect Badrap’s customers, partners, team members, operations, know-how and other secrets. Furthermore, Badrap wants to be a significant net contributor to online security with a major positive impact.

Privacy, confidentiality and business continuity are top priorities to us as we are the care keepers and trusted service providers of the online security of our customers and personal end-users.

## Upkeep

This policy is annually reviewed and approved by the Company’s CEO. Practice meets the policy and vice versa, in case of conflict they will be brought in sync.

Any deviations from this Security Policy are documented as Security Exceptions.

Present and future Badrap’s team and contractors will study this policy and be notified by the Security Officer when it changes.

## Access rights and control

All services and devices require user authentication, no open access or community passwords are in use, except when documented and handled as a Security Exception.

All passwords are personal and unique between different services. Passwords are stored only in a safe and encrypted fashion.

Multi factor authentication is enabled for all services with confidential information.

Access rights to third party and online services, including social media accounts, used in connection with the company’s operations are separately tracked and documented in an Access Matrix. When the team or contractors take a new service in use, it is added to the tracking.

Devices are configured to automatically lock and require login if left idle, if this is not feasible then such equipment is documented as a Security Exception and operated only in an access controlled space.

Physical spaces with unprotected equipment or information are physically access controlled and record of the current keys or access codes is kept in a Key Register. Keys are given to the personnel only when there is an actual need.

If a team member leaves the team or contractor stops working for the team then access rights and keys are immediately revoked or returned accordingly.

Adding and removing access rights is the responsibility of our owner or administrator of the system or third party service in question. Supervisor of an employee or a subcontractor should contact and coordinate access rights with respective owners and administrators as part of the onboarding and exit processes. Access Matrix is updated when access rights are modified, and reviewed as whole at least once per year in the periodic Security Reviews. Access rights are granted and revoked based on business needs only.

## Data storage, retention and backups

All devices, mobiles, computers and removable media storing confidential information are configured to encrypt information at rest with disk or storage encryption. If not feasible for special purpose instruments then such equipment is documented as a Security Exception and operated only in an access controlled space.

Personally identifiable information has a defined data retention in the corresponding Privacy Policy and it is not stored indefinitely unless explicitly so documented.

Online services we provide and sell have a Backup Policy. Distributed repositories, synchronised cloud storage and native backups of online services we depend on are used to safeguard our information and data. Ad hoc backups of devices or data that is not centrally stored are only taken to encrypted media and the media is kept either directly in the team's possession or in access controlled space.

When removable media or devices are no longer needed to store the data, they are wiped clean of the data before recycling.

## Zero-trust, remote work and device security
No matter where we work from, we should always assume that the environment itself can not be trusted. Don’t let others access the devices you use for work. If you have data to protect on any device or media it should be encrypted in case someone else gets physical access. If you have data to be protected on paper in plain text, always keep it in your hands or behind locks and shred it when done with it. Also keep in mind that it would be best not to have it on paper at all. Lets not keep extra sensitive data with us, only keep the bare minimum that you really need. When you have something sensitive on your screen, keep in mind that there might be prying eyes close by. When you talk aloud, remember that your voice might be heard around you, and snooped on the wire if the service is not end-to-end encrypted. Devices you use for work should automatically lock and require authentication if left idle. There are no trusted networks, all sensitive network usage should be end-to-end encrypted. Finally, in remote access and communications certificates or other mutual authentication should be used and required to make sure that both parties to communication are who or what they should be.

## Own infrastructure and personal devices

Any own infrastructure (for example web servers, gitlab servers, VPN endpoints, IoT devices) and personal devices should be minimized, and they should have clear ownership. Initial installations should be minimal and when new services are added they should be firewalled and authenticated to limit access to authorized use. Personal devices should be auto-updated. Infrastructure systems and devices should be auto-updated when deemed safe or otherwise patched monthly. The person who installed the system is responsible for patching until responsibility is transferred explicitly to another person. If patches include critical security patches, those will be installed as soon as possible.

## Own products

Periodic product Security Reviews are kept and documented. Our Product Security Officer has been named and authorized to make decisions required to keep our products and services safe and secure.

## Incident reporting and management

Suspected security incidents and major service interruptions are reported to the other team members or to the supervisor. Suspected incidents are documented and an Incident Log is kept. Owner or administrator of the affected data or service should be notified, and that person will lead the incident response process.

## Onboarding and training

When you as a team member or contractor introduce new people or companies to work for or with us, it is your responsibility to make them aware of this security policy. When we make security training or instructions available, you should promptly familiarize yourself with the guidance. Each of our team members have to participate at least in one periodic Security Review per year in order to train and refresh the security mindset.

## Privacy and data protection

Databases, services or registries that contain personally identifiable information have up to date Privacy Policies. Applicable data protection legislation and regulation is followed. Personal data should never be collected without a reason and data retention should be planned and minimized both in volume and time.

## Supply chain

Security of the supply chain, both subcontractors and technical dependencies, are considered regularly as part of the periodic Security Reviews.

## Security roles and Questions

* Our security officer is: Jani Kenttälä / +358401485100
* Our product security officer is: Joachim Viide
* Staff & Suppliers: please follow, please note exceptions and notify of incidents

Security, threats and risks are about the unexpected, and they constantly evolve. If ever in doubt, consult your team members, Security Officer or supervisor. There are no stupid questions.

0 comments on commit 2459fff

Please sign in to comment.