Patching pain? We can fix that for you.
It’s a painful topic for most IT professionals, seen as the eternal battle between keeping a system running, functionally up to date yet ensuring it is secure.
Some organisations I talk to have a monthly patching cycle, which takes a week out of every month to complete. Yes, 3 months of the year, they have teams of staff patching applications and servers. This is a costly and time consuming process, and I am sure these engineers would rather be doing something more interesting!
Yet it is arguable if a fully patched system really IS secure. Many hacking attempts and malware writers look for vulnerabilities that are not even discovered by the software vendors, a concept known as a Zero Day threat, so having a system that is patched against “ yesterdays’ “ threats is not exactly ideal. Let’s face it, malware writers and hackers create exploits quicker than corporates patch their systems.
So which other mechanisms do IT teams use to combat these threats? Configuration management is also key; This is the process of applying best practises to configure operating systems and applications with settings recommended by software vendors and security teams within an organisation.
Vulnerability scanners are sometimes an excellent indicator of machines that are exposed to threats, and can therefore help prioritise the remediation and patching efforts for servers within an estate.
Compliance tools can also give you visibility of machines that are potentially at risk due to poor configuration, alert you to patches that have not applied properly, and can help you prioritise which assets to patch first. But you still need someone to do the work in safe, tested and controlled manner.
So, we have teams of people potentially doing vulnerability scans, configuration management and patching and even risk assessments, and yet still you are facing the possibility that hackers are able to extract intellectual property or disrupt services within your environment. If you don’t believe that this is happening to you, just Google “MaaS”, that’s right, Malware as a Service. Next go to http://www.shodanhq.com/ and enter your company name. Any devices on there you were not expecting to see? Publicly available and presented to the internet? Well if you can see them, so can your attackers.
It is time for a different approach to these problems then, something more in tune with today’s threats that may actually challenge your maintenance and operational procedures in regards to server security.
Symantec Critical System Protection ( CSP) is a Host based IPS/IDS tool that also allows you to lock down the configuration of the Operating system, services, applications and other resources of a server so that they exactly behave according to your defined policy. CSP ensures that no changes can be made to these components, other than by specific users, service accounts or management tools if required. It can do this and effectively enforce change control within your organisation, stopping malicious insiders or rogue administrators applying untested patches, or just making changes to business critical services during a working day. So because no changes can be made (even by Malware or hackers), the fact that your Java component is 3 months out of date becomes irrelevant. Java will be confined by CSP, and its actions are always being monitored by our behavioural agent to spot suspicious activity, and if necessary take proactive action upon anything that will threaten the applications, services and OS of a Server.
I'll give you an example of how CSP works. With our Strict policy template, no changes can be made to any file considered to be a binary or executable by default. It also makes the memory space of applications and services read only by default. Configuration items such as the local "hosts" file or Registry settings are at best read only. Now think about how most Malware tried to infect your servers- largely by modifying or adding executable code, injecting itself into a running process, or modifying critical registry values.With CSP policy applied, this cannot happen.
The principles are clear; CSP natively protects the operating systems from attack, it can be configured to confine your applications and data so that they can only be accessed by approved users, applications, networks and management tools, further reducing the attack profile of the server.
It can even exclude administrators from having rights over certain user data, a concept that has positively ticked many a box on an auditor’s questionnaire. Quis custodiet ipsos custodes? Who watches the watchmen? Well CSP does of course.
So how infrequently do customers patch when using this product? I have one customer in the finance sector that aims to have 1 day of downtime per year with no patching in between maintenance schedules on some of his core Linux servers.
I have worked with a manufacturing client deploying hardware onto servers controlling production line equipment, and with CSP policy locking down Windows 7, they are not planning to patch the Operating system at all before 2020. They are getting maximum value from the OS license, minimising operational costs and are yet still highly secure.
I have also secured systems running Windows NT4 server, a legacy OS which has had no patches readily available for several years, and yet it is a frontline service running in a DMZ environment. This company deployed CSP to protect these machines and has decided not to pay custom support to the OS vendor, saving tens of thousands of pounds per year in the process. In effect, CSP could save you money.
So I challenge you to take on the Patching problem head on with Critical System protection.