Last week, I learned about a new kind of Denial-of-Service attack vector that uses a feature of WordPress. Hijackers utilised over 162,000 WordPress sites in a plot that turned the sites into a criminal botnet, forcing them to launch DDoS attacks. In this particular case, the developers had decided some time ago to turn a feature ‘on’ by default, rather than having it automatically set to ‘off’. They even made it challenging for users to disable, and you can assume that many of them weren’t even aware that anything had changed.

Leaving aside the technical details, it got me thinking — there’s an age-old and well-known pattern amongst many systems; they are not configured to be secure, rather they are configured for ease of use. Most developers create sites that ‘simply work’ for the users and rarely think about security. For those that are security-minded, features are often added only as an afterthought, they’re rarely integrated into the core of the system. Security professionals spend their lives working hard to prevent breaches, and are usually strict in defining what is allowed and forbidden — hark back to floppy disks and CD drives, preventing USB access, restricting or prohibiting internet access; hardening servers to the highest extent possible. Today, it’s still common to prevent access to social media as a means of security.

This conflict of interest with developers is one of the main reasons why security professionals were known as ‘Mr. No’; simply denying user’s requests for new technologies without any explanation. More often than not, the end result is jeopardised security; either because people find ways around the restrictions, or because senior management overrules security to satisfy business requirements.

The previous ‘just say no’ approach is no longer sustainable. Security needs to closely align with business requirements as well as user expectations. By using a risk-based process that starts from a business impact analysis, it allows you to have an approach that better balances the needs of all the parties involved. An evaluation can unite the security and business requirements, and these can be defined with technical or organisational controls that can contain the remaining risks. This will then lead to faster responses to new requests.

However, as the WordPress example shows, it’s not enough to only perform this exercise once during the introduction of a new service or technology. These updates to risk assessments need to be performed regularly; updating and enhancing your controls based on the changing threat landscape. The frequency of this exercise depends on the criticality of the system and the current threat environment and, of course, risk updates for internet-facing systems may be more often required than for internal systems.