Home » Posts tagged 'Firewalls'

Tag Archives: Firewalls

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).