Last week we talked about how to prevent the keys to your kingdom from falling into the wrong hands. This week we’ll have a look at how to secure your application.

Part II – Guards at the gate

The moat, the drawbridge and the guards at the gate all exist to limit movement in and out of the castle. In a network, it is the firewall, intrusion detection system and data loss prevention tools that ensure only authorised network traffic is moving into and out of your network.

When it comes to securing your website you will need the following:

• A firewall to close down access to unused ports and restrict access to others. Well written firewall rules will use a default deny all for all inbound traffic. That is if there is no matching rule for inbound traffic then deny by default. For simplicity many firewall rules allow all outbound traffic by default, however a genuinely rigorous firewall config will deny outbound traffic by default only allowing known traffic to leave the server or network. This is more time consuming and involved to set up, but it is also much more secure.
• Network based intrusion prevention system (IPS) to prevent attacks from reaching your server. The role of an intrusion prevention system is to block malicious traffic before it reaches your server. This is particularly useful for blocking known attacks, particularly scripted attacks.
• Host based intrusion detection (IDS) to raise alarms if any attacks manage to breach both your firewall and your IPS. There are scenarios in which a skilled attacker could access your server, even when firewall and IPS defences are in place. However, it can take some time before remote access has been escalated into full exploit, and the role of host based intrusion software is to look out for and create alerts for changes on your server. If the IDS detects changes on the server the administrator will receive a mail and from there it is a matter of taking action and responding (this is where good backups really help).
• A good security plan will assume that at some point your data will fall into the hands of the attackers. Strong encryption when data is in transit and “at rest” (i.e. stored in the filesystem or a database) adds that final layer of protection. So long as the encryption is strong and the keys are secure your data will remain inaccessible and secure even if it has fallen into the wrong hands.

All of the above becomes a moot point if good security practices are not followed and an attacker is able to guess or learn a password. Ensure these basic practices are followed:

• Use ssh key based authentication only for server access and disable password authentication. This closes down brute force ssh attacks and eliminates the possibility of passwords incorrectly shared or saved in clear text in a general access document.
• Too many CMS users use weak passwords. Enforce strong password for CMS log-ins.
• Enable https on CMS logins. Because the main site is http only, the CMS login is also http. An attacker on the same network (cafe or airport wireless network for example) could easily intercept and read the login username and password. Enable and force https login to prevent this.
• Enable and use 2-factor auth on CMS logins. Not all CMS’s support this yet, but for those that do it should be enabled and at a later stage enforced.

Next week I’ll talk about the business as usual security practices that needs to be in place to keep your website or application up and running in “Part III – Behind the walls”.

 

Warren Howard is an infrastructure specialist with an interest in leveraging technology to streamline business process. He has delivered solutions for international clients such as Coca-Cola and Holeproof.