Traffic laws are actually quite simple: You stop on a red light, honor the speed limit, and, of course, do not enter a one-way from the opposite end or park in a restricted area. Despite all the individuals participating in the daily traffic, the aforementioned rules usually work out quite good. Basically, because everybody knows about them and more or less adheres to them.
It seems quite obvious that bending the rules would not exactly be a smart thing to do during your driving exam. But after passing it? When driving through the city the other day all of a sudden everybody was slowing down for no apparent reason. Sure enough, a "flash" later some guy not paying attention scored himself a rather expensive photo – for speeding within city limits.
As it seems, merely having rules is not enough. There has to be someone to enforce them. And to enforce the rules, someone has to go patrolling. What seems to be so obvious for road traffic and its rules seems to be less obvious for many web developers. They tend to slack on defining (and monitoring) what is happening at the application level as well as the infrastructure level of their application. It is not enough to run a default install of your operating system of choice, add whatever services you need, and hope for the best. Considering the amount of money as well as damage to reputation, either directly due to fraud and abuse or indirectly by time lost to recover a hacked system or software, the "let's hope for the best" approach is of arguable quality. And we are not even considering general bugs here.
Before you can implement any access rules and define means to enforce them, you need to consider which services you actually need, how they are supposed to communicate, and with what permissions you want them to operate.
Hardening the systems (which, among other things, means removing unneeded services that come with a default installation or enforcing security rules such as limiting shell access to a certain set of IP addresses and users) is the first thing to do once the base system has been installed. This is a prerequisite for a secure environment.
Given the fact there is no such thing as 100% in security on the other hand, it is vital to define what the risks are and what a failure in enforcing any of the aforementioned rules might result in. The infrastructure you are going to use or are already using is likely to be under constant attack. Either by manual attempts to hack into the system or by automated scripts and bots that are always looking for new victims. The housing location, for instance, and the type of uplink for your server might be as important as the operating system and other software components as well as the versions in use, or the hardware platform the whole thing is based on.
Thinking about the uplink and location for the server might not seem relevant to security at first glance. But is yet another key factor in the broader picture: No matter how much time and money you spent on securing the services reachable via remote connections on the software level, all these efforts are for naught if there is no security protocol for physical access to the machine in question. Why would a dedicated attacker try to hack into your well protected database server when it's so much easier to simply steal the physical machine – or the latest backup tape?
There is also no point in securing only one – possibly prominent – system while leaving other parts of the infrastructure unprotected, as I have seen during an audit a while back: Imagine a web server which is a protected by an application level firewall, only allowing valid HTTP traffic, hosted on a sealed box making it virtually impossible to hack it. But the database was running on an unprotected third-party machine, open for everyone to connect to. Even though that was originally only planned for development purposes, there was now no need for an attacker to hack his way through the firewall to gather all the data he might need.
But how can you tell if someone is actually trying to break in? Pretty much exactly as the police does for road traffic: with speed checks and by patrolling. A properly configured firewall will show as well as inhibit any unauthorized communication within the network and all you need to do is monitor the vital signs of your infrastructure. Apart from network traffic that includes operating system level details such as CPU load and memory usage, continues with gathering statistical data to tell expected traffic peaks from attacks, and ends with analyzing logfiles for unusual and potentially problematic warnings.