It's not paranoia if they're really after you

The internet is one of mankind’s greatest inventions. It brings everyone together. When you put a website on the internet, you’re connected to more of humanity than ever before. And when users come to use your website for its intended purpose - be that to provide information, to get something done, or to entertain - they deserve to be valued. At SilverStripe, one way or another, almost everyone works to ensure the experience for all those people is amazing.

But as CISO, my job is not about helping these people. My job is to worry about … the others.

Here are some of the people that it’s my job to think about:

• People whose idea of fun is to find poorly configured websites and break them.
• People who want the confidential information stored in your website, to use for profit or further malicious action.
• People who believe that direct action against your website is acceptable activism.
• People who don’t care about your website particularly at all, but want to use your server to host their own website - often because their website is illegal, and can’t be hosted normally.

I do not work to make the experience of these people amazing. I work to maximise their disappointment. What I think about is how to stop them from doing what they want.

I can’t do it alone though - I need your help. Come, join me in stomping on the fun of others with these six security considerations to include in every project.

1. Be aware of the OWASP top ten

The OWASP Top 10 (strictly the OWASP top 10 2013) represents a broad consensus about what the most critical web application security flaws are. These are the ten security issues you should be most aware of when developing your application.

Although you can mitigate all of these issues yourself, I strongly recommend using a framework. A good framework should provide you with tools and APIs to help mitigate against the OWASP Top 10.

Whatever the framework, it’s important that the developer uses these APIs, and not the underlying language features - at least unless they are sure they are aware of the protection they are skipping by doing so.

Using SilverStripe as an example, the framework and CMS provides APIs and tools to help protect against all items. Using DataList filters provides protection against injection. Using Session and Member provides protection against broken authentication. Using correct DataObject field definitions provides protection against XSS. In each case, developers can choose to use the underlying systems - make direct SQL calls, create their own authentication system, avoid DataObject casting - but doing so means SilverStripe’s built-in protection is no longer enforced.

2. Be clear about - and enforce - your permission model

Increased security involves identifying exactly what operations can be performed, and which groups of people are allowed to perform them.

It is natural while designing a system to want to allow as many people as possible to perform as many operations as possible. This allows the greatest flexibility, and puts the fewest barriers in their way between the users and the work they want to do.

However, such a design strategy introduces significant security issues. Each user that can perform an action becomes another vector for a social engineering or phishing attack. Users also have their own agendas - and these do not necessarily align with the goals of the system owners. The world is rarely black and white, and honest, moral users can be tempted to peek at data that should be off limits, or go beyond the bounds of their nominal authority when given the opportunity to do so.

Make sure when doing your business analysis that you’re not just analysing what actions are performed, but exactly who is allowed to perform those actions and in what circumstances. With careful analysis you can introduce a permission model that mirrors natural business usage but ensures each individual has only the ability to perform actions they are authorised to do.

3. Think about your risk profile

If we can make it more difficult for an attacker to achieve his goals than it is worth to him, we can make that attacker give up and go looking for easier targets.

However, increased security has a cost. There is an actual monetary cost, in that setting up and maintaining security takes time and expertise, which is never free. There is also an accessibility cost, in that increased security usually means more rules and more difficulty to legitimate use.

So we want to apply enough security to discourage attack, but not more than is necessary, to avoid wasting money and worsening user experience.

We do this in real life all the time. We leave our knick-knacks in plain view, but lock up our laptops. Our clothes are left in the back seat of our car, but our mobile phones go in the glove compartment, or are taken with us. We tell people our names but not our credit card numbers.

To do this for a site, you need to understand its risk profile. How confidential is the data you’re collecting? How valuable would access to the service be? Is the content or site owner in any way confidential, or likely to be a high profile target?

The vast majority of attacks aren’t personal or targeted. Bots loaded with databases of known vulnerabilities trawl the internet, automatically probing sites for security holes. So simply being on the internet provides a baseline risk profile. Beyond that though, the level of security effort required depends heavily on the purpose of the site.

4. Harden your servers

You should be making sure that all the software on your services is up to date. Having out-of-date software is the digital equivalent of leaving your car doors unlocked. Old versions of software often have security issues. Even when they don’t, those automated vulnerability scanners I mentioned earlier can quickly detect what versions are running, and old versions are a great signal that you aren’t putting a lot of attention into maintaining your server.

You should also be disabling services and libraries that aren’t required - not only does this remove one thing you have to remember to update, you also reduce the chance that there is an undisclosed security issue in the latest version.

Make sure your permission model extends to “who can access various services" as well - and enforce these permissions. There’s no point carefully restricting who can access what data in the CMS if everyone has the ability to edit the code.

5. Put monitoring in place

No matter how carefully you harden your system, there is always the possibility that through the diligence of the attacker, human error on your part, or a confluence of bad luck that a security intrusion occurs.

Amazingly, most security intrusions are never detected. While some attackers are doing so to disrupt your service - vandalise or bring down your website, distribute malware, or other such practises - many attackers are subtle. After all, it has taken them some effort to gain access to your system, and a slow, careful intrusion might allow them to maintain that access indefinitely.

An attacker who is after your private data can be in, grab everything, leave themselves a small entrance for later, and then tidy up all tracks so that it’s nearly impossible to even tell anybody’s been there - except when your customer data is leaked a year later. Botnets can be created from hundreds or even thousands of servers. Owners aren’t even aware that their servers can now be remotely commanded.

So preventing an attack isn’t enough - you also need to know when an attack has occurred, and what happened during that attack.

Logs are your friend here - if you are storing these logs somewhere else, somewhere the attacker can’t just edit them to remove all traces. You should also be configuring your systems to log any suspicious or unusual behaviour.

6. Have a plan for how to react when there is a security incident

Finally, make sure you know how to react if a security incident does occur. An ongoing security issue can mean your customer’s data continues to be in danger, or that attacks continue to be launched from your hardware. A security incident can also put other systems in increased risk of themselves being attacked.

It can also be a high-stress period. If there is one thing that is likely to upset your client and cause them to put pressure on you for a quick resolution even more than a site outage, it’s a security issue.

A clear, premeditated response plan that ensures a quick restoration of services, completely eliminates the attack and introduces mitigations to prevent repetition of the incident is essential.

This will include having several systems and processes already running and available for use - comprehensive, secure backups; tested processes for quickly restoring systems from said backups; chains of command and communication; methods for detecting and isolating affected systems and diagnosing the security intrusion.

Sounds like a lot of work?

Let us take care of security for you. SilverStripe Platform has all this and more baked into its design.

Please check out security features of the platform to see how we silence security distractions. For some discussion on the ways using AWS helps us ensure security, download our whitepaper Security Advantages of Managed Platforms (it’s really good–and I’m not just saying that because I wrote it).