Version 1.3 of the Apache HTTP Server has reached end of life status
Posted On: Wed 16 February 2011 By: David
On February 2nd, 2010, The Apache Software Foundation announced that version 1.3.42 of the Apache HTTP Server was released and that this was the final release of version 1.3 of the Apache HTTP Server, which has reached end of life status. They have stated “There will be no more full releases of Apache HTTP Server 1.3“.
Handshake Networking Ltd. recommends that anyone still using 1.3.X versions of Apache HTTP Server begin a migration plan to version 2.0 or 2.2 immediately.
In Defence of Compliance…
Posted On: Mon 24 May 2010 By: Richard
I wrote an opinion column recently for Hong Kong ComputerWorld magazine. You can find it here on their site, or here as a PDF.
It’s an oversimplification of a very complex situation (it’s hard to be thorough when the editor limits you to 750 words), but the underlying message of the piece is that the sheer number of businesses out there who are “not even incompetent” at security (you can’t be incompetent until you’ve at least tried!) makes some form of mandatory compliance unavoidable. And that is the reason I’m a conditional supporter of the PCI’s efforts.
21st Info-Security Project
Posted On: Tue 20 April 2010 By: Richard
Look out for this event, scheduled for the 4th May. Excellent keynote speaker, always a good turn out.
Handshake are very pleased to be one of the sponsors this year, and we’ll have an exhibition stand there. Come and say hello!
PCI ASV Program Guide v1.2
Posted On: Mon 12 April 2010 By: Richard
After many months of anticipation, version 1.2 of the PCI’s instructions for ASVs has finally been published.
Overall, it looks like a huge improvement (although compared to the vague and outdated v1.1, that’s not necessarily a massive achievement!)
The most important change to the way that ASVs are carried out is also the one that has been the cause of most strife - the scoping. Under the old scheme, the scope was whatever the merchant said it was, and if it was incomplete then there were no consequences to the merchant. Now it is mandatory for the merchant to attest that the scope is complete and correct (i.e. all Internet-facing addresses, except those that are properly segregated away from the cardholder data environment).
We’ve issued a more detailed review of the impact of Program Guide v1.2 to our clients already. It’s also available on request - feel free to use the e-mail address at the foot of the page to ask for a copy.
Commodity SaaS in the Enterprise: Fools rush in…
Posted On: Wed 17 February 2010 By: Richard
We know MS Office is expensive. We know OpenOffice is bloated and, although nearly compatible with its Microsoft counterpart, the bit that isn’t compatible always seems to be the bit that you need. So (I am asked surprisingly often) is Google Documents a feasible third-way?
At first glance it seems like a splendid solution for the Enterprise. It’s free, it allows staff to work independently of location, and even independently of their own hardware. It’s pretty easy to use, and it’s got the magical miasma of “cloud” around it. Its buzzword-fu is strong.
The problem is that “cloud” tools intended for consumer users (and given away free) are in a freefalling race to the bottom. The revenue has to come from somewhere. If it doesn’t then the infrastructure ends up being held together by old string and bent paperclips and sooner or later it collapses (cf. Swissdisk). So where does the revenue come from? Advertising. And that, inevitably, one way or another, means that there will be compromises in confidentiality. (The users are, after all, the product - to be delivered to the advertisers with as much corroborating information as possible so that the commercials can be properly targeted.)
Take Google Buzz, for example. In an attempt to generate better advertising revenue, some of Google’s services have converged into a prototype social network, aimed at out-Facebooking Facebook. (Whatever happened to Orkut?!) This change has introduced deliberate breaches of confidentiality, as well as accidental ones.
Of course, people moan and complain about this, but what do they expect from a free service? And that is the important point for Enterprise to grasp. It’s very, very tempting to use free “cloud” services, but where’s the SLA? You’re totally at the mercy of the whims of the service provider. Your documents, confidential one day, could be indexed all over Google’s search engine the next day, if it becomes a commercially attractive proposition for Google to do so.
There’s nothing wrong with SaaS or “cloud”; but without right-of-audit and an enforceable SLA, you’re effectively outsourcing to unaccountable strangers, and that’s going to look bad on any risk assessment. So, I still recommend steering clear of Google Documents for confidential Enterprise work. For now.
What does reputation damage look like?
Posted On: Thu 11 February 2010 By: Richard
Any risk assessment worth its salt will divide the assessed “impact” into subcategories. The quantitative nature of “financial impact” is easy for anyone to interpret. But how would you interpret “severe” reputational impact? This video illustrates nicely the importance of proper penetration testing on web applications… find the bugs before somebody else does, and you make it onto the evening news!
Handshake’s ASV certification renewed
Posted On: Tue 9 February 2010 By: Richard
Handshake Networking Ltd is pleased to look forward to another year as a PCI Approved Scanning Vendor (ASV). We have been doing payment card security assurance work since before the ASV scheme even existed (we were certified under the MasterCard SDP scheme - the forerunner to the ASV - and grandfathered into the ASV scheme when the PCI was created). At the start of February 2010, for the fourth time, we have successfully completed the PCI Scanning Vendor Compliance Testing. Handshake is still Hong Kong’s ASV.
Have you thought about Blackberry security?
Posted On: Tue 9 February 2010 By: Richard
We spend a lot of time working with clients on the development and improvement of security standards and hardening/configuration procedures. Any responsible IT guy knows that servers and workstations need anti-malware, firewalls, patching, hardening, and a bit of tender, loving care.
But how often do mobile devices get included in these projects? Usually they’re overlooked because they’re not considered a threat to corporate information, or because they’re way too heterogeneous.
A presentation at ShmooCon is about to change all that. A researcher has released a proof-of-concept piece of spyware for Blackberries that unleashes all sorts of evil. It sends its controller copies of text messages; or the location of the Blackberry (if it runs a GPS); best of all, it can turn on the microphone and transform the Blackberry into a bugging device.
All that’s required is for the Blackberry’s owner to install a trojan application with this malware built in. Businesses make all sorts of efforts to stop people doing this on their laptops and workstations… but how many even know that Blackberries are equally vulnerable? And how many bother to tell the users?
Does your company have a build-standard for Blackberries? Has security software been installed onto the Blackberry? Is the device’s configuration hardened so that end-users do not have administrator-like privileges? If the answer to any of these questions is no, then a rapid review of the situation should be high on your agenda. It’s not going to be long before the proof-of-concept is released into the wild.
(Reference: Blackberry Spyware)
Last year’s problems are still around
Posted On: Tue 9 February 2010 By: Richard
For the optimists who thought we might have seen the last of Conficker, I have bad news. You cannot relax yet. In the last couple of weeks there have been two high-profile outbreaks in the UK. The first hit the Manchester Police, causing some fairly severe operational impact. The second affected the health authority in Leeds and luckily the impact seems to have been fairly small.
Of course, in Hong Kong, we’re sensitive about security incidents affecting hospitals and police departments because we’ve had our own high-profile incidents in the recent past.
So what can we learn about these two Conficker incidents? Unfortunately, there is nothing new to see here. The vulnerabilities were exploited because of patches that had not been applied. Old patches, that should have been on the systems long ago.
Here’s the importance of regular security audit, in the guise of internal penetration testing. If you have a control failure (for example: your patching procedures are not working 100%) then how are you going to find out about it? Option one is to wait until Conficker (or something nastier) hits your network, costs you money, and embarrasses you. Option two (responsible corporate governance),is far less painful. Worth considering.
(References: Manchester incident; Leeds incident)
