Security is Hard: Where Do I Start?

This post is not supposed to be a complete list of steps a company should take when securing a network, system, or company – but more of a handy reference for when companies ask me: “Where do we even start?” Which happens about once a week…

Patch everything, immediately. I don’t care if you have a business requirement for that software, if it’s vulnerable and there’s public exploit code or an easy to use exploitation tool available – then it’s going to be compromised. The UK Government says you should be installing all patches within 14 days [Cyber Essentials Requirements, Page 12].

Change your default passwords. Do you want to be part of a botnet? because that’s how you get added to a botnet. Mirai showed us the default accounts will be found. This includes your firewall, servers and that ridiculous IoT fridge that you bought.

Network Segmentation is key. Do mobile devices need complete and unfiltered access to the server range? Gosh I hope not. You should segment devices logically by type; set up choke points between device types and heavily filter based on port and protocol. If you can restrict and monitor in this way then network propagation will become significantly harder. Consider how you can restrict an attacker moving from corporate wireless to the server range and how you can prevent that. Consider how you can prevent an end-user device compromised by a phishing attack from reaching the servers. What about the mobile devices too?

Manage out of band. If your management plane is logically, or physically, separated from your data plane it makes the task of an attacker monitoring of modifying that traffic one step harder. This is not a replacement from using good protocols (SSH not telnet) but is an additional security measure.

If you don’t need it, disable it and then monitor it. Protocols such as NetBIOS-NS and LLMNR can make both initial account compromise and privilege escalation trivial. If you’re not using them (pro tip: you’re not) disable them. Take a look for legacy and weak protocols such as telnet and older versions of SNMP.

PSK for wireless is not good enough. Not only can PSK networks be cracked off-site (once a handshake has been captured, which can take seconds) but also there are key distribution and key management issues. You should look in to deploying 802.1X which utilises client-side digital certificates and active directory authentication. You should have a plan for protecting against stolen or infected end-user devices and you should have a plan for access revocation.

Mobile Devices will get lost. Remote erase, a secure pin number and encryption-at-rest are essential. Your threat model will give you the specifics of whether fingerprint access is acceptable, but you should accept that devices will be lost and stolen. The data on the device should be protected as should the access the device has in to your internal network – such as VPNs. Encrypt the data on the device so that it cannot be accessed or modified; enable remote wipe which may help with damage limitation; have the ability to be able to revoke a devices access to the VPN.

Enable Two Factor Authentication (2FA). This isn’t the same as enforcing 2FA, but simply by configuring systems such that additional protection measures, can be used will allow those users at a higher level of risk of benefiting from those protections. Social Networks Facebook and Twitter operate in this way with optional login verification. You can even use Google Authenticator with WordPress! There are lots of options for 2FA with Active Directory. This will also assist with the issue of password reuse and the risk of phishing credentials from users.

Password reuse will be your downfall. If you reuse passwords between websites any single compromise will compromise them all – therefore you should consider password managers. Also consider your local administrator password for workstations; if it is reused then any single system being vulnerable could allow an attacker to extract that credential and propagate rapidly.

Restrict User Input. If you’re writing a web application then contextually filter user input through a white-listing approach to match each expected input – e.g. if you’re asking for an phone number does the input look like a phone number? If you’re managing desktop workstations then restrict access to features of the system not required, be that directly on the desktop or through a remote environment like Citrix.

Restrict User Access. Network Access Control applies to both wireless and wired networks and should be rigorous. Don’t restrict access based on something public and easily forged such as MAC addresses but instead utilize something like client-side certificates or active directory integration to determine whether machines should be allowed access. For web applications and external infrastructure restrict access to administrative interfaces to administrative machines only.

Weak Encryption will be Broken. There’s a lot more to cryptography that just what encryption algorithm you’re using. With implementation issues, algorithm issues, hashing issues, padding issues, PRNG issues. There’s a lot of complexity and a lot that can go wrong – plus vendors take an awfully long time to actually remove default support for issues – just look at Microsoft talking about “sunsetting” SHA1 back in 2014 and then again talking about it in 2016 to say deprecation will start in early 2017.

You should gather analytics on how many of your users are utilizing each algorithm so when you’re looking at calculating the risk for removing support for certain ciphers and configurations you know who’s affected, how much traffic and revenue that is for you – when you’re making difficult decisions you want to be armed with all the required information to make an informed decision. Remove old and weak ciphers quickly and remove broken ciphers immediately. Try to keep a real world understanding of the risks of each attack and new weakness – issues like CRIME are minor, simply acting as a bypass to HttpOnly protection, whereas attacks like RC4 NOMORE are a big deal.

Trust but Verify. Test your systems. I don’t care if you use a simple vulnerability scanner, have an in-house testing team, utilize third-party penetration testers, have a bug bounty, or all of the above – test your systems. I’m a big advocate of third party penetration testing, as I personally believe human driven testing far outperforms automated testing and I also believe you shouldn’t mark your own homework, a third party perspective adds a lot. However, whatever your budget, team size, or internal capability do everything you can to actively verify which security controls are effective and which aren’t.

Before attackers come, have a plan to respond. The period of dealing with a security breach is one of tension. If a company is not adequately prepared for the efficient handling of an incident then a time of tension becomes one of crisis. Effective incident response plans detail critical steps for staff to follow when they’re in a high stress situation: who to inform, what their responsibilities are, immediate actions for responders, and how to document the whole incident. Have a concise, easy to follow procedure for identifying and responding to a security incident – and just as you should test your systems yous should test your response plan.