Automated Vulnerability Scanners and a False Sense of Security

by bhagred

Following numerous cyber incidents involving supply chain compromises, the security industry has been supplying tools to help larger enterprises gain assurance that they can rely on their supply chain when it comes to cyber security.  Those tools are providing organizations with a false sense of security and masking issues behind tools and paperwork.

I have worked in Small- to Medium-Sized Enterprises (SMEs) for several years now and have seen a pick up in the number of companies using automated vulnerability scanners to provide small companies with a security score.  Once those scores reach a particular threshold, they are deemed safe to use, only often that is far from the case.

SMEs often put security at the bottom of the pile when it comes to maintenance and development of systems.  There are several commercial reasons for that, the most important being that they need to build functionality they can sell.  And they probably cannot afford the experienced and security aware developers they need to make their applications as safe as they should be.

Security might help a sale but how do enterprises know if that small provider is safe to use from a cyber security perspective?

They often turn to a third-party provider who will do automated scans against the small provider as part of their due diligence.  The results of that scan then provide the enterprise with a signal if they should continue with that provider or not.  Those scans often give false negatives.

The company I currently work for has recently received two of these scans from two of our biggest customers.  Both of them appear to do fairly simple scans to check the software versions that are in use on our servers.  That certainly does give an indication of how seriously the company treats security, but it is way too shallow a scan to give any indication of their overall security position.

One scan we were recently put through gave us a score of 78/100 despite the fact that it found one of our servers was using outdated software, and I mean really outdated (it was still using PHP5).  The server in question was not actually in use for production purposes and was being used for training.  But we obtained the code prior to us telling them that.  On that particular scanner we were deemed amber in terms of usage and were two marks of green.

Other customers insist on seeing copies of our own automated pen-tests.  Which show very little in terms of any critical issues but do pick up some small and incredibly difficult to use security flaws.  They go away happy and continue to supply us with business.

Now contrast that to our own internal analysis of our security.  Not using an automated vulnerability scanner or an automated pen-test, but a static analysis tool (SonarQube - www.sonarqube.org/downloads), backed up by some human analysis of the results.  This has identified approximately 1000 security holes (we are still analyzing the results).  These range from data leaks from website pages that have zero security to SQL injection vulnerabilities that would take five minutes with SQLMap (sqlmap.org) to do a full data extraction.  There are also an abundance of session issues and XSS issues.  None of the automated scanners have picked up any of these vulnerabilities because they are not looking in the right place.

They are missing them because they are only interested in a superficial surface scan.  If I gave you the landing page of our website and you did a full scan from that page you would find nothing, even if you followed all of the links from that page.  However, if I were to give you the full list of every URL on our website and let you do a scan, then the red lights would start to flash.  If I then gave you a demo account to login with and you did a full scan with that and the list of URLs, I can guarantee you would start to ask some serious questions.

But if I gave you our source code, or access to our Git repos and allowed you to do your own analysis, it would take a decent security aware developer ten minutes to come to the correct conclusion: don't use that company.  Now we all know the chance of getting hold of the source code from one of your suppliers is not going to be an easy sell, but I would argue that in the long run, this could benefit those security aware suppliers.  Particularly if you have a a non-disclosure agreement set up with them.

If you work for a large enterprise and are worried about your supply chain cybersecurity, then you need to do more on your supply chain cyber security due diligence.  Doing it correctly requires more than the use of simple automated score-based scanners.  It requires access to systems, access to source code, and some static and human analysis to tell you if that supplier is secure enough for your business.

If you are a supplier and you really want those juicy enterprise contracts, then you need to start treating security as a serious advantage to your business and not as a money pit.  Do everything you can to make security a competitive advantage for you.  Give them access to a demo account on your site, and do automated pen-tests that cover the whole of your site and not just the superficial pages.  Share the results of your pen-tests.  Build security into your development process and give serious thought to making your source code open-source (not the best bits, of course).

If you are a security consultant working with an enterprise looking at their supply chain, please start taking a more in-depth look at those suppliers.  Those decisions are normally based on the volume of data being shared with that supplier and the type of the data.  But take a look at the integrations and see what trust is being implied.

If you are a supplier for scanning tools (or work for one), you need to start looking a lot closer at what your tools are checking for and how easy it would be to make that score jump.