Does your customer have a requirement for monitoring servers or for Intrusion Detection? Are they asking about Real-time File Integrity Monitoring (FIM)? Have they recently failed an IT compliance or regulatory audit?
Usually a request to monitor server activity, or user and administrative access to a server, is driven by a few business needs.
It could be a Compliance or Audit requirement, it could be to pass information to a Security Incident and Event Management tool (SIEM) or Security Operations Centre (SOC) team, but more typically it is deemed to be good IT behaviour to keep an eye on how your servers are being used on a daily basis.
Let’s think about the rationale for those points.
Firstly if you are being audited, or someone in a risk and compliance role is scrutinising your environment, the process of generating incidents which are then analysed and potentially acted upon is actually the housekeeping role that many engineers in IT operations and Security teams perform on a daily basis. It is time consuming, costly but seen as necessary to keep your house in order.
Maybe you have a SOC team or utilise an SIEM within your environment, collecting information about user activity, be it malicious or authorised, can be extremely valuable when collating incident information and forensically understanding events that may represent a breach of some kind. Host Intrusion Detection products or File Integrity monitoring tools collect reams of this information to pass to these expensively skilled teams or systems for further analysis.
And lastly, it is deemed good practise to monitor all servers for usage and configuration changes, not just those in exposed environments and locations (e.g. DMZ servers, remote branch offices), as security comes from understanding the bigger picture in relation to where problems may lie in your estate. Visibility of all possible risks is one of the key instruments to help you determine security posture within an organisation.
So far, these business needs have described the requirement for multiple teams or employees in different roles, all working towards the same aim of having a reliable and secure IT estate. But they have not necessarily prevented an attack.
The concept of monitoring is sometimes sold as one of the easiest processes to implement within a company to improve your Risk Posture, almost a 'tick-box' exercise in some cases. However this process in reality may only result in one thing, namely that it can tell you when you may have been hacked. Monitoring does not offer either Prevention or Protection against an attack. Monitoring is just one of the processes required within an estate to be (re)actively informed of security risks.
But does your CISO, Auditor or Compliance officer really just want to understand that the various IT teams are monitoring a situation? Surely they would be more interested in a more permanent and proactive solution to stop the attacks in the first place? I believe they would, especially if they understood that the total cost of ownership of a preventative solution could actually be less than a monitoring one. I am talking about HIPS- Host Intrusion Prevention.
Firstly let's dispel some myths about HIPS that are usually mentioned by vendors selling Monitoring solutions;
It is a nightmare to configure!!- Not true, built in policy templates speed up deployment, and require no skills such as advanced scripting to use full functionality.
It requires constant attention and policy tweaking!!- Sorry, wrong again. Policies can be set and forget, as they relate to the role of the server rather than a platform or application release.
Security policies have to be switched off or disabled to update servers. Again-a misnomer, software deployment and management tools can be allowed to patch and update target machines, yet at the same time the policy is 100% active, and denying Administrators the ability to accidentally patch outside the change control window. Some HIPS products offer security to such a deep level that patching can actually be reduced to once a year.
It only works on current Operating Systems and kernels- not true, they can support even legacy operating systems such as Windows NT/XP/ RHEL4.
So given that HIPS is a proactive approach to server security, has minimal management overhead, is simple to configure, ensures greater server uptime and reliability and even allows the patching mechanisms to be secured, why wouldn’t you look at this instead of monitoring?
I will give you one last thing to think about. IDS and Real-time FIM products create sometimes hundreds if not thousands of events per day per server. Unbelievably, this is sometimes described as a Good Thing. In reality, what you actually want is a product that has told you the key thing- I have prevented your server from being attacked, or your data from being stolen. Why do you have to wade through masses of data via monitoring, when a Prevention product only reports something that is suspicious? Which would your SOC or SIEM product prefer I wonder?
With HIPS protecting a server, you do not need to monitor every action or log entry to detect incidents as you are already blocking the possibility of attack. Therefore events per server per day can be kept to the absolute but necessary minimum. Sorting the Wheat from the Chaff you might say.
In summary, I am referring of course to Symantec’s Critical System Protection product, which handily includes not only HIPS and HIDS, but Real-time FIM too.
So the balance of security and monitoring can be struck to not only keep the hackers away and the auditors happy, but more importantly keep your business out of the newspapers.
http://www.symantec.com/critical-system-protection
