Part 1 of 15: Server Application Hardening
What Is It?
Servers exist to “serve” applications, which is probably why they have the name in the first place. What those applications are can be, well, anything. They can be internet-facing web servers, content management systems, core network servers such as DNS, DHCP, and Active Directory, and critical systems such as SQL servers. Hardening these applications really isn’t optional and you need to defend against malicious data access, theft, exposure, corruption and loss.
For the record, this strategy needs to be considered in the context of internal as well as external threats. The numbers and statistics vary but the common thread is that most of the incidents originate from an internal source. That internal source, however, is subjective. It can be accidental or deliberate, by a well-intentioned or disgruntled insider, but can also come from “outsiders” that have gained access through an unsecured system (might want to check that boardroom PC without a password).
This is not to say, however, that you need to be paranoid and distrust all internal users and systems. You should all be on the same side, but things can and do happen, accidental or otherwise. Some users will push the limits in the name of getting their work done, and others are just curious. Unless you have a tight physical security posture, it’s hard to stay on top of who is where and when, and what they are doing. In larger organisation, there is a good chance that not everyone knows everyone else or why they are there.
It’s best to just harden server applications using the principal of least privilege, bearing in mind that functionality must be balanced with security. If you can’t use the systems, you may be doing the job of the hackers for them!
Where Do I Start?
A current inventory of applications is a must. I know I’ve said this over and over, but you need one for so many elements of these 37 strategies, and server application hardening is no different. It is hard to secure applications when you don’t know which ones you have. This also holds true for your network services such as DNS (and please don’t tell me you still use WINS!).
After you have an inventory, the next question I’ll ask is if you have already performed application hardening and Operating System Hardening. If not, then I’d suggest doing these next and I’ve covered them in previous articles. I’m happy to link you directly to them if you like, just ask me any time.
You’re probably asking how Server Application Hardening is different than the other previously-discussed hardening. Fair point. Application and Operating System hardening should apply more to the App or the OS in their own context. Think of disabling unused services, current stable versions, and vendor best practices on applications and applying patches, using current versions, disabling unused services, account management, and many more for the operating systems. In our case, we’re more focused on the interaction with the applications both from and end-user point of view and from a server to server point of view. It’s all about keeping that traffic clean and secure.
In other words, think of it like road maintenance and policing. Just because there are is a route between two destinations and both destinations are well maintained does not mean the road itself or the traffic on it is of the same calibre.
Once you get a grip on what applications you have, figure out how they interact and what kinds of traffic they do and don’t use. Even a hardened application can be vulnerable if it handles the wrong kind of traffic. Web applications seem to be at the forefront here, so even if you have locked down your firewall and hardened the server to only accept HTTPS, we need to think about the quality of that HTTPS traffic itself, and that applied to both ends. It takes two to tango, as they say!
How do I make It Work?
Depending on the server applications, there are several ways to approach this. Since I think Web Applications and Content Management Systems (which may or not be related, depending on the environment) are probably the pointy end of this strategy, I’d suggest starting there. While not completely on-topic, I must ask, do you have a Web Application Firewall (WAF)? Maybe pencil this one in for a future discussion if you don’t or consider a health check of your WAF if you do. It is the applications we’re trying to protect, after all.
You could consider a vulnerability assessment against your servers and their applications and that can yield some very eye-opening results, especially if you factor in some protocol and traffic analysis. One of my favourite go-to’s in this area is OWASP – The Open Web Application Security Project. Some of you are familiar with the OWASP Top-10, but the OWASP project provides a ton of great information, resources, and tools to help you with your server application hardening.
OWASP guidance helps to mitigate these web application vulnerabilities such as SQL injection, and provides great details on code review, data validation / sanitisation, user / session management, data protection (in transit, in use, and in storage), error handling, authentication, and of course logging and auditing. I won’t go into in detail here, but please do yourself a favour and have a look. Better still, get the right people involved to help you out….it can get overwhelming very quickly. Even things such as versions of TLS, deprecated cipher suites, and legacy applications that only want to use older technologies (we should all be off SHA1 by now) can get you bogged down without a little help.
With your inventory, an understanding of your traffic, and some guidance from sources such as OWASP, you should be ready to begin hardening your server applications.
Pitfalls?
Often when hardening, we end up disabling items such as legacy cryptographic protocols that “break” our applications. Understanding the dependencies of the applications and data is critical. Certificates can cause all kinds of headaches when you attempt to define input validation and the applications will only accept limited capabilities like key length. The things that can go wrong are many, so proper planning, testing, and execution are very important to success. Don’t make changes for the sake of changes unless you fully understand what you are changing and why….don’t do the hackers job for them.
Ghosts in the Machine?
Sometimes the characteristics of the applications themselves limit to what extent they can be hardened. Applications can be developed with function in mind and security ends up a long way down the priority list. Evaluate the value of the application and the value of the data it handles. If you cannot harden the application sufficiently to protect the data, or mitigate the risk through your defence-in-depth approach, it may be time to replace the application with something that delivers adequate security. Always plan for some systems to be uncooperative.
Anything Missing?
Change control. Be sure to document what you are doing, why, and what you are doing it to. Ensure you have the stakeholders involved lest you break their toys! Get approval to make the changes, but when it comes to these types of changes, always have a roll-back or contingency plan of some sort. Nobody wants to be trapped frantically trying to get a system up when the first arrivals of the morning want to get on with their day.
Disclaimer: The thoughts and opinions presented on this blog are my own and not those of any associated third party. The content is provided for general information, educational, and entertainment purposes and does not constitute legal advice or recommendations; it must not be relied upon as such. Appropriate legal advice should be obtained in actual situations. All images, unless otherwise credited, are licensed through ShutterStock
information, educational, and entertainment purposes and does not constitute legal advice or recommendations; it must not be relied upon as such. Appropriate legal advice should be obtained in actual situations. All images, unless otherwise credited, are licensed through ShutterStock