Cyber security breaches seem to be becoming commonplace these days.
Hardly a week goes by where we do not hear of a breach at an iconic organisation. This has led to increased caution being exercised for cyber by Boards and Executives and I am regularly getting asked for advice in this key area of risk. Given the criticality of this area, I thought it best to share some advice on securing your IT infrastructure with a focus on recent threats and breach events.
When an organisation connects their infrastructure to the internet, it opens them up to numerous threats. Insecure infrastructure or data can easily lead to data breaches and exfiltration.
The questions that arises is “How do we protect ourselves?” The simplest way to provide this advice is to break this down into key control categories one should consider when protecting IT infrastructure as follows. Please note this is not a complete list of controls and policies, but rather controls specific to recent threats and breach events:
Identify critical data in systems:
- Data Classification and Discovery – know your data in the network. Discover it regularly, classify it and protect it. Do not use production data in test environments. Do not leave production data lying around unprotected.
The following controls will help protect your infrastructure:
- Firewall – anyone in the organisation should not be able to make internal systems accessible to the internet without going through change control and a risk assessment being done
- Data Leakage Prevention (DLP) – software should have been in place to detect and stop data leakage. You wouldn’t usually use DLP software in a test environment, but if you going to use actual data, you will need to use tools like this as a control measure
- Network and User Behaviour Analysis (NUBA) – a security tool that detects and can stop data leakage based on unusual behaviour. A data breach event would generally indicate unusual behaviour and these tools can be useful in detecting and preventing such an event
- Authentication Requirements on APIs – any API should require authentication to prevent just anyone accessing it and the data behind it
- Encryption – data at rest, in transit and ideally in processing should be encrypted. When all else fails, encryption will prevent valid data falling into the wrong hands
- Secure Development Training – this is a critical part of ensuring your developers know how to develop applications securely and do not perform actions that open your environment up to breaches
- Data Security – never use production data in a test environment. Use adequate access controls and segregation of duties, even in test environments.
The following controls can help detect a cyber security incident:
- Data Leakage Prevention, Network and User Behaviour Analysis and Security information and Event Management systems – these coupled with adequate monitoring should detect an unusual event such as a breach, alerting Analysts or ideally triggering automated preventive steps to stop the data leakage
- Regular Penetration Testing and Vulnerability Scanning – this will allow you to detect vulnerabilities in your environment before hackers do and exploit them.
Respond and Recover
The following controls can help with a quicker response, thus limiting damage:
- Automated Incident Response – Data Leakage Prevention, Network and User Behaviour Analysis and Security information and Event Management systems can be configured to automatically respond to a security incident and shut it down before too much damage is done. However, the risk of false positives and legitimate access being terminated is a factor to consider
- Breach Response – following an Incident Response Plan to manually contain a breach and notify the affected parties. If damage is done, as in the case of ransomware attacks, then using the Disaster Recovery Plan to expeditiously recover and restore systems.
Policy and Process
The following policy controls can provide the foundations of good security practices:
- Change Control Policy – ensuring adequate change control processes are in place to prevent risky or unauthorised changes being made
- Secure Development Policy – a policy that outlines the requirements of secure coding. This will ensure applications are developed securely and the development environment is secured appropriately
- Overall Security Policy, Specific Policies (e.g. Encryption Policy, Email and Web Security Policy, etc.) and Associated Security Architecture – a holistic view of how the entire environment should be secured along with a reference architecture that dictates what controls must be in place to mitigate threats to an acceptable level
- Incident Response Plan and Disaster Recovery Plan – as covered in “Breach Response” above.
Call to Action
Testing an IT environment for security is like testing the condition of a car before buying it. You will test drive it to see whether it runs as intended on the road. You will also get a mechanic to look under the bonnet to ensure all components are in place and operating as intended.
The same concepts apply to keeping an IT environment secure:
- Regular Penetration Testing and Vulnerability Scanning – this is like the test drive. This will allow you to see what a hacker will see and address any issues prior to a hacker being able to exploit them. That is road testing your IT environment to ensure it is ‘internet ready’
- Assessment Against a Standard – An assessment against a standard such as NIST-CSF will reveal any vulnerabilities in your environment which you can address prior to it being exploited. This is akin to getting a mechanic to look under the bonnet.