Am I secure?

As part of my work at Sitewards, I will do a casual review of some of the data yielded as a result of instrumenting the services we build…

As part of my work at Sitewards, I will do a casual review of some of the data yielded as a result of instrumenting the services we build. One evening, I spotted an anomaly — specifically, the CPU was nearing 100% utilization for extended periods of time. Now, while it was not affecting any metrics that indicated the service was suffering issues I was curious, and thus investigated further. I found that another system was marking large number of unusual requests against this system.

Now, to cut the suspense short, this turned out to be “fine”. That system in particular was scheduled for migration, and the team doing the migration was abusing a service that generates PDFs to save a copy of all PDFs, and that’s an inherently expensive operation. Weird, but whatever.

However, in the back and fourth communication with the service owner we got a bit confused, and something like the following came out:

“That looks like hackers! Are we secure?”

You are as secure as you are healthy. That is, you’re healthy until you’re not.

It’s an interesting question. Being “secure” is a little like being healthy.

Health

From another life as a personal trainer, I remember “healthy” people were people who would exercise, eat the appropriate foods at the appropriate levels and set aside time to practice their mental self-care.

However, even those people sometimes got sick. A particularly strong bout of the flu, or simply an odd circumstance that required them to push beyond what their body was capable — that’s it, you’re down for a little while.

So, being “healthy” is the absence of being sick.

Security

In the same way, we take pride in modifying our systems to be resilient to hackers. Just as those who practice to stay healthy, we practice to stay secure — keeping software up to date, limiting the ability of one component to interact with another, restricting components from being accessed at all. We continually review our security posture, and determine if there are some improvements that can be made.

However, sometimes even we get this wrong. My understanding is that hackers tend to violate assumptions that we have made, exploiting some consideration that we had failed to grasp for access to resources they should not.

Being “Secure” is the absence of being hacked.

Prevention is better than a cure

Considered against health, it seems obvious that we should try to limit our risks of getting sick. Reducing smoking and alcohol consumption, getting some exercise each day, regularly checking in with our general practitioner. There are many mechanisms that we can implement that will help keep us in good health as long as possible.

It applies equally well to security. There are many ways to prepare against being hacked, and at Sitewards we are continually improving our security posture. We are following the general pattern of “instrument, review and improve” — adding additional tooling to our systems to understand them further, reviewing their use and modifying them to mitigate the risks that we can see as most likely affecting that system. We try and keep our customers secure as long as possible.

Like health, security is a cost-benefit analysis

I am no longer a personal trainer — as may be determined from this post, I now work as a programmer. This decision has negatively affected my health in some ways, but positively affected my health in others. On balance, it’s probably a net loss — I am a programmer because the trade off between health and the financial return of being a programmer suits me more.

Security is much the same. We make trade-offs, judging the potential risk of a security issue against the cost to implement the mitigation and the Likelihood of that issue being exposed. Though it would be nice to disallow team leaders from having access to services in production, it would (currently) make it extraordinarily difficult to do our jobs. Though it increases the risk of being hacked (though unauthorized of developer passwords) the risk is currently justified.

The balance is shifting

The question of security is becoming a progressively hotter topic as the consequences for a unauthorized access become far more significant. A combination of the GDPR (“General data protection regulation”), increased consumer awareness and attacker sophistication mean that more is required now to mitigate the risks of being broken into than in the past.

This means it’s inherently more expensive to operate a service that collects data (such as a shop system), but it also means the privacy of consumers and their personal data is held more carefully than ever before.

It’s neither a good, nor a bad thing — simply a reflection of the changing times that we’re in.

Determining security

When we suspect that we are becoming sick, we go and see a doctor who will run a series of tests on us to determine just how healthy we are.

The same is possible with security. There are various standards against which we can evaluate the service to determine if we are taking the appropriate preventative steps. Additionally, it is possible to hire people who will attempt to hack the site on our behalf (either through a bug bounty or by contracting a Pentesting company) and write a report showing if they were able to hack the system, as well as how the hacked it.

In Conclusion

The absolute answer “am I secure” will always be “no”, just as the absolute answer to “am I healthy” will also always be “no”. However there are steps that we can take to mitigate the risks that we see, as well as testing whether our assumptions about security hold true. So long as reasonable steps are taken to secure the data, you are unlikely to get hacked.

Thanks

• Antonius Koch for his review of the content, particularly how understandable it is.

• Cipriano Groenendal for his review of the content and grammar.