Last week was sadly remarkable for the cybersecurity industry: former New York city mayor Rudy Giuliani, compared cybersecurity to cancer, while famous security expert and journalist Brian Krebs pointed to serious problems at Norse Corporation, a prominent cybersecurity startup recently backed by KPMG VC investment of $11.4 million.
Both events undermine trust in the cybersecurity industry and its players. I think it’s too early to speak about a cybersecurity bubble, however, it becomes more and more difficult to distinguish genuine security companies, with solid in-house technologies, and experts with flashy marketing and FUD (Fear, Uncertainty, Doubt) tactics. This makes the process of cybersecurity RFP (Request For Proposal) more complicated and challenging for organizations of all sizes.
Last year, many friends of mine - security professionals and managers within different organizations -- complained about their disappointments with RFPs for purchasing various cybersecurity products or services. An open and transparent bid is probably one of the most efficient ways to get the best price/quality ratio available on the open market. However, the invisible hand may not always work properly for the cybersecurity market due to its complexity and dynamically changing environment. Nevertheless, a cybersecurity RFP can be successful, if we take into consideration few simple rules:
Make sure that the RFP is aligned with your corporate risk management strategy
Before purchasing any security product, system or service – make sure that the new security control will properly mitigate your security risks in the right priority. New trends regularly appear on the cybersecurity market, and often companies invest into novelties just to follow the fashion. If the most important risks to your business reside in the area of insider threats, it would be wrong to spend money on external threat intelligence, before ensuring that you have a properly working DLP corresponding to your risk appetite.
Quite often, a new security trend is just a nice wrapping around previously existing risks, threats and vulnerabilities. Nevertheless, sometimes new trends really represent an important, previously ignored or non-existent risk, and it’s worth conducting a risk analysis to define if, and how, you shall mitigate it. New technologies can bring great insights and added value to your corporate cybersecurity and reduce the costs. However, before deploying them, make sure you have a clear vision of how and where to integrate them into your risk management strategy and risk mitigation plan.
Be precise and detailed in every requirement
I've seen hundreds of RFPs with very vague requirements and definitions, such as product capability to detect OWASP Top Ten vulnerabilities, without any additional details. Today, it’s hard to find a web security vendor that would not claim that their product detects OWASP Top Ten vulnerabilities. However, it’s very important to understand a vendor’s technology, its efficiency and practical capability to detect the OWASP Top Ten.
For example, classic XSS vulnerabilities, are fairly easy to detect with automated tools, however what about DOM-Based XSS, XSS inside JS, or Blind XSS? What about a WAF bypass? Moreover, some of the OWASP Top Ten vulnerabilities cannot be reliably detected by automated scanning (DAST) by definition, due to their complex nature.
The quality of detection, false-positives rate, and other nuances are also very important. It’s pretty easy to identify all web forms without an anti-CSRF token, and many web vulnerability scanners will detect all of them. However, poorly implemented CSRF protection can be bypassed, moreover many web forms do not perform any sensitive actions and do not really require CSRF protection. Do you want to know if your CSRF protection mechanism is reliable and get a list of practically exploitable vulnerabilities, or just get an endless list of all web forms without CSRF protection? It can be a huge difference in practice, all being equal in the RFP.
Request technical demonstration and testing in your own environment
Many companies create artificial environments to prove their product efficiency. In web security, there is a great variety of frameworks and web applications intentionally left vulnerable to test and compare web security testing solutions. Not surprisingly, many of them are suited to a particular product, its internal logic, crawling mechanisms and vulnerability detection algorithms. Such tests are very far away from the reality and cannot be used to conduct product comparison.
Therefore, always ask every vendor for a demo in your environment, not in their own. Otherwise, you risk buying a pig in a poke.
Price shall not outshine the expertise and experience
Make sure that the company with the lowest price has technical experience, customer references and case studies of implementing the projects of the same scale as yours, not just implementing the same product or solution. In many cases, lowest price means lowest quality of delivery, implementation, support or maintenance. Make sure that you don’t give too much % weight to price in your RFP, otherwise you force competent companies to ignore it, while IT integrators will offer a service they have never done before at a miscalculated price. Later, once they realize their losses, they will be obliged to cut their future expenses at least to breakeven, quite often putting the entire project quality at risk.
Don’t forget about Service Level Agreement (SLA)
Some companies, forget about SLA, relying on their friendly relations with vendor’s sales people and flashy marketing materials. Sales people have strict KPIs and obviously won’t tell you the inconvenient truth about the product. If you have a particular requirement to the service quality - make sure that the RFP participants are aware of it, and are ready to commit contractually.
For example, a Web Application Firewall service may easily resist small DDoS attacks. However, if a proper SLA is not in place or there are no have financial sanctions for its violation, during a large-scale DDoS attack you may be suddenly surprised by going offline in few minutes since its start. Friendly sales people will make excuses on the phone each time you call them, however your website won’t be live for another few days.
Robert Metcalf, cybersecurity expert at PwC Switzerland, comments: “In order to achieve your objective it makes sense to request a proof of concept (POC) – try before you buy – which will help clarify your requirements as well as help you select the right solution to your issue.”
By following the above-mentioned rules, you may benefit from the advantages of the open market without putting your project at risk.