Security Policy

Axelerant has established the following policy to safeguard the security, confidentiality, availability, and integrity of our personnel, partners, and end-clients. All team members and contractors are expected to accept and abide by this policy, which will be reviewed and updated from time to time. If you have questions or comments about this policy, please contact your supervisor. We invite your feedback.

What are the primary goals of our Security Policy?

• Protect: clients' confidential and personal information

• Reduce: potential liability of Axelerant

• Maintain: a consistent policy that is easy to understand, implement and follow

• Educate: our best practices for security throughout the Axelerant community

• Demonstrate: to clients that we are trustworthy and satisfy contractual requirements for security

How is the Security Policy understood?

We can group information into two classes: confidential and nonconfidential. 

Confidential Information:

• Personal information, such as name, e-mail address, mailing address, telephone, passwords, and all records and files directly relating to a person that is not publicly available.

• Proprietary client information, for example, intranet/extranet content, files or data, unpublished/staged content, project planning/design documents, or source code produced by the client or 3rd party vendors; this may include information covered by a non-disclosure agreement (NDA), but even in the absence of such an agreement we should treat information provided by clients as confidential unless instructed otherwise.

• Confidential business information of Axelerant or a client, including engagement terms

• Communications involving legal advice or discussions that are intended to be protected by attorney-client privilege or the work product doctrine

• Internal Axelerant information, for example, information regarding our IT security, accounting, finance, or human resources, unless by prior agreement by a member of the management team.

Nonconfidential Information:

• Free and open-source ("FOSS") licensed source code (e.g., GPL/AGPL), such as projects downloaded from drupal.org. This also includes all FOSS source code written by Axelerant, except files containing credentials.

• Free and open-source licensed creative assets (e.g., Creative Commons); this also includes project planning/design documents authored by Axelerant, as well as training materials and other incidentals that have been designated Open Source

• Publicly available information, including client information on public-facing web site pages

Key Points:

• The content management system, customer relationship management, and e-commerce databases and database exports should always be treated as confidential since these contain personal information.

• The uploaded files directory may need to be treated as confidential if the client site has any access-controlled content.

• The site source code can normally be treated as non-confidential unless this includes proprietary code from the client or 3rd parties.

• The contents of the project management site (e.g., JIRA, Github, etc.), e-mail lists, and related communication tools will normally contain a mixture of confidential and non-confidential information:

  • Information authored by Axelerant for clients will generally be non-confidential unless an NDA binds us. However, Axelerant may from time to time produce content for a client-owned by the client and/or includes proprietary IP (such as trademarks or copyrighted text), which should not be disseminated to third parties used by Axelerant except by express permission of the client.

  • Information authored by clients or 3rd parties should generally be treated as confidential unless it is clearly public-facing. Then its use other than as outlined in the engagement agreement may still require client permission. If in doubt, ask your supervisor or the General Counsel

  • Non-confidential materials can be sourced for distribution or repurposing but should be reviewed and redacted, if needed, to ensure no confidential information remains.

If you are unsure about the confidentiality of a piece of information, you should ask someone who can give a qualified answer (if in doubt who this is, consult with the legal department), in the meantime, work from the assumption that it is confidential.

Acceptable Use Policy

It is each person's responsibility to ensure they understand and follow the data security policy. This is true for Axelerant employees and contractors in both non-technical and technical roles. However, some additional steps need to be taken for those involved in technical work.

Broadly, dealing with confidential information involves the maximum extent feasible - limiting the number of places (physical and logical) where it is stored. Secondly, ensuring that each of those places is as secure as reasonably possible to prevent unauthorized access.

Users are responsible for carefully tracking any confidential information stored on personal devices (including backup/offline storage). Periodically during and after each project, confidential information stored on personal devices should be reviewed. Any longer needed should be deleted (after being archived to an Axelerant service, if needed). Users should ensure files are actually deleted (and not stored in a recycle/trash area), ideally running a secure delete on the files, which is available out of the box on OS X and GNU/Linux-based systems.

Axelerant IT services provide several general user accounts. This includes:

• Axelerant Google Apps (Gmail, Docs, Drive, etc.)

• Web-based collaboration accounts such as

  • Our home site

  • Intranet (internal team collaboration)

  • Project management site (Jira, Github, ...)

  • 3rd party collaboration tools (such as Slack, Zoom, ...)

  • IP telecommunications/conferencing accounts

Usage of Axelerant user accounts should be as follows:

• Usage must be directly related to your work with Axelerant; personal use (including personal projects) must be approved in advance by the CIO.

• Usage that in any way would be harmful to Axelerant, our partners, or their end-clients is forbidden.

• Storing confidential personal information from client website users (for example, CSV exports from CMS) on internal collaboration systems should be avoided wherever possible, especially on 3rd party services such as Google Docs.

• Confidential information (other than personal information) should only be stored in areas restricted by access control, such as the project management area.

• Binary software executable files should not be distributed via internal collaboration systems, as we do not have anti-virus scanning in place. Uploading human-readable source code and scripts (PHP, Bash, Perl, etc.) is acceptable (but should be considered a risk).

In addition to user accounts, we provide developer and system administrator access to system and service accounts, such as administrator web-access and SSH access to client sites, version control systems such as SVN/Git and MySQL database access. Usage for these accounts is covered in our server security policy below.

Access Policy

The security of our systems is as strong as the weakest link. All devices that connect and are authenticating must be as secure as possible. Specifically:

• This includes access to web-based accounts, such as our intranet—as well as developer accounts.

• This covers both desktop and laptop machines and devices such as mobile phones and network routers (including home/office Internet gateways). This also includes 3rd party sourced servers/services that employees and contractors may employ as part of their workflow.

• Axelerant is responsible for maintaining the security of our own systems and supporting computers or other devices that may be provided to staff as a part of their employment.

• Employees and contractors are responsible for maintaining their own systems to the highest standards of security. This includes (but is not limited to) the standards described in this document.

• The axelerant.com Google docs and domain must be accessed via your axelerant.com email address; in particular, it is not permitted to add a personal email address to the shared axelerant.com domain Google Docs.

Before connecting and authenticating to any Axelerant IT system or storing confidential information on your systems, all users must ensure that:

• Operating systems and all software that makes network connections (such as web browsers) or opens files that have been downloaded from the Internet (such as PDF readers) is patched or updated to resolve critical publicly known vulnerabilities, or, when an older version of a program is used on purpose (such as for interoperability testing), it is run in a sandbox (typically a virtual machine)

• Systems vulnerable to malware infections (primarily Windows, but may include other systems and mobile devices) are running a high-quality virus scanner (such as Kaspersky, Avast, or ClamAV) that automatically updates its virus definitions at least every 24 hours, detects malware in a real-time fashion, and completes a full system scan at least every week. Also, Windows users are expected to run a general malware scanner (which may be integrated into the virus scanner, or maybe separate, such as Ad-aware or Spybot - Search & Destroy) that detects accidentally installed malware that does not qualify as a virus.

• A firewall is configured to block all unsolicited incoming connections to systems that store confidential information (or contain saved passwords that provide access to confidential information, although we discourage saving passwords); This can be a network router NAT-based firewall or a software-based firewall running on your local machine. This applies to all operating systems.

  • For laptops used in hostile network environments (including public places such as cafes or airports), a software-based firewall is mandatory.

  • For users of Unix-based systems, such as GNU/Linux and OS X, it is acceptable to open port 22 to allow external SSH access to home/office computers, as long as these systems are up-to-date with security patches and they use strong account passwords or SSH keys.

  • It is crucial to ensure that network shares, databases, and local development sandbox versions of websites are not publicly visible when working from home/office and public places.

• User accounts on all systems must be password protected (using passwords that adhere to our password policy) and require entering the password on initial startup and resume from "sleep" mode.

• Whenever practical, work should be done from under a relatively non-privileged (user) account, not from an account with administrative privileges on the computer; working under the latter is more likely to result in the unintended installation of malicious software that would be harder for an anti-virus program to detect and cure; even if you're the only person using a computer (such as a laptop), it is a good practice to create two accounts on the computer: a "user" and an "administrator" and use the "user" account for most activities.

• Untrusted software should not be installed—this includes software you have never heard of, as well as known software that was downloaded from sources other than the author's site or a trusted, established repository.

• Be cautious opening e-mail attachments or files sent over instant messengers or similar systems; even if the attachment is from a contact you recognize, if it is unexpected and does not indicate a project or discussion you recognize, it is wise to e-mail the person separately to confirm that they sent the message; the reason for this is that it is common for malware to use e-mail software contact lists to send e-mails masquerading as a known contact with the malware attached.

• Do not access Axelerant IT systems using an untrusted computer (for example, an Internet cafe or library system) because these systems can easily be infected with malware that transmits user activity to a 3rd party.

• If technically possible, additional protections such as encryption of your home directory (with a strong passphrase not reused for another purpose) and "remote wipe" of lost mobile devices are encouraged.

• When connected to wired or wireless Internet connections associated with Axelerant (for example, while at company sprints/retreats or when visiting client site offices), users are expected to follow the appropriate terms and conditions of that provider and to avoid initiating network traffic (e.g., by visiting specific websites or running file-sharing software) that may bring our reputation into question.

If a system is believed to be compromised, either through theft, loss, remote access, virus/malware infection, Axelerant people operations team should be informed immediately.

Password Policy

Passwords are used to protect many of our systems and services.

All passwords at Axelerant must follow this policy, including passwords used for:

• Personal computers or devices that access Axelerant services or store confidential information

• Passphrases used for PGP or SSH encryption keys

• Personal accounts on any Axelerant internal or client site or service

• Axelerant accounts on 3rd party vendor sites

The importance of strong passwords:

• Consider using a password manager (see below). If you use a password manager, you can skip the rest of this sub-section

• Consider using a passphrase even where a "password" is requested. These tend to be easier to remember and stronger than passwords; a reasonable passphrase consists of four words or more (three words is the minimum, allowed only if the word combination is extremely uncommon and additional non-letter characters are used along with the words); you may separate the words with arbitrary characters of your choice (digits, symbols, whitespace, even letters), which adds extra security; you may also purposely misspell or mangle the words, but only in a way you can remember.

• If you choose to (or are forced to) use a short "password," include a mix of upper and lowercase letters, numbers, and symbols in it.

• Password Length should be around 10 to 14 characters if permitted and longer still if possible while remaining memorable.

• Avoid any passwords based on usernames, people or pet names, dictionary words in any language (unless meeting requirements for a passphrase, above), dates, ID numbers, repetition (too few different characters), letter or number sequences, keyboard patterns, etc.

• Password should be easy to remember—you can use mnemonics (the first letters of a line from a poem or song, for example), but you also need to add multiple non-letter characters—or better yet, use a passphrase as suggested above.

• Avoid using the same password for multiple sites or purposes – passwords for client sites should substantially differ from passwords for internal accounts. Neither should ever be used for third-party or non-Axelerant accounts.

• A passphrase that you use for encryption (such as on a GnuPG/PGP or SSH private key, or with an encrypted file system) must not be reused for authentication to a system; in general, an encryption passphrase should typically be stronger than those used for authentication.

Password Managers & Two Factor Authentication

A password manager (such as 1Password) can easily create and maintain hundreds of different 16 character (or more!) passwords. It is a must for all employees to use 1Password as a password manager at Axelerant. Be sure to choose a strong password for your password manager.

Modern password managers - and many other services such as Google Apps, GitHub, Slack, and more) now accept Two Factor Authentication that can greatly increase the security of the protected assets. Axelerant requires TFA for access to the Axelerant Google Apps such as Gmail and Docs and OATH-authenticated apps such as GitLab.

Please see the Security Awareness and Tools document for details on these subjects and more.

Handling Passwords

• Passwords to personal system accounts must never be given to anyone, including IT team personnel and management; IT staff will never ask for your password. Please use 1password password manager when sharing confidential information among the team.

• Passwords should not be "written down" in a non-encrypted file (if you feel you have to start writing down some "low-value" passwords to maintain a large number of different ones, which is a reasonable tradeoff, use an encrypted file protected with a strong passphrase, or only write down password hints rather than the actual passwords); or use a password manager.

• Passwords must never be transmitted or stored in a clear text (i.e., readable) format.

• Passwords can be stored and transmitted by the computer when encrypted with GnuPG public-key encryption; IT services can support getting this set up if needed.

  • The unencrypted clear text contents of a GnuPG encrypted file/message should only ever be viewed then discarded but not saved in decrypted form.

Some Exceptions

• On occasion, "starter" passwords for new accounts on websites may be transmitted/stored in clear text, on condition that the recipient immediately logs in and sets a new strong password Both the starter and new passwords must adhere to the strong password policy. If possible, it is preferable to use a "one-time" login link or transmit "starter" passwords with GnuPG or via phone, email, SMS, Slack, etc.

  • When transmitting a password electronically in clear text, do not include the username or website URL in the same message

• .The MySQL vhost password is stored in clear text form on the vhost for usage by Drupal and deployment/testing scripts (e.g., drush)

• The "basic auth" pop-up credentials used on dev/QA and pre-launch instances of client sites can be stored in plain text on the project management system for easy client reference.

• There are a few 3rd party services that we have shared accounts for and which store no confidential information, for example, CrossBrowserTesting.com; these passwords can be stored/transmitted in clear text within the team

• .If you suspect a password has been compromised (for example, it was accidentally typed into an unencrypted chat session), change the password immediately yourself if possible, or inform IT right away so that a sysadmin can change the password

  • .This includes the case when a client sends a name/password pair in the clear in an email

.Private Keys

• SSH public/private key pairs are used to access Axelerant servers

• GnuPG (PGP compatible) public/private key pairs are used to transmit and store credentials to Axelerant client sites and internal services

• .It is absolutely critical that a very strong passphrase protects all SSH and GnuPG/PGP private keys; having such keys with no passphrase is forbidden.

  • As an exception to this, additional public/private key pairs may be generated for specific tasks that require full automation, subject to approval by IT

• .SSH and GnuPG/PGP private key passphrases must not be reused for any other purpose or site

• The private key files themselves should be kept in as few places as possible (ideally just your primary computer; a home server is also acceptable for storage of a backup copy of the encrypted key, but not for the use of the key)

• Private keys should never be placed on external servers—if you need SSH access to one server from another server (typically for a large data transfer), generate a dedicated key pair for that purpose or tunnel SSH over SSH port forwarding (ask IT for instructions)

• If you suspect a private key file (or its passphrase) has been compromised, inform IT immediately so that we can revoke the corresponding public key on our servers

• .Keys must be 2048 bits as a minimum (keys using lower strengths must be replaced). 4096 bits or higher is recommended for new keys

• Passphrases may be cached but should expire after 1-2 hours or at the end of each login session for desktops and laptops and after 5-15 minutes for mobile devices.

Server & Site Security

Web administrator access to websites, working on source code, and access to servers (SSH/shell, file system, database), carries a high level of responsibility and trust. You are expected to be familiar with and follow our best practices and processes, maintain your skills, and know your own limits.

Usage of Axelerant developer accounts should be as follows:

• Usage must be directly related to your work with Axelerant; personal use (including personal projects) must be approved in advance by the CIO.

• Use in any way harmful to Axelerant or our clients is forbidden.

Web administrator account holders (Drupal, CiviCRM, etc.) must also:

• Be familiar with how to maintain configuration security (drupal.org/security/secure-configuration)

• After changing site permissions, the site must be tested by logging in as a user with each affected role and ensuring that access is limited correctly.

• After changing settings affecting content/data access control, the site must be tested to ensure the correct settings.

• The use of PHP in the web administration interface is strongly discouraged (as this code is harder to find and hence audit)

• Respect the privacy of site users, avoiding accessing personal data such as private messages

Developers and themers working on the site codebase (and committing code to Git) must also:

• Ensure their own code follows Drupal coding standards (drupal.org/coding-standards) and security standards (drupal.org/writing-secure-code), and is well abstracted and commented throughout; the project technical lead (or a designated lead engineer/lead themer or peer-review process) is responsible for reviewing all new/modified code each sprint, and ensuring it meets a high standard of quality.

• Ensure the standard dev-QA-live process is always followed, such that all changes that may affect site security can be thoroughly tested before being made live.

• Ensure that external developers (client or 3rd party) working on the site codebase are either:

  • A full part of our developer team, such that they been assessed/trained to have the appropriate skills and are subject to TL code review

  • OR: The client confirms that we have not assessed their skills or are reviewing their code; this scenario is best avoided but is sometimes necessary if the site is being transitioned to another developer.

• Review all contributed code they have not previously used for basic quality—this is not a formal security audit in most cases, but rather checking the usage stats, issue queue, skimming the module code for readability and adherence to good practices, etc.; code that is actively used and maintained and follows best practices is less likely to have serious security issues.

• Check for security advisories (drupal.org/security) for modules used on each active development site and ensure they are upgraded where necessary before the site is made live.

• Understand common attack vectors and the best practices for preventing them, including:

  • SQL injection, prevented by proper query construction and placeholder usage

  • XSS (cross-site scripting) attacks, prevented by ensuring user data is always sanitized as appropriate on output

  • XSRF (cross-site request forgery), mitigated by ensuring URLs performing actions (including pages that process GET/query strings) carry an unpredictable token on URL generation

  • Session hijacking, prevented by using SSL and correct site/session settings

  • Data disclosure, prevented by carefully setting and testing access control, as well as using SSL as needed

  • Password guessing attacks, mitigated by using strong passwords

• Software that is not licensed under an approved Axelerant open source license may not be used on a project without prior approval from the legal team.

Developers and themers maintaining local sandbox copies of client sites must also:

• Ensure that our standard tools for creating, sanitizing, and transferring database dumps for sandboxes are used

• Ensure that unsanitized MySQL data (created via mysqldump or PHPMyAdmin) to sandboxes are not downloaded from the server to a local sandbox

• Ensure that all confidential data associated with a project (such as databases, database dumps, and other files) are securely deleted from their system(s) when leaving or completing a project

Developers and themers working on the site vhost (SSH/shell, file system, database) must also:

• Ensure they follow best practices concerning SSH keys, passphrases, and passphrase caching (see above)

• SSH, SFTP, and SCP access to vhosts are managed exclusively by designated admin(s); access by password, manually installed SSH keys (other than by admins), web-based "shell" script, port forwarding to 3rd parties, or other methods are forbidden by unless authorized in advance by the CIO

• Temporary SSH port forwarding is permitted to access the server MySQL from your own desktop.

• Accessing Axelerant servers by initiating an SSH connection from external clients or 3rd party servers is strongly discouraged—it is preferable to SSH out from the Axelerant server.

• Running non-standard software on a vhost requires a system ticket and approval from a member of the IT team; this includes:

  • Daemons (persistent, long-running processes)

  • Binary software (compiled on the vhost or elsewhere)

  • Web-accessible scripts/CGIs that do not use an established framework solely

• Please inform the IT team as soon as possible if unusual resource usage is anticipated so that we can monitor resource utilization and ensure backup processes run correctly; this can include high traffic events, large data/media file uploads, or high CPU/RAM usage (e.g., during large imports)

IT team system administrators working on Axelerant servers must also:

• Take the utmost caution when working on server configuration—document and test each change.

• Non-urgent yet risky changes (those with a significant risk of introducing undesired side-effects) should only be made when the person expects to remain online and available after the change.

• Not work on-site/user files as root - but "su" to the account first.

• Respect the privacy of server users, avoiding accessing others' personal data such as e-mails

• Work with the IT team to ensure server and backup health is monitored and alerts are responded to promptly.

• Ensure offsite backups are transferred and stored only in encrypted form

• Ensure the Hurricane Electric and RimuHosting access list (that controls remote hands and physical server access) is maintained

Security Awareness & Tools

We maintain a Security Awareness and Tools document that dives deeper into some additional topics, including:

• Password Management Tools

• Two Factor Authentication

• Phishing and Social Engineering

• Backups

• Secure Delete Files and Wiping Disks

Anti-virus Policy

• All engineering team members are encouraged to use GNU/Linux and OS X based systems that are not so vulnerable to virus attacks.

• All Axelerant employees should have Antivirus installed on their endpoints irrespective of the project/engagement.

Got Questions?

Contact your manager or Axelerant people operations team immediately.