By Dr. Johannes Bauer, principal security advisor, identity management & security, UL
Cybersecurity breaches are part of the nasty reality of today’s IT infrastructure and even though they are not commonly talked about, many individuals and businesses are the targets of attacks. Sometimes the victims are none the wiser that a breach even occurred or data was stolen. When looking toward the Internet of Things (IoT), it becomes even messier. With over an estimated 30 billion connected devices, IoT cybersecurity has a greatly increased attack surface compared to enterprise infrastructure. This also provides an attack surface that is decentralized and distributed among millions of different networks all over the world.
Everything would be so much easier if only, after the discovery of an attack, we could push a button, go back in time, and do things over. With no DeLorean with a flux capacitor on the horizon, that option falls flat.
The first important thing to realize is that security is not a feature or property of a product. Instead, it is a process, i.e., constantly evolving and changing. The rules of the game are changing, and they’re changing fast. The reason for this is fairly simple – software in our connected products today is complex and consists of many thousands, sometimes many millions, of lines of source code. It is guaranteed that somewhere within this code, there’s a vulnerability lurking – a length field that has not been validated properly, an SQL statement that does not properly escape its input or a webpage that includes untrusted data. At the time of manufacture, such issues might be completely unknown to the vendor of a product and, unless anyone specifically looks for these problems, they’re not going to pop up. Even worse, we’re still discovering new types of vulnerabilities, which once known can affect software previously considered secure.
Once they’re found, these vulnerabilities or weaknesses can often become public knowledge, either through responsible disclosure by a security researcher, through direct exploitation in the field, or by reverse engineering patches which show where areas of code have been updated. Anyone can then easily pinpoint and target a specific vulnerability in order to exploit it.
Therefore, in order to remain ahead of the curve, it is crucial to know what software is contained within a product. This not only means all proprietary software components but, sometimes even more importantly, all third-party code installed and used by the proprietary code as well. For each component, it’s vital to know that this is part of the overall Software Bill of Materials, but it must also list the exact version included within the package. Everything on the list can be continuously monitored in order to be notified of any potential vulnerabilities. A good place to start is looking at MITRE’s Common Vulnerabilities and Exposures (CVEs) list, where over 130,000 vulnerabilities are recorded and continuously tracked. Those CVE identifiers are used to uniquely itemize vulnerabilities. Databases like the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD) refers to the MITRE list and gives not only a rough quantification of their severity but also enriches them by cross-referencing original sources, fixes or test code.
But what happens if such a dreaded notification comes in? First, citing the advice of Douglas Adams – don’t panic! Not all vulnerabilities, even those that are marked as critical, affect every product in every configuration. This is why the triage of security issues is a crucial step in the evaluation of a weakness – somebody in the organization needs to determine if the vulnerability is even effective in the way the product has been built. Many bugs only affect certain architectures under which the dependency has been built or build-time configuration variables such as linked libraries. Others only affect protocols that are configured in a certain fashion – something that might not even be used in the product itself. Examples of either would be a library that is only vulnerable if it includes XML parsing support or a TLS library that only has an issue when used with a specific cipher suite.
Unfortunately, this triage process can be quite complex and detailed, and often requires skilled resources to assist or perform the process.
These resources responsible for triaging the vulnerability need to decide if the product is affected by the vulnerability, and they also have to estimate the worst-case impact. For this, many things need to be taken into consideration. How large is the attack surface? How many products are in the field? Are there security controls or countermeasures already in place? After deliberating on all of these aspects, an action plan needs to be formed. Usually, patching the vulnerability is the clearest path forward, but it’s not the only one. In fact, some circumstances even make it impossible to update a specific software component, so alternatives and workarounds are often necessary.
For example, rather than patching or removing a vulnerable component, remediating countermeasures can be implemented. If a vulnerability is discovered where oversized data for a particular protocol can trigger an exploit, then a simple remedy could be to implement a firewall rule that discards such large packets before they even get to the vulnerable piece of software. For example, limiting the size of DNS packets to prevent a buffer overflow.
Of course, such a change can have adverse effects on the product itself and needs to be thoroughly tested before putting in effect.
Lastly, if neither patching nor a workaround is possible, the last resort can be to accept the residual risk and mitigate only the impact of a vulnerability. An example of this would be a piece of software that has a weakness which allows attackers to crash it remotely. At a minimum, the software could be configured to automatically restart in case such an event happens, and perhaps to send a notification that something has happened so that potential exploitation of the vulnerability can be monitored. Needless to say, from a security engineering standpoint this isn’t the most desired outcome, but the harsh reality is that we often don’t get to cherry-pick the prettiest solution. While it might seem unorthodox, such as “software duct tape” can get the job done long enough to bridge the gap until the root cause of the issue can be properly fixed.
All of these actions are process measures that every manufacturer can undertake as part of their development efforts. With effective monitoring of known vulnerabilities, fast response time, competent triaging, and rollout of mitigation, many cybersecurity attacks can be stopped before they ever can develop. If all of the above advice is followed, however, how can one measure the performance or effectiveness of such a process?
Similar to functional testing, security can also be proactively tested. In particular, when we are looking at products, penetration tests can often achieve this goal. Pentesting is when ethical hackers – people who are paid to find vulnerabilities in products – try to hack the product so the unethical hackers don’t get to. These pentesters will report any findings to the vendor and the issues can be fixed as part of the regular development cycle, with some weaknesses patched before they are ever deployed in the field.
Still, it is a possibility that despite all those best efforts, a product or company gets hacked in the wild, with no prior warning or heads-up at all. Of course, this can be a very difficult and stressful event to manage, but when this happens it’s crucial to again remain calm and be deliberate about the responding steps. It could make a situation much worse by falling into panic. Ideally, the person who is designated as responsible for security already has an incident response plan worked out. Of course, this plan cannot know of any attack details – but it considers the infrastructure and components within it and can estimate different rough scenarios. In a well-prepared environment, many of these scenarios will have been played through as part of the threat and risk analysis – the correct vendor responses are already roughly laid out.
In the aftermath of an incident, finding the root cause and performing a forensic analysis of the attack is almost as crucial as mitigating it in the first place. You would want to find out all the details, including (but not limited to) when the attack started, what the attack vector or process used to exploit the system was, what data was compromised, modified or deleted, and how you can effectively guarantee going forward that this vector cannot be used again to compromise your infrastructure or product.
Rolling out good security is much like playing a game of chess – you do not get to pick the move your opponent will make, but you can plan well ahead and you alone get to choose the appropriate response. Well-defined responsibilities, and proper issue and vulnerability tracking go a long way and are as close as they will get, to preventing security attacks before they even start. However, just like in chess you can expect to have some setbacks. Careful planning to help ensure timely response to events is therefore vital. NIST has a great summary of this approach in its Cybersecurity Framework – Identity. Protect. Detect. Respond. Recover.
In today’s world, security is everyone’s business. What are you doing to help secure your systems?
To learn more, visit IMS.UL.com.
About the Author
Dr. Johannes Bauer is the principal security advisor, identity management & security, for UL in Frankfurt, Germany. Dr. Bauer has a Ph.D. in Computer Science and has over ten years of experience in the field of IT security. In particular, he has worked in the fields of electromobility and smart home systems. Dr. Bauer has expert knowledge of physical threats to embedded systems, both invasive and non-invasive, and he has published multiple papers on mitigation strategies to thwart such attacks. He has frequently led workshops on topics of applied cryptography and worked as a security consultant, guiding secure software design and development as well as practical threat and risk assessment.
UL is a global safety science company. To learn more, visit: https://www.ul.com/
