In order to build a business and create quality products, we need to grow all the time. Professional developers and architects that use the best practices can achieve the goal much faster with lower risks for business.

The IT world community knows a lot of practices, but today we are talking about the most important that can save the business and will adjust internal and external processes.

SECURITY PRINCIPLES

Security principles of the company and development team should be well documented and reviewed. The purpose of that kind of documentation is to consolidate the best practices we are using to keep our operations secure. An initial version of this document was created by relying on the experience of maintaining YMCA of the North and OpenY-related sites with the addition of Drupal community best practices in areas where it is applicable. Then these methods were applied in partnership with the QS Corporation.

 This part describes initial security rules already settled in the IT Care team and provides best practices to secure the development environments and accounts.

General Security Practices

 For websites that are leveraged with large, well-maintained open-source libraries (packages) with a critical mass of users and developers, it’s necessary for backup procedures to be regularly performed to ensure that the website can be restored.

 Only the necessary software and modules are installed and maintained. Reducing the amount of code installed (Code refactoring, Legacy and deprecated functionality clean up, Code review). Code should correspond to security standards, known security vulnerabilities should be considered.

 

Accounts Security

 The following principles should be applied to all accounts created for the management and development of the website and related services:

• Avoid using shared accounts, each person should have his/her own access to all systems (code repository, CI infrastructure, SSH, CMS, CRM, DAM, etc.)
• Implement two-factor authentication on each system where it is possible
• Access policies are “denied” by default, only providing access in the scope of responsibility
• FOR QA: remove test accounts created during testing after the test is completed
• Account passwords should be changed every 3 months. 
• Highly recommended to fill in all information in all accounts profiles (photo, phones, emails, positions, and other information) to build trust and transparency for social engineering attack prevention.

Password Security

 The following password security principles should be applied and followed in order to ensure account access security:

• Password requirements:
  • Minimum 8 characters long
  • At least 1 uppercase letter
  • At least 1 lowercase letter
  • At least 1 digit
  • At least 1 special character
• Password-sharing tools should be used for transferring passwords in Slack or Email  (example: https://privnote.com/)
• Password management tools should be used in order to avoid storing passwords openly (example: Google Passwords Manager, KeePass, etc.)
• Passwords received by email or any other message tool should be changed immediately
• Change password period - 3 months. Should be set as a default setting in all systems that have this option of automatic password requirements

Inventory Security Management

 The development team should ensure and maintain the security of all environments and endpoints used for the websites. Server and application software should be updated in time, security updates should be applied as soon as possible.

Technology Stack

 The team is maintaining the latest versions of the software (PHP, Drupal, JavaScript, Jenkins, Git, and others).

Environment security

 The following rules and measures should be applied by the DevOps team for the security of local, dev, stage, and production environments. 

• The Local development environment and LAN security 
  • Wired network security recommendations
  • Wi-Fi network security recommendations
  • Antivirus and Firewall software for local machines
• Digital Assets security
  • Access security and Password policy
  • Data sanitization
  • GitHub security 
• Hosting provider environments security: Stage/Production
• Integration of external services:
  • External service vendor should provide Production and Test environment access to the API and administration tools.
  • Developers should have access to test (sandbox) environment.
• Drupal security
• SSL certificates 
• Continuous Integration system access and security (Managing security in Jenkins)
• Software versions should be up to date and supported
• Security of communication channels (Security risks in Slack, Email security practices, Social engineering security)

 

Development procedures

 In teamwork, it is very important to follow a development procedure that includes best practices about coding standards, сode review, code freeze, and others. 

 Code review is a knowledge exchange process aimed at improving processes and the product. It should be remembered that the code is reviewed by another team member.

 Coding standards

 Agencies and developers that are involved in website development and maintenance should follow the existing coding standards and procedures:

Drupal standards:

• Drupal Code of Conduct
• Coding Standards

Javascript Code Standards (+ React JS):

• Master reference for reviewing javascript ES5/ES6
• Vue.js code style guide

Best practices library (created by the ITCare team)

https://www.drupal.org/list-changes/qs_distro

Very often code review saves our time in the future.

 Look at the examples:

https://www.drupal.org/node/3281070

https://www.drupal.org/node/3282417

 

When is a code review needed?

• the delivery process isn’t perfect
• tests aren’t perfect
• long development loop cycle
• low code quality 
• knowledge transfer needed

What does code review provide?

• a chance to change code quality
• a way to share knowledge
• helps to check the code (by more/less experienced team-member)

 The code can be reviewed by both more experienced specialists and less experienced ones. In any case, code review is a way to teach yourself or others.

 The best practice is also the way a developer not only writes code but also how tests that code. This not only forces the developer to follow a set of rules but also reduces the time the QA team spends on testing.

Deployment window (non-business hours)

 Deployment of the code to the Production server should happen during the maintenance window: the best time for it is during non-business hours local time.

Also, it’s good to have a few standard deployment weekdays (Monday-Thursday).

 If it’s an emergency release during business hours it’s the team should:

• Communicate the need to make deployment during business hours to organize teams as soon as you recognize it 
• Receive approval to deploy from stakeholders
• Once the code is ready for deployment inform the other teams in Slack or by another way about readiness for deployment, tagging the responsible and concerned people.
• Verify deployed code and functionality after the deployment is complete and write a release note.

Code freeze it’s a period when the website should be stable to stay online and handle incoming traffic to keep sales during the marketing campaigns.

Code freeze:

• If there is an urgent need to deploy the bug fix or security update to the website communicate your need to other teams and stakeholders
• Receive approval to deploy
• Verify deployed code and functionality after the deployment is complete and send a release note

Security checklists should be created for different roles in the organization to ensure that company's working environment is secured.

General checklist:

• Make sure Antivirus software is installed and the antivirus database is up to date
• Make sure your passwords to any service are following all requirements
• Setup two-factor authentication (TFA) for access to the admin panel of the website
• Setup TFA for all services
• Install a password management tool to make sure that passwords are stored in encrypted
• Make sure that your development software is updated to the latest versions

 Acting in an emergency situation

 The purpose of that kind of documentation is to provide information about communication channels for technical failures and problems related to website performance.

 We divided emergencies into three levels and assigned responsible persons to each level. This helps to respond quickly in emergency situations. The speed and consistency of actions save time and money, so this is a very important document not only for the internal work of the team but also for the business in general.
 

 Issue reporting and escalation procedure

In order to quickly response in an emergency situation, you should provide several reliable ways to communicate with the responsible persons. It is important that there are 2-3 responsible persons for each level. It is also necessary to offer a list of emergency actions that can be performed by managers' 

 

Emergency actions can include

• Contact support to ensure that they are looking at the problem from their side
• Submit a ticket to support
• Check servers' availability 
• Check server and application logs
• Re-deploy the website
• Reverting files and database backups

 Post Resolution 

 Once the problem has been resolved, the team will follow up to answer the following questions: 

• What went wrong and why?
• How can we prevent it in the future and at what cost?

COMMUNICATION AND ONBOARDING

A communication plan is a process that must be established in each team. Messages, task allocation, daily calls, weekly calls, monthly security calls, and monthly reports – are only part of what we implement. Each team, of course, builds its own plan and adjusts processes. But we want to share our experience.

There should be communication channels for direct communication with stakeholders and responsible people.

 А healthy environment is important, but we must also remember the responsibility that the team bears to the customer. That’s why it is very important to have clear rules and structure within the team.

Working hours and vacation leave

 The team should set their working hours to cover company business hours to be in touch for working questions and emergency situations.

 The team should be informed about plans to take days off at least 2 weeks before the desired dates, so the team can plan its capacity for the vacation period. A day before the vacation leave, an email notification should be sent (optional) to assign an acting person in case of emergency or urgent issues.

 Basic communication rules:

• everyone knows their area of ​​responsibility;
• the employee notifies the team 2 weeks in advance about the vacation leave;
• each team member chooses convenient hours for active work if possible;
• if the employee feels burnt out, he informs the team about it;
• daily meetings have to break down the blocks that slow the employee down;
• there are no “Bosses” in the team, there are Leaders;
• knowledge transfer within a team is a way of growth.

 Guided by the principles of democratic relations, we managed to build excellent partnerships with many teams in different parts of the world.