An economic and security analysis of security suites
Security suites promises easy security - the question is if this is true. We find that while security suites may create moderate improvements it is more likely that overall security risk decreases. A better alternative is to use modular and professionally managed security services where all security safeguards integrate and interact.
We observe a trend on the market where suppliers are advocating for security suites. Those suites promise to solve our security challenges more effectively and more efficiently. To verify this claims this we shall analyze the economic arguments and investigate the effects on security risks and security design principles.
The most prominent argument is that integrated suites provide better security protection. This due to the number of safeguards include in a suite and the capability that the safeguards may interoperate with each other and therefor identify and address threats more effectively. This argument, while sound, appears a bit superficial. Already today existing security products can mostly exchange data and can use data from other tools. A great number of suppliers provide well defined interfaces (API’s) that allow tools to exchange information. However, it is complex to ensure this data flows and it is more difficult to configure and tune the applications when such features are used. In other words, we could do it today but abstain because we cannot manage it. While it appears reasonable that to suites would reduce the efforts to a certain extend the most complex parts are likely not to be solved. Hence the possibility increases while the feasibility depends on other factors which implies together that it less likely to change.
Another argument is total cost of ownership (TCO). For TCO usually operation costs, supplier management costs and license fees are mentioned. Let us look at all three. Suite suppliers argue that the costliest part for security tools is the operations costs. Here specifically the need for multiple supplier-specific operations teams are mentioned. This appears to be correct. However, we should wonder if this need emerges from the supplier or, more likely, from the different domains. The specialists dealing with network security frequently require different skills AND a different mindset then the one handling endpoint security. It seems therefor more realistic that independent variables are more important for operation costs. When it comes to supplier management cost it is obvious that the overhead cost for having one instead of two suppliers is reduced. Naturally some increases in supplier management for a suite vendor are to be expected but this argument appears to hold. The last cost argument relates to license fees. Some suppliers argue that a joint license will reduced the overall cost. In the authors experience this may be true as a calculation example if the full functionality of the suite is compared to multiple individual products with the same feature sets. However, it appears more realistic that only parts of the functionality are used, as by the arguments above, and that the actual savings may therefore not be as big as a hypothetical calculation suggests. In summary, while the TCO can be slightly reduced it appears unlikely that big cost cuts can be expected.
Finally, we want to mention the increased risk of supplier lock-in (i.e. the inability to change supplier). We know already today that it is hard to modify or change security tools. It appears therefor likely that when using a suite, it becomes even harder to change the security tools. This as the migration risks increase massively when handling several security functions at once.
Apart from the economic aspects we also want to check the security effects. To make more than an educated guess about the security impacts we need to establish a reproducible assessment model. Our suggestion is that as modern security is risk driven we would like to start with investigating risks and then investigate security design principle to evaluate the security posture of suites. For the sake of readability, we cannot provide a full-scale analysis but only select a small selection of risks.
From a risk perspective the most prominent risk is related to software errors. All software has, unfortunately, errors. Security software is no exception to this. And we know from history that when security software fails it has usually significant implications. However, we also know that we normally built systems with several layers of defense and that while one layers fails that other layers are keeping us secure (enough). Normally other vendors’ products would not be affected from an error in one component. When using a suite this fail-safe feature is negatively impacted (to a certain extend) as the error is more likely to be present in the entire suite. How large the risk increase is, is difficult to describe in general. What we can see is that some (high security) organizations (e.g. NATO, Swedish defense, arms manufacturer, power plants.) already today require multi-vendor solutions for their most critical and/or most exposed system. Meaning that this appears to be already an establish risk factor for some.
A frequently mention risk for security is the appropriate selection of safeguards and their configuration. Suites short-circuit the selection process for safeguards, at least to a certain extent, as they come with many security safeguards as a package. While theoretically more security safeguards should imply more security there may be some risk associated. As already mentioned there are some effects on the maintenance efforts. Furthermore, the increased functionality necessarily implies an increased publicly known attack surface. If all functionality is used this is perfectly acceptable. However, for unused functionality this implies a risk. Secondly, those additional security safeguards must be appropriately configured for the organizational context. Relying purely on the supplier’s default configuration is likely to be insufficient as the supplier needs to have the least common denominator which usually implies a low security level. This requires competence and effort and creates a risk for errors as we know that misconfiguration contributes significantly to security breaches. To summarize, while it is generically hard to assess what more safeguards, most useful but some borderline, imply we can certainly deduce that uncertainty and complexity is likely to increase. Both will, as we know anectodical and scientifically, increases the security risk.
A prolongation of the above risk with more safeguards concerns the handling of security alarms. While security safeguards can delay attacks, they will not be able to stop them. Intervention is usually needed to react to attacks and requires a certain capability at the organization. On the positive side this allows for more sophisticated detection capabilities when using an automated analysis tools such as a SIEM (security incident and event management). However, this also leads to increased workload and may make it harder to find the relevant attacks. To summarize we find that if handled correctly more alarms may allow for better security but if handled incorrectly, which is unfortunately not unlikely, the risk increase. This due to acapability overstretch and drowning in false positives which in turn lead to decreased security.
A final risk we want to observe relates to the supplier. In recent times we have heard on several occasions that some suppliers have alleged cooperation with their national security agency. Although this may seem remote for a given supplier it should be considered in conjunction the more extensive data exposure (a supplier that is at more spots has more opportunities to create a more complete picture) as an increased risk. In other words – suites are of higher interest for adversaries. Obviously the relevance depends on the organization and its data.
We shall now move on to security design consideration. We use the well establish security design principles by Salzer and Schröder. These eight (8) principles provide guidance for security since many years. In our analysis below we find one adherence, five indifferences and two non-adherences.
On the positive side we can argue that psychological acceptability is likely to improve. This is an important factor as we have learned over time that usability is extremely critical for successful security functionality.
Next, we look at the least common mechanism principle. It suggests that a mechanism should not be “common to more than one user and depended on by all users”. Suites introduce mechanisms that clearly violate this concept as they depend at least on the same management systems and share some common functionality. As argued above a failure in such a component may be risky.
In respect to economy of mechanisms, saying to “keep the design as simple and small as possible”, we find that suites necessarily add complexity exponentially as more components and more interactions exist. Especially interesting to note is that if we consider the manageability issues mentioned above several mechanisms may not even be used and therefor introduce unnecessary complexity.
Although it always hard to make definitive conclusion from such an analysis the above suggests that it is more likely that a negative effect on security occurs rather than a positive.
In summary we find that while there are some arguments for security suites it appears that the expectable gains, while being possibly significant, are more likely to be moderate with an increase in security risk.
Our suggested conclusion is instead focus on getting the existing security tool landscape to interoperate more instead of hoping for some magic effect by a suite. To cope with the challenges, it appears reasonable to let experts handle the problems and source the security tools as a service. When opting for managed security services an important requirement should then be that supplier ensure interoperability between her own security services, the customers current security tools and the security solutions of relevant market players such as cloud suppliers and other security service suppliers. It is also crucial to ensure that the supplier shows capabilities in managing and optimizing the interactions to gain benefit from broad data feeds and artificial intelligence. We are convinced that such an approach is more promising to improve the security posture.
A short waiver
We want to clarify that this analysis assumes that there is a choice between various security tools and a suite. For actors which do not have coverage with their security tools today any option, including a suite, that provides such coverages is preferable. Simply said, something is always better than nothing.