Axiom: The only truth that is perfect about security is that there is no such thing AS perfect security.
That said, if you can get your technology providers to say, “Yes” to the following in relation to your servers, you’re pretty close to as good as you can get:
1. The server is private and hidden from the world; it is not known to you to exist until someone explicitly tells you it exists.
2. The server is authentication-only access; all access not explicitly given is denied.
3. The server is running transportation socket layer security; all connections are secured to current minimum standard (RFC 6176).
4. All connections coming to the server are encrypted via site-to-site VPN.
5. There is a logging and data retention policy in place that is suitable for the accounting, legal, reporting, and tax needs of the corporation.
What this means is that you have secured the server to the fullest extent humanly possible; particularly that you have created a viable depth of defense strategy that sets the bar for malicious success so much higher than the potential reward of access (from the perpetrators view) that incentive for the attempt can be reasonably be judged as eliminated. More importantly, when this judgment is incorrect, there are layers of defense in place, all of which may be (should be) monitored, so you have depth of awareness as well.
At the end of the day, if what you’re doing strictly meets the above, you’re as good as you can get for server security (adding only that you regularly challenge and re-examine your assumptions on it all; even the mall has a midnight walker of its halls.)
If you can say that all non-VPN connections are rejected, the next step in “best possible” security practice is called TCP Stealth. This concept is essentially laying down the following additional rules for if and how the server will respond to unexpected or malformed requests:
1. All requests not explicitly expected are ignored.
2. All requests ignored receive no response.
3. All requests receiving no response are logged.
Many technology professionals groan at that last one, “That is going to create monsterous logs!” To which I politely respond, “That’s what generational backup and archive schemes are for; real time, near real time, near line, off line. You cannot report on trends over time if you’re not tracking attempts over time.”
They usually follow up with, “But you only really need to log authentication attempts.” To which I even more gently respond, “You cannot know in advance what piece of data is going to deliver insight three to five years from now… you cannot report on data you do not have… you can eliminate what you don’t need over time, but that’s actually more work and maintenance than just keeping it all and leaving it to the algorithms for management.”
This is of course, a very high level overview of the matter; there will be strategic business and even legal considerations that sway a business more heavily on some aspects of this, less on others. But, in general, the above is a good starting place for companies who can’t afford to learn the hard way. Personally, I’m surprised any company would prefer to bet on never having to learn the hard way, especially given the ongoing plague of intrusions and the ramifications of their successes.
But that’s another topic, for another article.
[starbox]