Home » Posts tagged 'Patching'
Tag Archives: Patching
Three Common Technical Failings
A regular part of my work is to undertake technical audits of IT systems, and report on my findings.
This is different to a Penetration Test in that an audit confirms the general health of a system rather than attempting to break into it. It is similar to the difference between the local Crime Prevention Officer having a look at your house and giving advice to help you remove weaknesses, and a burglar casing the joint. There are three things that are seen in almost every audit: I could almost write part of the report in advance.
Patching is not maintained.
Implementing the vendor’s patches remains the best way of reducing the number of security issues within a system. This should be done regularly and against a defined policy.
The policy is important, as it defines the maximum window of opportunity that an organisation is willing to tolerate for their systems to be vulnerable. For systems where the protection of the information is critical, a policy of patch production immediately may be appropriate, and the risk of disruption is acceptable. This is often known as “Patch and be Damned”.
For less critical systems, then you can test the patches before a large monthly patch deployment.
Antivirus is not up to date.
Antivirus systems, despite their limitations, remain the last line of defence against malware. They are at their most effective when they are able to deal with new attacks, and to do this they must have the latest signature files and the latest versions of the detection engine.
As with the patching of software, antivirus software (properly called malware detection software) should be kept up to date in accordance with policy.
Antivirus is not fool proof, and should not be the only form of defence, but if you’ve got it, then make sure it is effective.
It is reasonable to have one policy document that covers patching and antivirus.
Firewalls are open.
The purpose of a firewall is to limit the connections that can be made through it. Restricting which devices can talk directly to others, and which protocols or ports they can use will hamper the spread of any attack. It must only allow connections that are required for the solution to work and no more. Any additional rules, however convenient they may be, reduces its effectiveness.
And if I see a bunch of rules followed with “default = allow all” I will comment on it.
Take note and consider this a free bit of advice. Following it makes you safer (and adds variety to my work).
OpenSSL End of Life
One of the most commonly used pieces of security software is the OpenSSL cryptograhic library. It is used in almost all Linux based systems and it is packaged in a significant number of Windows applications and, of course, used in the Internet of Things devices, as well as various security appliances and VPN firewalls.
OpenSSL is an Open Source Project, one which has – through good reasons – now adopted a formal release model for their various versions.
Support for version 1.0.0 and earlier has already ended. OpenSSL support for version 1.0.1 ends on the 31st December 2016 – the end of this year.
Why is this important?
The OpenSSL library manages the creation and operation of secure network connections.
- It manages the HTTPS bit for most secure web browsing.
- It manages the connections of secure VPNs connecting users into corporate networks.
- It manages the security for administrators remotely logging into linux servers.
- It manages the hashing of passwords.
There is almost nothing in the security space that OpenSSL does not impact. It is a large and complex piece of software, and has been the subject of some of the most highly publicised and critical IT security issues, such as Heartbleed, which have led to a lot of developer effort being expended on it across all of the versions. [Hence the new support plan]
As OpenSSL is used for so many functions, any upgrade has to be taken with extreme caution. Internal testing by Trusted Management indicates that a version upgrade frequently breaks dependencies requiring additional effort to implement workarounds or alternative systems.
- The current major Linux Distributions, with the exception of the latest Ubuntu release, use OpenSSL Version 1.0.1 and thus will require patching.
For supported distribution versions it is expected, though not confirmed, that these will be available through the repositories. - Applications on Windows platforms that use the OpenSSL library will need patching.
These should become available from the software vendor. - Devices, such as Firewalls and VPN terminators, will need patching.
These should become available from the vendors for supported devices. - Internet of Things devices will become increasingly vulnerable if they are not patched.
Failing to patch OpenSSL will leave systems exposed to any vulnerabilities (such as a new Heartbleed) in those systems.
Unpatched systems will also be a major non-compliance on any regulatory or contractually required audits such as PCI-DSS.
Patch and Be Damned
Why do you test manufacturer patches before releasing them? So you don’t disrupt the Business when you apply them.
What if the exposure to a Business Disrupting Security Event is greater because you haven’t patched?
What is the balance of the two risks?
Security Patches, issued by a large software company are a nicely package guide to where Security Vulnerabilities can be found. These are rapidly reverse engineered by the malware and criminal hacking community – and they work very quickly since their window of opportunity is small, but their rewards are great. This is why critical Vulnerabilities, such as Heartbleed, are announced after the major affected systems have patches available or implemented.
So, should you test Security Patches before deployment? Why not just deploy patches before an attacker uses their vulnerabilities against you?
But know you are doing it. Have an approved Patching Policy, and have a routine for it – a Patching Procedure: Backup or Snapshot systems beforehand (one of the big benefits of virtualisation) then if there is an issue you can quickly revert and start to investigate the cause of the issues.
After all, you have a business continuity plan to handle minor disruptions don’t you? Better to have a test of that than a real use of your Security Incident Plan.
(And you do have a Security Incident Plan don’t you?)
