Server Application Hardening, unlike other system centric hardening, focuses on using the application rather than the application itself. Server to server and client to server transactions must remain secure. Like roadworks and policing, a route between destinations that are both secure does not mean the route itself is. Have a current application inventory and know what systems are used, how they are used, and the traffic they do and do not accept. Be wary of legacy cryptographic elements and dependent legacy systems. Consider both internal and external transactions and evaluate a Web Application Firewall solution. Undertake vulnerability assessments against applications.
Incident detection and response must be as important to your enterprise as the focus on prevention. Many organisations spend too much time and money on the “Before” of a security incident but are unable to respond when (not if) a critical incident occurs. Create, test, and implement an incident response plan. Understand your risk profile, assets, and resources. Acquire the technology and resources to accurately discover incidents. Ensure you have the ability to respond in a timely manner and with conviction. Ensure recovery after the incident to minimise disruption. Above all else, test your plan in anger at least annually.
Your passwords are keys to the kingdom and it only makes sense to protect them. Rather than worry about what constitutes a secure password, focus on where they are stored and used. Operating systems must securely encrypt and store passwords for the accounts they hold. Network devices must have encrypted passwords unable to be extracted or decrypted. Change account, system, and master passwords regularly. Use a password vault. Do not write down passwords if avoidable. Do not share login credentials. Avoid using generic accounts. Ensure you have a current policy that governs passwords and review it regularly. Undertake awareness training.
Network segmentation is not just about physical and logical separation of your network elements, but also accounts, permissions, applications, files, and services that your enterprise relies on daily. Begin with a current assessment of your environment. Get the right people using the right tools to help map it out. Ask why X talks to Y, if it should, and how to do so securely. Update your diagrams and documentation, keeping them dynamic to match the evolving infrastructure. Separating the elements from each other can mitigate the amount of damage caused deliberately or accidentally. Test all configurations and use change controls.
Local administrator accounts on computers wield considerable power and must be limited. It is common for domain users to have local administrator rights or access to the local administrator account itself. It is common to use the same local administrator password across the enterprise. To protect the organisation, disable the local administrator accounts if possible or at the very least change the default name, use unique, secure passwords, and restrict access unless necessary. Assign separate administrator accounts to users if needed for temporary use and enable auditing on all privileged accounts. Underpin this with management supported policy. Remember non-windows systems.
Generic exploit mitigation is not so much about vulnerabilities but rather methods used to exploit them. Patching vulnerabilities is important, but consider mitigations for the vulnerabilities not so easily addressed. By limiting where programs can execute, randomising the location of allowed programs, and refining your system security settings, you can augment overall system hardening. Think of it as a lock that could be picked, but preventing access to the lock in the first place. Upgrade older platforms to newer versions that already have these mitigations built in. Deploy baseline images already hardened. Defence in depth extends to within individual systems.
Proxies reside between clients and servers, acting as an intermediary for transactions. Proxies enable a number of roles, from filtering and monitoring to load balancing and anonymising. The question is not IF you need a proxy, but rather what kind of proxy is needed? It is important to choose a suitable, scalable proxy and to design, configure, and manage it correctly. Otherwise, it creates more problems than solved. Forward proxies control outbound connections while reverse proxies manage inbound connections such as load balancing a server farm. Even your firewall with NAT is a proxy, working at a lower network layer.