Web applications security #1

Web applications security — our new three-parter

In this blog series we’ll look at the security of web applications, namely LAMP (Linux Apache MySQL PHP). The first blog will focus on a secure process, with forthcoming blogs on building passive security for web applications and building active security for web applications.

Problem summary

Over the past 19 years I’ve worked for a wide range of IT companies that deliver internet and cloud services, including website hosting and website development, SaaS and eCommerce systems. During this time I’ve seen how companies struggle to deal with the problem of online security. Even today there’s still a lack of understanding. And the ramifications of a security incident are far-reaching, impacting the brand name, share price, business operations and customer relationships.

“The real security is the security at every level.”

This article aims to help you understand what real security is — how to assess it, how to plan it. It’s recommended reading for web agency directors, senior developers and devops teams.

After reading this article you should gain an overview of the problem and understand the process and solutions currently available in the market, so that you can plan a strong online security model.

For a start, I encourage you to ask your IT team this question: “How does our company monitor online intrusion incidents?” Do you get a well-structured and extensive answer, explaining intrusion detection and intrusion prevention systems? Maybe you hear words like web application firewall and multi-factor authentication? Or maybe you rely on an external vendor. If this is the case, ask if your hosting provider offers features like those mentioned above.

The most common answers you may get are:

• Our clients haven’t complained about any security incidents for years/months.

• We haven’t seen any hacked websites yet, so everything should be alright.

• Our developers patch the content management system (CMS) A/B/C and thus we’re covered.

• We moved all our websites to an external service provider, so this is not our headache any more.

In these typical scenarios, the client becomes the intrusion detection system, alerting you about any problems after the fact.

Cloud-based SaaS or PaaS solutions are in high demand now and create other risks around web applications security. They help reduce (or completely avoid) devops and system administration tasks, which makes them very popular. However, these solutions often don’t offer any visibility into the security of your website. In fact, hardly any SaaS or PaaS vendors have an efficient, active security system in place, such as HIDS (Host Intrusion Detection System) and WAF (Web Application Firewall). The typical approach is that website security is the responsibility of the end client (or an agency).

The triangle of false expectations

In the triangle of false expectations (TOFE) the three corners are occupied by:

1. Client

2. Web agency

3. Hosting company (or devops team)

TOFE creates an illusion of security, since none of its participants consider themselves responsible. The outcome: the customer’s website may end up unsecure or having very limited security.

Let’s review the three integral parts of the TOFE.

1. Client

The client expects that their website is secure, well looked after and protected. Without knowing exactly how to deal with the security of their website, clients rely on their agency’s advice.

2. Web agency

The web agency expects that the security of their client’s website is the responsibility of the hosting company, and that it’s well looked after with minimal or no interaction from the agency. When providing security advice to the client, the web agency is often talking about regular application of the security patches for the CMS used and assumes the rest will be covered by the hosting company. The agency is unaware how to manage, or unable to effectively manage, the security of the system as a whole and only works around the security of the web application.

3. Hosting company

The hosting company usually states that the security is included, but often doesn’t actually do much. Rather, they expect the the online security or remediation actions to be handled by the web agency or the client.

Avoid the TOFE at any cost! It’s imperative to identify the responsible parties and define and assign all responsibilities. As you go through the process review, ensure no unassigned responsibilities remain.

Website delivery cycle

The typical model of a modern website delivery process could be separated into these parts:

1. Web agency — a company that builds and maintains websites.

2. Operations — client and their staff that manage daily website updates (or product updates, orders management, etc. if the site’s an online store).

3. Devops — local team or an external vendor, SaaS provider or a data centre that’s looking after the hosting and the security of the client’s website.

In daily operations these three parts of the system need to communicate and share information. Without a strong and efficient process, these parts of the team may expose your system or customer data to security problems. Leaked passwords, weak passwords, intentional password exposure to the public by ex-staff, unattended (forgotten) active accounts or employees that left the organisation are the most common causes behind the biggest data breaches.

“The security of any system is as strong as the weakest part of it.”

Planning a secure process

Every agency needs to define its own, unique secure process. The common parts of the process are:

1. Password complexity policy and restrictions

2. Password expiration policy

3. Password sharing policy

4. Password policy for your customers

5. Password storing policy (for example "no plain text passwords should be stored")

6. Spoofing and phishing email awareness within the team, with periodical training of new and existing staff

7. Encryption and password protection of any backups

8. Backup storage and retention policies

9. Use of multi-factor authentication

The first five points contain the same common word: password. Nothing new here, after around 25+ years of internet existence, passwords still bring the biggest security risks. Using a good password manager will minimise the password-related risks significantly. It's also worth mentioning that team awareness campaigns around password security should be periodical.

The conflict between devops and developers

In my daily professional life many times I’ve worn a developer hat and a devops hat.

As a developer, I want the process and the configuration to be simple so I don’t have to deal with extra steps or extra security required for the production website.

As a devops engineer I want developers to follow the process and security best practices. This avoids decreasing the security through weak file permissions, storing database dumps and website backups everywhere with no control, and so on.

This conflict seems to be one of the biggest struggles of the modern era, creating security incidents over and over again.

As you plan a secure process, ensure there aren’t any possibilities for it to be bypassed.

The process we try to build (or update) comes down to regularly revising company policies and practices, and working with staff to educate and control the way they approach security at every level.

Minimising security risks during deployment

Whenever it comes to deploying a release to a production website, it’s good practice to automate the deployment process so that manual interactions are avoided.

Whenever a website runs on multiple environments for QA and UAT purposes, these websites should be at least password protected from public access. This serves several purposes: firstly, it prevents anyone accessing and seeing the work-in-progress website or project; secondly, it prevents search engines and bots from crawling the website and driving public traffic to it; and lastly, it keeps bad guys away, ensuring that no vulnerability scans would discover possible weaknesses.

Private information sharing and password management

How does your team share private or sensitive information? Do you use online messaging services to uncontrollably share usernames and passwords with the rest of your team? Or do you use password management software to control who, when and how this private information is accessed?

To efficiently store and manage the most valuable asset of any online system — a password — password management software is recommended. Whether this is LastPass, 1Password or another system — you decide what works best for you.

Some other tips:

• Define and enforce password complexity and change frequency policy. Do not overcomplicate it and do not request password changes too often (this will avoid employees taking shortcuts like sticky notes with passwords attached to their monitors).

• If two-factor authentication is not possible, find a way to integrate it at least around your key systems.

• Ensure that employees who leave your organisation cannot access any online or offline systems that belong to you or your customers.

• Ensure a strong employment agreement that covers the handling of private information accordingly, and for a long period of time.

• Ensure your process recommends, and policies control, your staff from sharing passwords and other sensitive information.

• Ensure strong passwords are in use (LastPass or 1Password are very helpful here).

Before starting to strengthen the security of your online systems or patching web applications, work through a simple and reliable process, to ensure your daily work does not create security risks or data breaches.

Part 1: The secure process

I want to outline a few important points about web applications security and meeting customer expectations in relation to it. An effective security system is security at every level. It begins with the secure process, it then relies on passive security measures, an efficient intrusion detection (and prevention) system and an active security system.

Six principles of a secure process

Any online security should begin with a global security audit across your entire organisation. This audit should be repeated periodically, for instance annually. The audit aims to provide information covering the following principles:

1. Establish requirements

1. Identify key stakeholders: The aim is to identify key staff responsible for delivery of the secure process. The responsibilities should cover process planning, implementation and control.

2. Identify key systems: Identify and protect your key systems at any cost. Define the secure policies for every one of them. Ensure your process cannot be circumvented.

3. Identify the key security issues: Identify the key security problems from the past and plan for the future, ensuring the process you build covers these problems. As new security incidents emerge, review and update your process and ensure that all stakeholders are aware of the change.

4. Set measurable goals: Plan where your organisation wants to be in the next one, two and five years. Set quantitative goals that can be easily measured as you reach the set milestones.

2. Review and simplify the process

A big share of all security incidents are the direct outcome of complex processes. As you build (or review) your process, make it simple and easy to follow. Complex processes often make people take shortcuts.

These are the principles of a good process:

• Simple and easy to follow.
• Built into the baseline of your systems and with no reading required.
• Reduce the number of steps or checklist points.
• Automate where possible.
• Avoid creating length process documentation.
• When an issue is identified, try solving it globally, rather than expanding steps or creating extra checklist items.
• Delete unused steps

3. Identify the backdoors

Identify the weaknesses and backdoors in the existing processes and ensure they are eliminated. For example, you designed a great and easy-to-follow process. How do you let your team know about it? Is your process documented? Is it easy to find? Is it easy to follow?

4. Set policies

Policies help your organisation to set boundaries around the process. For example, you may require your development and devops teams to avoid creating backups of online environments and leaving those backups accessible via the internet. (Have you ever seen files like db.sql or public_html.tar.gz sitting in the website docroot folder? One of the features of hackbots is to crawl websites and identify files like that, downloading them.) Another example could be a policy to have any dev/UAT environment password-protected.

5. Select tools

Identify and implement critical tools to allow following the process easy. Decide what tools your process will need. For example, use password managers for all your password storing and sharing needs (such as LastPass). Passwords are not secure, ensure the MFA (multi-factor authentication) is enabled and enforced for all key systems. No password sharing online or offline, except if using the password manager of your choice. Make these the approved tools and demand all staff use them.

At a minimum, you should have:

1. an incident management system;
2. password management software; and
3. multi-factor authentication for all key systems.

6. Staff management

Prepare a strong onboarding and offboarding process, with periodical review. Make new and existing staff aware of your processes and policies. Ensure access is removed when offboarding staff across all key systems.

In our next blog on web applications security we’ll look at building passive security for web applications.