Why and How You Should Harden Your Systems

Written by

So, you’ve been hacked. Maybe your system was modified for malicious reasons, your information was stolen, or your website was defaced. All of these scenarios cause panic. The effects of a successful breach can result in loss of revenue, customer trust, shareholder faith, sensitive data, and even your business. 

Putting protective measures in place will strengthen your security posture. This process can be difficult, but there are a ton of tools and resources to help you.

Start with a security plan
Building a security plan is very involved, and it should encompass a broad range of protections for your business. You should review your plans annually. They will also be validated during audits. This list is not exhaustive, but most security plans include:

Physical controls: building alarms, fire suppression in data center, cameras, and key access. 
Network controls: hardware (routers, switches, firewalls, concentrators, threat analyzers), network drawings for boundary and segmentation visualization, and DMZ/exposed zone documentation. 
Application controls: the patching standards, operating systems used, approved application list, and encryption used.
Database controls: approved databases, schema documentation, and application to database dependency diagrams.
Disaster recovery plans: runbooks for recovery, backup schedules, off-site points of contact for media, call trees for support personnel, and cold/warm/hot site activation.
Business continuity plans: sister site/co-working site activation, and communication plans to employees.

Once policies are in place, it’s time to begin a security assessment. Building a detailed security assessment is outside the scope of this article, but you can find guidance online.

Once you’ve assessed your environment, pick the most attractive targets to harden first. Your internal network database may have the most sensitive data, but if your border load balancer is wide open and unpatched, it’ll become the prime target.

So, how does all of this hardening happen? If you don’t have people with security training in-house, you should invest in training them or seek external companies to assist in the process. However, be aware that if you pay for external help, it’ll become an ongoing cost if you don’t bring the talent in-house and maintain the security posture.

Use industry standard guides 
So now that you’ve invested in security talent, what are that best practices and standards guiding their planning for hardening your systems?

There are plenty of free resources available to help you understand and guide your hardening process: a thorough (and rigid) library of hardening documentation is managed by a federal agency called the Defense Information Systems Agency (DISA). Their guides focus on strict hardening. 

DISA publishes and maintains Security Technical Implementation Guides, or STIGs. Here you can find a catalog of operating system STIGs and the full index of available STIGs.

Another widely accepted authority in the private and public sectors is the National Institute for Standards and Technology (NIST). NIST provides guidance on multiple technologies and is often the gold standard on which many other agencies base their own practices and documentation.

Documentation is great, tools are better
The guides are great for in-depth information about the “what” (is being hardened), the “why” (it should be hardened), the “how” (to harden it), the individual criticality of the vulnerability, etc., but the documentation doesn’t tell you whether you’re vulnerable or compliant.

Tools can do that. Tools are able to scan your entire environment, build reports, give you a means to benchmark, and even remediate vulnerabilities for you. However, a word of caution: do not auto-remediate vulnerabilities in a production environment without knowing what it’ll do, and don’t do it until you’ve tested it.

If you don’t have integration tests (e.g., Serverspec, Testkitchen, Beaker, Selenium, etc.), you should always perform regression testing to ensure that introduced hardening doesn’t prevent required functionality.

External auditors are your friends 
Believe it or not, whether you hire a friendly, external agency to audit or you are audited for regulatory control (e.g., HIPAA, SOC, and PCI DSS), the auditors are coming to validate that you are, in fact, operating in a secure and compliant fashion.

This validation can be in the form of penetration testing, vulnerability scanning, paperwork/artifact validations, or a combination of these efforts.

It’s much better to have the auditors discover findings that you can resolve than it is to have an attacker exploit them.

Operating system hardening
There are many vulnerability scanning and penetration testing tools, but it is up to you to make sure that you install all security-related patches. Every missed security vulnerability patch will be flagged by scanners as “high” or “critical.” Nearly all Microsoft Windows security advisories are flagged as critical.

Remember, the worst part is not that you’ll have all the findings in your audit report — it’s that an attacker can scan your environment, find that weakness, and exploit it on all of your systems. Don’t give them the easy win; install all security patches.

Whether you have a fully integrated testing environment and CI/CD pipeline (ideal) or a fully manual and person-driven regression testing environment (least ideal), you should follow the same hardening steps: scan, remediate, test, scan, and automate.

Applications need armor, too!
Your operating systems and boundaries are strong, but if your external-facing applications were built with weak security practices, hackers can pillage at will.

Every application architect should review the Open Web Application Security Project’s (OWASP) Top 10 security risks and remove the vulnerabilities from their stack. OWASP publishes annual lists and provides ongoing guidance for securing applications. Expect pen testers to scan your applications for the OWASP Top 10.

Hardening is a highly complicated process. It needs to start with a plan, the guidance, the skills, and the tools to bring your environment into compliance. Once you’ve built the processes to test, implement, and maintain the security posture, you’ll consider recent announcements like Spectre and Meltdown to be just another set of planned remediations.

You should make hardening part of the process of operating your business, not an additional box to be checked for audits. Make 2018 the year to tighten your security belt and squeeze out the attackers.

What’s hot on Infosecurity Magazine?