Hidden security costs that can make a project fail

Check Point entdeckt Fuzzing-Schwachstellen in Microsoft Office

Orca Security uncovers IT Security Cost Traps

In many companies, decision-makers ask themselves the question of how likely it is that a particular provider will improve their digital security. Almost any solution from a provider will make a company safer, some maybe only slightly, some maybe will bring security forward with huge leaps.

The biggest challenge for a CISO is not to sort out the few providers who present “miracle cures”. It’s about identifying those solutions that might make the company a little safer, but whose hidden costs are too high. According to Orca Security’s experience, these hidden costs can not only cause the implementation to fail, but probably even throw the entire security program off track.


A large number of security products rely on the installation of an agent: a small piece of software that must be installed on each system to ensure the protection of this system. This sounds insignificant, even trivial, but it can be anything but that.
If there is a completely homogeneous environment, i.e. every system is identical to every other system, then the integration of agents is probably not a big problem. However, most environments are more heterogeneous. Windows servers are side by side with Linux servers and the Linux servers are available in a whole range of different distributions, while applications are created in a wide variety of environments.

An agent must be able to operate safely in each and every one of these environments to ensure full coverage. If something goes wrong during the deployment phase, the agent will be held responsible, rightly or wrongly. Then it will be deactivated as part of the response to the incident, and companies will have to argue after the incident that it will be reactivated.

Agents also consume resources on the machine. When asked about the performance overhead, security vendors probably give a vague answer like “Oh, not very much, just a few percent”. “A few percent of what?“, however, the question arises. Similarly, agents are tested on idle systems, and CPU usage is measured. However, the decisive factor is often how the agent interacts with the system during peak load. Most corporate users probably know a horror story about a laptop that stopped them because of an antivirus scan when they were about to prepare an important presentation. Imagine if the same thing had happened to the web server during a Black Friday sale.

Widespread agents are also a vector for attacks on the supply chain. An example of this is the incident at Solarwinds, where an IT management agent installed everywhere opened a way to compromise. The security risks of your own tools are a cost factor that most security teams do not take into account, but which should be included in every evaluation.

Incomprehensible warnings

Anyone who has naively used a new security product to find problems in their environment has been confronted with a flood of incomprehensible warning messages. Why is it important for a machine to respond to ICMP timestamp requests? In fact, this does not matter.

The challenge in defining alerts in security products is that the incentives between the provider and the buyer are completely unbalanced. The provider wants to avoid the dreaded false-negative alerts that are actually important, while the buyer focuses on the opposite problem and tries to avoid meaningless alerts that do not bring any actionable benefit.

It is very difficult to define the value of a warning in advance. Sometimes it is contextual. Perhaps an attacker can read all the files on a web server. Is that a problem? Possibly already, because this server could have access data to the production database. But it could also be less interesting if the server only manages a website with brochures.

Many security teams are not even the actual users of the alerts. The alerts are forwarded to the business department, and the security team is often ignored. Many companies get into an awkward situation where the Devops team demands prioritization while the security team demands action. Both teams are right, but the valuable security work is not done.

The essence of the problem lies in the discrepancy between the target audience for which the product was implicitly developed and the target audience that actually uses the product. On the one hand, the target group includes a technically experienced security architect or security operator with excellent project management skills, and on the other hand, a young security analyst or project manager whose skills are increasing by leaps and bounds every day. The ability of a deep security professional to prioritize alerts relatively quickly would be handy, but that’s an expensive skill to use for thousands of alerts.

Unfortunately, most tools don’t have the architectural or organizational context to make an initial prioritization and help analysts make positive security changes quickly.

Complex implementations and organizational friction losses

Whenever a complex project has to be introduced in several companies, no company really wants to be the first, because it bears the burden of integration problems. Probably, the introduction will also have to be repeated, because over time the company has learned lessons about a better implementation than the one first proposed.
Most project managers have already had this experience: colleagues who want to see someone else’s success before they do the bare minimum themselves, surprising obstacles that derail a project that was already progressing very slowly anyway. If a project progresses too slowly for too long, it is implicitly “de-prioritized”. If it hasn’t been completed in the last three years, why is it important enough now to push it through this year?

The costs for organizational coordination increase supralinearly with the technical costs: the more work a team actually has to do, the greater the effort for the coordination of this work. If a company has too much work, it has to push back large or nebulously defined workloads.

Security products as storekeepers

According to Orca Security’s experience, many security products end up as storekeepers or partial implementations because one or more of these pitfalls occurred during their introduction. The managers may not even realize that the projects have been limited or not successful at all, because they are still paying the provider for a solution that is not introduced or ignored. Therefore, in any case, it is necessary to pay attention to hidden costs in a timely manner.

Outsourced Software Development Services | Dedicated Software Development Team

Ready to see us in action:

More To Explore

Enable registration in settings - general
Have any project in mind?

Contact us: