With the recent news that TalkTalk has suffered both a cyber-attack and ransom demand, tightening up online security is once again still at the bottom of everyone's agenda.
Security just isn't sexy. The default position in too many companies is to lock everything down to the nth degree, then open up seemingly minor ports and IP addresses for 'exceptions.' I haven't read enough about the TalkTalk crack yet to put together any commentary on what happened there - but if you're reading this as someone in charge of your business' information security, here are a few pointers.
Authenticate your users properly
Authentication is the process of checking a user is who they say they are. In most modern systems with a username/password combination you're assumed to be that person. Think about adding two-factor authentication to add some spice; most people carry mobile phones now and authentication key managers like Google Authenticator will cost very little to integrate. If you're not ready for that; then add in random checks via text messages or automated phone calls.
Check your authorisation logic.
Too often once a user is authenticated they get permissions to do anything; or nothing. It's the old principle of protecting a castle or a hotel. Too often we choose the castle method - securing the perimeter and then expecting everyone on the inside to be on our side. Instead you should switch to a hotel permissions module; stop focusing on the perimeter and focus on your data packets - making sure individually only the right people can access them for the right period of time. Your hotel manager disables your key at check-out time.
Stop making 'exceptions' and change your global policy
Twitter, Facebook, Pinterest and other social networks are becoming the 'norm' - as are API connections to them. Instead of locking down your environments and just opening up access to these 'safe' networks, review the reasons why these are regarded as 'safe' ahead of sites like the BBC, this site, or Ebaumsworld. If your machine is going to be connecting to API services, then you should assume you're open up to the whole internet; who knows what could be passed down that API? Have a global policy that reflects the requirements of your business, not the whims of your IT manager.
Run servers with a single role
If it's a database server, use it to serve a database. Seems simple enough, but then you need to install SQL Server Studio so that your remote team can login and easily access it. Don't. Secure it to the level required for your business usage, then allow your DBA team access only to the DB port. They shouldn't need RDP access to the machine, that's a Systems Job, not DBA.
Change authentication details regularly.
It's a simple one, but never rely on a static password/passphrase or token. If when creating a new password you haven't got an easy plan in place to change it often, then you'll forget about it.
Implement a 4G firewall (but allow employees public internet access without sniffing).
It's one of the few sales pitches that sold 'next gen' technology that I found incredibly humbling. Palo-Alto demo'd their PA-200 just before it's release back in 2011. Instead of looking at ports and analysing traffic, it would carry out packet inspection to decrypt protocols passing over your network. Whilst I'm a big fan of open data and open standards for the public internet, I'm also an advocate of encryption, privacy and data security. As an organisation you have to take responsibility for the security of your own network and I'd suggest if you do go down this route, then be careful about how you implement your network. You may wish to give employees a separate line for access to the 'public' internet so that you mitigate any risk as your security procedures forcing you to intercept all employee messages.
Encrypt your data
Encryption is cheap; don't encrypt big chunks of data, but encrypt each 'segment' of data individually. Work out how big/small those segments should be, or even better give your end users control over how much data they want to put into each envelope. A good example is the password management company LastPass. Despite keeping each user's password vault on it's servers, each vault is encrypted by an individual user's encryption key. Now LastPass were hacked, but their architecture meant that the bad guys got away with very little useful information; yes - there were improvements to be made and LastPass identified and addressed those issues - but ultimately the information that I'd asked LastPass to protect - my passwords - was protected. They're also a great example of how to react when you do have a security incident.