Linux Security: Auditing, Hardening and Compliance

How much system hardening should you do?

System Hardening

When it comes to Linux system hardening there is a lot to do. From the almost book-like CIS benchmarks to following best practices found all over the web. Recently someone new to the field of information security asked me a simple, yet important questions: how much system hardening should you be doing? When is it enough? Since there was no easy answer, I have written down my thoughts to help others in the future.

Time and Effort

To understand the value of system hardening, one should know that it is a matter of putting time and effort into it. Time is simple: you have to first recognize that there is something to improve and decide to invest time to do research. Then it is about finding the right resources to help during the system analysis and system hardening process. You should first know what you can improve and test if things are actually related to your environment. Then more time goes into making a decision on what defensive measures to use, test them, and finally implement them. And you might also do some monitoring afterward, or even solve issues caused by your actions. So there is a lot of time involved for sure.

When it comes to effort, that one depends on your skillset and tooling used. Regular readers of this blog might already know that you don’t have to check every setting by hand. Tools like Lynis provide a quick and extensive method to discover possible security gaps. What also helps is your own skillset to quicker make an estimation on what would, or would not, work in your environment. After all, security is a matter of security appetite. You decide how much risk you want to take.

The value of starting

Every beginning is difficult. With system hardening that is not different at all.Getting started somewhere is the key. For that reason, the Enterprise offering of Lynis provides a section called “Improvement Plan”. It searches through all the findings and provides you with some quick wins. Start with the simple things and make quick decisions. Nike’s slogan “Just Do It” is applicable here. Making small steps, like removing the greeting banner on Postfix. Why would you tell everyone that you are using Postfix? Read, understand, and implement that new banner that says “mydomain.com ESMTP”. You are now started with system hardening and slightly decreased the chance that the average Joe can discover what software components you are running.

Marathon versus Sprint

When we talk about information security, we should consider that we are running the marathon. There is no use in implementing security quick if you can’t keep up. It is better to craft a culture of continuous improvement. Become a little bit better (and more secure) every day. So considering that way of thinking, we can answer the question at the beginning of the article with: “never”. There is obviously some nuance to it.

The level of security should be high enough. If you don’t have enough of it, you will later discover the consequences (a possible break-in, data leaks, damage to company brand). Too much security will actually harm the business as well. When simple tasks become too complicated through all level of implemented measures, the business will slowly grind to a halt.

Knowing when to stop

Finding the right level of security does not just depend on your organization. If you are a bank, you know that trust is everything. So that means you will have to implement those measures that display trust and to some extent even can guarantee it. If you are any other business, then your security posture might be completely different compared to your competitors. That is fine, as long as you know your risks, threats, and vulnerabilities. Not just on business or financial risk, but also technical risks. Getting a clear picture will help you focus on the right things. That system that deals with credit card payments might need a lot more security measures than your developer system. Well, unless your intellectual property is stored on that machine, and contains even a higher value.

Vulnerability Management

One of the things I dislike from the information security field is vulnerability management. It has even become a business model, fed by fear, uncertainty, and doubt (FUD). Instead of helping people with the next step, many solutions work on presenting all the weaknesses. Sure, you have to measure something. The focus should be on the positive (implementing measures), not on the negative outcome. You would be surprised to find how many quick wins are not implemented, while these same companies invest lots of money in all kind of security hardware and software. What we need are tools that educate us, instead of just doing some magic. No tool can decide how much security you need. You are the smart person to make that decision for your system or organization.

Baselining and priorities

Setting priorities for system hardening is better than just setting fixed thresholds to your security posture. And yes, it helps when you have at least some baseline. This way you get the feeling of getting closer to the end goal. Priority setting in Lynis Enterprise we do by calculating system risks and ordering (from bad to good). While the number alone doesn’t say much, you can compare it with other systems. Users of the community version of Lynis know this as the Hardening Index. And it works! I’ve seen people battling who could get the highest score during workshops.

Security policy

If you truly want to say that you reached the right level of security, then it should be documented. Not in a text file on just a single system. It should be part of your security policy. You can even create a policy per operating system, stating the minimum required steps to be taken. This can be extended by requirements for each role a system has. You could use instructions like “All production systems should have no installed compiler installed unless required for business purposes. In such case, access to the compiler is only allowed to a particular process (or user) and documented.”

Conclusion

The answer to the simple question we started with really depends on your environment or organization. Still there are steps that every organization should take, like having a clear inventory of systems used and stored in a central database. The next level of knowledge to gain is the risks, threats, and vulnerabilities to those systems and the business.