It's something I hear often these days from clients becoming increasingly frustrated at being unable to find decent quality and skilled IT staff and contractors. It's not at all surprising...
In the last 15 years (and probably long before then), the IT contractor market has gone through a number of cycles, alternating in average quality from "crap" to "excellent".
I started my IT career in 1990, working for a small offshore Merchant Bank. At the time, email systems were starting to gain ground and the PC-based network was replacing the mainframe system. The killer apps of the time were Lotus 123 and WordPerfect. The IT market was bowling along nicely and the people in the market were considered to be a pretty high quality lot.
By about 1992 everyone with 6 months experience in Novell Netware 2 and 3 was calling themselves a "Network Consultant" and running off contracting at £40 an hour. The market got saturated with crap and clients started to get a bit stroppy. The Novell CNE qualification was born out of a desire by Novell (the market leader) to reduce some of the complaints it was getting about its products that turned out to be faulty installs.
The recession bit hard in '92 and didn't really lift until '94. The jobs market for IT contracting shrank dramatically as everyone held their breath and IT projects were put on hold. This had the effect of driving the overpaid numpties back into permanent jobs at whichever company would hire them. Correspondingly, the average quality of those left in the market returned to its previous rating of "excellent".
By about 1996, the IT industry had regained some of it's former confidence and the market expanded again. Rates went back up accordingly and with the arrival on the scene of the dotcom game, demand for IT people worldwide exploded. The numpties raced out of their permanent jobs into the contracting market and waited for their new TVR sports cars to arrive. Average quality returned to "crap", and the labour government decided that IT contractors were far too well-off and introduced IR35; an unsuccessful tax diktat targeting a specific group of people in a decidedly divisive fashion.
All was well in the industry until an abrupt stall around the end of 2000. For those working in the dotcoms (myself included) it was nothing short of apocalyptic as companies imploded all around us. It was happening so fast that a now-famous ex-website was set up to try and keep track of the worst excesses of failure (www.fuckedcompany.com) by posting content from anonymous contributors. Entire staff were getting fired by text message (that really happened at British Amulet Group) and voicemail and jobs were evaporating almost as soon as they were advertised. IT contracting agencies started behaving incredibly badly and everyone suffered as a result. Worse still, big, established companies teetered on the edge of oblivion (Marconi, Lucent and ICL to name three) and some never recovered. The market shrank like an iceberg in the desert and sure enough, the numpties started looking for permanent jobs. Average quality miraculously rose!
This time, however, the clients got a little wise and contractors applying for permanent jobs got some tough questions ("Why do you want to leave contracting, are you having trouble finding work?"). Those of us that were left had to put up with unscrupulous clients (mostly the banks) demanding that rates be dropped or unpaid "holidays" taken. This never happened to me, but then I choose not to work for that type of client.
No thanks to the (still) labour governments' tax policies, the economy has recovered (probably due to the housing boom) and since late 2003 it has gradually expanded to its current point. We've never had it so good; large projects are being announced almost daily and there is so much work around that even the most incompetent numpty (hey Bob!) can get a job as a contractor. Average quality is dropping faster than a frenchman's trousers, and even the agencies are starting to complain!
So there we have it. There is indeed a lot of crap in the market, and so it will remain until the next economic slump. The trick to landing the best and most interesting roles is to differentiate one's self from the herd. I got myself Chartered, what are you doing?
Page : 1/1
Friday, 31 Aug 2007
Thursday, 16 Aug 2007
I have long been an advocate of "Full Disclosure" of bugs and security issues in technology products. I believe that FD enforces an urgency on the part of the vendor to address the failures in their code and come clean about their shortcomings. Without FD we would not have had the Microsoft Trustworthy Computing Initiative and we would all be at greater risk than before from the silent hacker whose route in isn't publicised outside of the blackhat community.
Of course, FD increases the risk of the zero day attack (briefly discussed here), but that is a small price to pay for the vaste number of patches that would not be available if the vendors were allowed to keep quiet.
I was looking through my archives the other day and came across this quote from Jason Coombes in 2003:
"All vulnerabilities deserve a public fear period prior to patches becoming available"
What Jason was saying was perhaps open to interpretation, but the fact remains; without FD we would be in a far worse state security-wise than we are now.
6:46 PM
| Comments [0] | #Security
There are three types of patching policy:
• Pro-active
• Re-active
• Ad-hoc
Pro-active patching is the process by which patches are applied as soon as possible after they become available (subject to testing or industry indicators) and the business benefits from the best possible protection while running the small risk that a patch may prove to be faulty.
Re-active patching is the process by which patches are only applied when a outbreak or failure actually occurs. The risk of an unpatched outbreak or failure is considered to be significantly higher (and growing) than the risk of a faulty patch. Re-active patching places the business at significant risk through loss of data or service, depending upon the nature of the outbreak or failure. A good example of such a risk is the Code-Red and Nimda worms, that caused vast damage among Corporate and private systems throughout the world, yet Microsoft release the patch to fix the vulnerability more than 5 months before either threat appeared.
Ad-hoc patching is the process by which patches are occasionally applied in batches to one or more servers. This process brings the disadvantage of re-active patching and at the same time, precluding certain knowledge of the current patching status for any individual machine. Further, none of the benefits of pro-active patching are realised, even when a single server is brought up to date. Ad-hoc patching typically relies on the will and diligence of a small number of individuals (typically, the server administrators) to patch servers when they have cause to visit them for other maintenance works, and convenience allows. Ad-hoc patching rarely follows recommended change control guidelines and is usually performed ‘under the radar’.
With the introduction of Sarbanes-Oxley, and equivalent UK and European Corporate Governance legislation, it falls to senior managers to be personally responsible for the business activities, or inactivities of any company with employees or shareholders. An outbreak as devastating as Code-Red, Melissa or ILoveYou (all industry firsts in their own right) could have a severe affect on the ability of a company to carry out its business, thus attracting the attention of the authorities. It is therefore clear that re-active and ad-hoc patching strategies are not suitable.
Using Microsoft and Microsoft Windows as an example...
Between 1998 and early 2007, Microsoft delivered in excess of 1800 security updates and a further several thousand other software patches, only 2 of which were found to be faulty enough to cause a serious problem. There has (to date) not been a patch released for the Windows Server 2003 Operating System that was deemed by the industry to cause severe problems.
One of the primary technology concerns of businesses today is the use of a new or as-yet undeclared/unknown vulnerability to extort funds by organised criminals. There is no defence against this type of attack from the authorities and it is down to the business to take steps to protect itself. Protection undoubtedly includes personal and perimeter firewalling, but must also include a pre-emptive patch management strategy. It is possible that a new vulnerability could be unknown to the vendor whose software is attacked, and the release of an exploit upon an unprepared public is known as a zero-day attack. Only a comprehensive defence in depth policy will provide any protection whatsoever.
As the number of vulnerabilities increases and the exploitation of these becomes more of a revenue stream for organised crime, it is clear that the business is at ever increasing risk of attack. While it is impossible to totally protect against the zero-day attack, the principle of defence-in-depth (IE multilayered security methods) dictates that agressive pro-active patching is by far the safest and the best course of action.
It used to be the case that Windows was considered insecure and *nix secure. The email flamewars raged and 'net forums ran red and blue with the proverbial blood and invective of the most vocal gladiators of each side.
The statement never really held up in the cold light of day, for the simple reason that any operating system can be made secure if deployed in a secure fashion. What we try and do is deploy securely, while maintaining the functionality and connectivity demanded by our users.
Back in 2002, Microsoft delayed (by several months) the release of Windows Server 2003 and the second Service Pack for Windows XP to begin the Trustworthy Computing Initiative (TwC). TwC was Microsoft's response to the nasty rash of buffer overflow and browser misdirection exploits that were causing public relations headaches in the industry and mainstream media. You know it's bad when yet another flaw is reported in the Financial Times (more than 200 articles to date). The CodeRed worm was even reported in my local village paper!
TwC (now in its fifth year) is an ongoing initiative and has improved matters considerably. In January 2006 Computer Weekly Magazine reported three times as many security flaws relating to *nix as Windows.
That doesn't mean we can sit on our laurels, secure in the knowledge that Microsoft is doing our job for us. A secure operating system is but one part of the infrastructure required to run a business, and all must be considered for their security risks.
6:30 PM
| Comments [0] | #Security
Wednesday, 15 Aug 2007
I had to be taken to A&E on Monday night (this is getting habit forming). When I get home, I noticed that one of my neighbours had put out my bins, and my usual large pile of recycling. We don't know who did it and although we've asked around, no one is any the wiser.
So, whoever you were on Monday night, thank you very much indeed. It's things like that that restore my faith in humanity.
Update: It turned out to be George. George is my opposite neighbour and his actions are made all the greater by the fact that George is well past retirement and needs no excuse to avoid lifting heavy refuse bags for someone else. Thanks George, I look forward to returning the favour.
Tuesday, 7 Aug 2007
Over the last few years I have put in at least a dozen resilient DHCP solutions, search this blog for a few of my thoughts on the subject or take a look here for some design tips.
I recently had a strange error occurring when I tried to use the software I wrote years ago to programmatically configure MAC reservations on a new DHCP server.
When I tried to programmatically add the 146th reservation, it failed with a spurious message. When I tried to add it by hand with the GUI (successfully), the "Address Leases" and "Reservations" sub folders both acquired red crosses and the MMC reports that "snap-in failed to initialize". No amount of fiddling would get rid of the red cross on each sub folder, but the DHCP Server continued to correctly give out all the existing reservations.
Even using NETSH to list the reserved IPs failed (netsh dhcp server scope>show reservedip) with the message "DHCP Server Scope Show ReservedIP failed. Parameter(s) passed are either incomplete or invalid.".
Very little is available to Google on this subject, so I was left with Windows Update. The server in question was Windows Server 2003 R2 SP1, so the obvious solution was SP2.
Amazingly enough this fixed the problem. I say amazing as I have built dozens of DHCP servers using Windows 2000 and Windows Server 2003 and never come across this issue. I wonder if it's an SP1 specific issue?
Wednesday, 1 Aug 2007
As part of my ongoing general interest in the perfect branch-office infrastructure design, I recently decided to put in DFS-R at home. I created all the namespaces and began replication, only to have the CPU shoot to 100% on DFSR.EXE as soon as I enabled the last replication group.
After checking everything and googling for help, I eventually traced the problem to RDC - Remote Differential Compression.
RDC allows DFS-R to compress the changes to the files in the replication group and send them down the line. It's designed for lots of small files and low bandwidth connections, but not large files (some as large as 6Gb) over 1Gb ethernet where the whole file needs to be sent the first time.
Once I switched it off, the CPU dropped to an average 40% as it concentrated on shunting circa 700Gb from one server to another - rather than trying to compress 120 6Gb files before sending what is already compressed data anyway.
