|
|
posted: July 16, 2022
tl;dr: Although imperfect and potentially misleading, security scanning by checking version numbers has some benefits...
There are many ways to attempt to uncover security vulnerabilities in a software system. You can use programs which utilize known exploit methods, such as a SQL injection attack or a Distributed Denial of Service attack, to try to cause the system to malfunction. Other programs will exploit particular vulnerabilities (bugs) in various software components, such as the operating system or networking stack. You can hire a team of white-hat hackers, or put in place a bounty program, to stimulate creative new ways of hacking into the system or breaking it. Or you can use a program which just surveys all the software components of the system, gets all the version numbers that it can find, and produces a list of the components and their known security issues based upon published security bulletins.
I am seeing that last one, which I call a superficial security scan, more often these days. I call it ”superficial” because it doesn’t uncover the existence of an actual security problem. There’s certainly a potential for the known security vulnerability of a software component to cause a problem. But that security vulnerability often depends on how the component is used. It may be in a feature of the software component that is not even being used in the system. Nevertheless, because the security vulnerability may be classified with a scary word such as “severe” or “major”, it can cause a lot of angst when people read the report. The less technical the report reader, the more likely they are to panic.
Suppose the MacBook Pro I am using to compose this post is part of a software system in a retail store, but it is only being used to add up purchases. The Calculator is the only application being run. The MacOS operating system contains many other features and applications, any one of which might have a security issue. Suppose the Safari browser has a known security flaw that can allow a bad actor on the Internet to take control of the Mac remotely. Along comes the superficial security scanner which discovers the version of MacOS, looks up the known security issues, finds the Safari browser issue, and lists it as a severe security flaw in the report. Confidence in the entire software system has been reduced, even though there is no demonstrated flaw.
A superficial security scan doesn’t guard against attacks that rely upon social engineering
Now in this example it may be fairly easy for someone to read the report and determine that the Safari browser flaw is irrelevant because the browser is not being used. In other systems, it is often much more difficult to determine if a given security issue actually applies. The issues often involve technical detail and minutiae that only skilled software developers understand. Most issues do not happen all the time: there is often a set of necessary input conditions to trigger the issue. It can be hard-to-impossible to assess if those conditions will ever be met in real-world usage.
What should be done with these reports, especially after giving them to the experts and hearing them respond “we’re not sure if any of these potential issues actually apply”? There are a couple good hygiene practices which can help address the potential issues.
The first is to upgrade the software to incorporate more recent versions of all the software components. Hopefully this upgrade process is not too hard; this is why I recommend that the first feature to put into any software product be software upgrading.
The second and even better is to simplify the system, where possible, by removing software components. In the example above, the MacBook Pro is overkill if all it is being used for is a calculator. Better to replace it with a dedicated calculator; the calculator will have a much smaller set of potential security issues than the MacBook Pro. This is another place where the design philosophy of elegant simplicity can pay dividends.
All this work may be for naught, as there may not be any actual security flaws. But by applying one or both of the solutions described, it should yield a better product, even though the security scan was superficial.