Getting to understand the basics of security

Written by DragonBe's PHP blog - - Aggregated on Friday February 8, 2019

In this article I first try to understand what security is and what are best security practices for web applications.
In my previous article "The challenge for 2019 has just got real" I had set a challenge for myself in 2019: to learn more about securing web applications in general and PHP web applications in specific.
In this article we're going to explore what security means and what basic steps should be considered in providing security. After all we want to incorporate security in our design and development process instead of trying to bold it on at the end.


What is security?

Security is freedom from, or resilience against, potential harm (or other unwanted coercive change) caused by others.
This quote is taken from WikiPedia where in my opinion the goal of security is very well described.
What I'm missing in this quote is the fact it also safeguards and protects valuable assets or people. But I might confuse security with safety, where the latter is aimed to keep items or living organisms safe from harm.
Looking at the goal of my exploration, building secure web applications, I need to understand the basics of good security practices. I found DarkReading: Back To Basics: 10 Security Best Practices where the author lists ten things you need to consider in regards to security:
  1. Patch
  2. Limit
  3. Check
  4. Segment
  5. Automate
  6. Visualise
  7. Document
  8. Align
  9. Educate
  10. Measure

My interpretation of security best practices

I believe these are good first basics to get started, but I would like to have them ordered differently. In terms of securing a typical web application, I need to look these steps a bit differently.

1. Document

I should document the design of my application. This means I should detail the platform (a part of) the application will run on, what sort of tools or services should be present and what ports are required. And this should be done for each aspect of the application. If we split up responsibilities of the application, we might want to include which pieces of the application should connect with each other and in which direction.

2. Align

I always tell people that good agreements make better friends. This is why documentation is so important in any endeavour you're embarking on. The documentation should also specify what is expected by anyone on the team so everyone knows who's responsible for what and what will be the result of their work. A good distribution of skills and experience should create an awesome team.
Of course, the people that are part of the team you're working with should feel comfortable in the role they were given and they should feel a valued member of this team.

3. Automate

If we automate the setup of our platform and application from the beginning, we already have a playbook to get started with those things we should optimise over time like software updates and automated deployments. This automation should set up the infrastructure, remove the pre-installed bulk of services, tools and libraries (clean slate), update the platform to the latest version and install only required components we need on it.

4. Segment

Because a web application consists of different purpose areas we want to segment these areas as much as possible and apply the concept of single-responsibility. All this is handled by our automation step.

5. Limit

Since this segmentation flows naturally into limitation, we can ensure that we define rules how segmented components should interact with each other, what connections we allow inbound and outbound, and which users (if any) should have access to these resources. Again, automation should make this a trivial process.

6. Patch

We need to ensure we're always running the latest version of the OS, library, tool or service we're using and when patches are available, this update should be easy to apply. Considering it's a repetitive process, we should automate this.

7. Monitor

Alongside the installation of required OS, tools, services and libraries, special attention need to be put in monitoring of these systems. Upfront you should define metrics that you will measure, how you can distinguish normal telemetry from abnormalities and how you're going to alert on these abnormalities.
Given that you can not secure a system 100%, you need to be able to discover intrusions and have a remediation plan ready.

8. Visualise

Your whole infrastructure should be visible from every layer:
These application diagrams provide useful information for your team to pinpoint weakest links in your architecture.

9. Check

In the article the author used this part to enforce policies, but I would disagree. Checking things should be a process where expectations should be verified.
At one point you have a working environment with a variety of platforms, networks, services and applications. If you want to know for sure they are meeting your requirements, testing for these requirements is your only option.
With my background in testing I would suggest that you apply a few testing approaches to ensure the running architecture meets your expectations, preferably in an automated way.
Some of the tools I can think of:

10. Educate

Knowledge sharing is one of the most important aspects of a thriving team. We use Phabricator as our central activity hub. This is where the code lives, commits are reviewed, documentation is written, projects and team formed and so much more. By creating a blameless environment with transparent communication for everyone, we are able to educate everyone in the team on every aspect of a project.

Summary

We now have a better understanding what security means and what we should do to improve the security of web applications. In next articles we're going to break down each suggested action and work our way towards a more secure, robust and performing web application architecture. Until next time.

« The Disney-fication of our world - Cal Evans

Facebook Code - Team behind Infer wins POPL 2019 Most … »