Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Corrective Actions
Disinformation can be a tool for cyberterrorists to sow confusion. Here's how to harden your network against such attempts.
The filesystems that web servers use for static content should be read-only. Having production servers that are read-only makes them very difficult to crack or modify. Static content should be managed from staging/test servers before it's moved into production. This also provides for fast recovery in the event of a disaster, or if a hard failure is caused on the production server by a malicious cracker. Databases should be inside a separate demilitarized zone (DMZ) and managed with message passing and/or secured authentication schemes that can be authenticated prior to a database action being performed.
All users of these systems should be authenticated using a good system such as CRYPTOCard, SecurID, or public key infrastructure (PKI) to prevent crackers from attempting dictionary attacks on systems and compromising secured server areas, or getting access to sensitive tools that may aid them in making changes to dynamic and/or static content. (A dictionary attack is a special type of password attack. It attempts to "reverse engineer" users passwords on a given machine, running through all possible spellings to find passwords.)
Once again we must stress the importance of having good security policies that include regular audits and reviews of patches and updates of all running software. Verify that web servers are secured by best practices and regularly review them to make sure that they match the security policy as it evolves (or as best practices evolve) to keep systems secure. Remember, firewalls are not enough to protect all your assets. Virus scanners, intrusion-detection systems, and vigilant administrators are the first line of defense.
Create a hardened DMZ with intrusion detection outside the firewall, designed to limit just how far a cracker can go in the event that a system within the DMZ is compromised. Plan the design of the DMZ with this worst-case scenario in mind.
If you create applications in-house or use applications from third-party vendors, conduct periodic code reviews to prevent common exploits such as buffer overflows from exposing your servers. Buffer overflow attacks (also known as "stack smashing") have been around for a very long time. Good programming practices need to be passed on to junior programmers and practiced by all. Know your code, and on occasion take the time to test it with known techniques to see whether you need to deal with vulnerabilities.
Most important of all, don't let frugality push you into making bad decisions. Whenever possible, try to segregate applications onto separate servers and not put them on a single server to save money. Not only do individual applications have issues, but the interactions of these applications when deployed in multiple configurations may present issues that need to be addressed.
Adhering to these corrective actions is time well spent and the payoff is stronger security across your network.