The Relationship Between Performance and Security

The software landscape has undergone a profound transformation over the past two decades. In the past, a substantial portion of software was designed for local desktop use. However, today, the norm for computer users is to access web-based software services through a web browser.

With the prevalence of web-based software, the paradigm has changed. We, as users, have our data residing on someone else’s server. It mostly doesn’t matter how robust your computing device is, as everything happens on servers.

For a software developer, this shift signifies the emergence of large-scale, highly available web-based software that handles vast amounts of critical customer data. In this new era, performance and security are not just additional features but fundamental elements that must be considered during development.

Be Proactive About Security

Accenture published its State of Cybersecurity Resilience 2023, in which it mentioned that around 18% of its respondents are planning to enter cybersecurity later.

We found that, when it comes to embedding security controls, 18% of our survey respondents still deploy them after they’ve finalized a transformation effort — and that’s only if vulnerabilities are detected.

They continue to expand on the impact of such an oversight:

It could be a case of too little, too late. As a recent study found, the discovery of an error due to poor application security in an app's coding phase, instead of during initial planning, costs five times as much to fix —and that soars to 30 times the cost post-release.

While focusing on performance and security, we must be well aware of their relationship. That sense will help us make wise decisions and manage unintended consequences.

Friend or Foe?

When you try to improve either performance or security, you will most likely pay the price of the other. This is not a hard and fast rule, and it’s entirely possible that we can improve both simultaneously up to a specific limit. As an experienced software engineer, this is where you come into the picture: providing guidance and recommendations to the team and driving discussions on such nuances.

Think of a new web service you built. Users would have to log in to access some services. The firewall has zero rules and allows all traffic. This allows malicious actors to bring down your service using standard methods like Distributed Denial-of-Service attacks and injection attacks. When the load on the server is high, legitimate users cannot use the capabilities.

As we can see, both security and performance in this scenario are extremely low. If we add some sensible firewall rules, we could increase security by blocking some of the cheapest attacks and improve performance, such as the traffic latency of legitimate users.

Adding some firewall rules can improve the performance and usability. This expectation only holds true up to a certain limit.

The Balance

To make our service more secure, we could add more firewall rules to enhance the security and block some harder-to-block attacks. 

This is where we need to be careful. Making any improvements beyond a specific limit can become counterproductive. In practice, the law of diminishing returns is observed. The initial limited number of changes led to most security improvements, reinforcing the Pareto Principle.

When the probability of measuring a particular value of some quantity varies inversely as a power of that value, the quantity is said to follow a power law, also known variously as Zipf’s law or the Pareto distribution.

- Newman, M. (2005). Power laws, Pareto distributions and Zipf’s law. Contemporary Physics, 46(5), 323–351.

Steve Ballmer once published:

One really exciting thing we learned is how, among all these software bugs involved in the report, a relatively small proportion causes most of the errors…About 20 percent of the bugs causes 80 percent of all errors, and — this is stunning to me — 1 percent of bugs caused half of all errors.

Overzealousness Should Be Avoided

Let’s explore what can happen if we keep adding more firewall rules. We would now focus on the corner cases, where attacks use random permutations of requests to find an exploit. You realize they are trying to exploit known issues, but you have applied the security patches.

If you try to add more rules, which have to be more specialized, you may block another 5% of the malicious traffic, but the added overhead causes 5% additional latency for your users. Is this worth the overhead?

Consider this tidbit:

10 years ago, Amazon found that every 100ms of latency cost them 1% in sales. 

As we can see, adding more security features could reduce your company’s revenue. To make matters even more complex, this correlation might not exist for every company, and even if the correlation exists, there might be no causation. As a software engineer, it is your job to understand the broader impact your changes may introduce. 

Conclusion: Use Your Best Judgment

Due to the nature of free markets, businesses have fixed budgets and limited time. Our goals should be to maximize returns and optimize time and budget. The goal is to strike a delicate balance. This fine balance is highly subjective and depends a lot on the kind of customers a business is catering to and the level of competition.

As a senior or staff software engineer, you are responsible for contacting the teams and individuals affected by your change. In the above example, where adding more firewall rules can impact latency and revenue, it is a good idea to loop in the security, customer experience, and marketing teams.