Member Since: 8th Aug 2003
Stewart Twynham is an experienced information security expert and AccountingWEB contributor. He recently founded the independent cyber-security consultancy Brandfire (https://brnd.fr/) to help businesses in Scotland tackle these issues.
10th Nov 2006
Documentation is an important point, but often more so because the 40-50 IT enthusiasts I've come across in the last few years are generally highly regarded by their employer but are pretty lousy at IT! As one clever person once put it - an expert is someone who knows 3% more than you do!
The big problem is that systems are left set up a rather strange way, or that huge amounts of time, money and effort are put into problems that wouldn't exist if things were done "properly" in the first place.
Internal IT enthusiasts DO have their place, though. A local IT company, whilst being a whizz on Windows or Exchange, won't know Sage or VT or business practices as well as your internal person.
Small businesses should look at having BOTH points of reference if they can - an external company to sort the basics out - properly - against the wider background of knowing what's going on in the IT world, combined with your "superuser" IT enthusiast that knows every nut, bolt and screw of what's going on internally. And if one or other parts company, it's not the end of the world.
8th Nov 2006
Actually, I ran through the test using three of my clients as examples, and each one came up with the words "HEALTHY"... so I must be doing something right!!
I suppose my concern here is the suggestion that a £37 per month support service is going to deliver some amazing strategic IT advice right into the heart of a small business, whatever the size or complexity.
I agree that a more detailed set of questions and a better breakdown of the results more relevant to the size and scale of business would make far more sense... I just happen to feel that there is more to IT than support!
17th Aug 2006
Re: XML Bloat
JC, of course you're right. Even if we extend your example:
compared to a CSV file which looks like:
...the inefficiency is broadly the same. Add "real world" data including binary information and you can understand why compression is a much researched subject.
However (there is always a but..!), when you combine XML with the right tools (e.g. web services, XSLT) some amazing things can happen. Only this week, I have made it possible for a client to push information from their CRM system onto their website.
Even five years ago this could have been weeks of work, and would have been pretty unstable to boot. It isn't just the fact that the information wouldn't be in the correct "format" - there would simply not be any mechanism where one end could send data to another - so it would all have to be invented from scratch.
Now all I do is build a web service on the web server to consume the XML feed which the CRM system happily provides, whilst XSLT is employed to transform one "format" of XML data into another that the web site understands. The basic prototype took two hours, the whole thing was finished just after lunchtime...
That's not being clever. Accompanying XML is a whole new world of tools and technologies which enable developers (and sometimes even users) to do traditionally very complex tasks very, very easily.
CSV is dead. Long live XML! :)
29th Jun 2006
RAID is often mis-understood, not helped by the salespeople who sell it also not understanding what it is / does / how it works.
Adding in a second, third, forth, or sixth drive does not make your computers more reliable. It makes them LESS reliable in that they are more likely to go wrong (more hard disks to fail).
What RAID does is increase fault tolerance, i.e. when they do go wrong more often, it's even more likely that they won't destroy all of your valuable data in the process.
Specific things that RAID doesn't protect you against include:
(a) user accidently deletes a critical file
(b) the server crashes / fails in a way which corrupts your data (e.g. power failure).
(c) the RAID controller itself fails and scribbles all over each drive (and yes, I've seen that one!)
(d) Other human intervention e.g. accidently rebuilding the wrong array / replacing the incorrect drive / etc causing spectacular loss of data
Furthermore, the added complexity of RAID systems can make system recovery slower when things really have gone belly up!
Of course, that's not to say RAID isn't essential, it's just to set the expectation level of people buying the technology...
26th Jun 2006
Re: query from dumbo
A very sensible question, Malcolm, re: Linux.
Just to add to to Bill's comments...
1) The fact that you're running Linux on your PBX server does not preclude software like Asterisk working well with other systems. The solution we're working on with my client involves reading and writing files on a Microsoft Windows 2003 server, talking to both Microsoft SQL 2005 and Oracle 9i Databases, plus accessing ASP.net 2.0 web services on a Microsoft IIS 6.0 web server. All pretty standard stuff in today's world.
2) Just as an aside, I understand someone's actually managed to port Asterisk onto a Windows platform. Now, quite why anyone would do that (because it's there, perhaps?) is beyond me!
21st Jun 2006
Fly on the wall documentary coming soon...
For those interested, one of my clients (25 users in their HQ plus a few remote users) is planning to migrate from a traditional PBX "phone system" to a Voice over IP (VoIP) solution based upon the open source Asterisk platform.
I will be writing a "fly on the wall" documentary to cover this (warts and all!) - for the benefit of AccountingWEB members later in the year...
Specific benefits for my client of choosing VoIP are (interestingly) absolutely nothing to do with call costs, but the kind of integration that is only possible with VoIP especially integration between the PBX and existing in-house IT systems, for example:
- calls automatically recorded
- calls automatically logged
- recorded calls automatically attached to the relevant client records on the customer database
- voicemails automatically attached to relevant client records
- seamless routing of inbound calls i.e. John is away, and when Company X calls John, Susan gets the call, and when Company Y calls John, Sam gets the call - all decided from information stored on the customer database.
- call performance (KPIs) automatically generated
...yes all things that can be done with a conventional PBX plus several tens of thousands of pounds of extra equipment, software and time, but with the right VoIP system, it's limited only by the inginuity of your IT people.
10th Jun 2005
...actually, although it was a version upgrade, the data had to be converted from Version X to Version Y because the system had gone from Database A to Database B (if I tell you what they are, you'd probably guess the supplier, so I won't!) and the data structures had dramatically changed (no summary tables, etc)
There was no way of converting from old to new, so data from the new had to be re-entered on the old system.
Having said that, my insistence that the old system be kept running "just in case" paid off...
10th Jun 2005
Plain Vanilla Upgrade
Oh if only life were that simple! Recently, one of my clients upgraded from version X to version Y of a well known mid-range accounting package. Version Y had been out for 12 months already, and given that my client was going from plain vanilla version X to plain vanilla version Y - the upgrade was considered a "low risk".
The install was fairly uneventful, but when it came to exchange rate variances, my client found a bug. Instead of posting a variance of £3.77 for example, the package would post, say, £29,892.25p. With over a million pounds incorrectly and seemingly randomly posted all over the system within just a week, the software vendor (not a reseller, this was direct with the software house) claimed that my client was the ONLY one out of their 20,000+ user base using that particular feature, and it wouldn't be fixed until version Z (due in six months, and only because the software would handle exchange rate variances a different way anyway).
In the end, the vendor supplied a consultant free of charge for two days to manually re-key that week's data back into the OLD version and the client had to stick with that for nine months until version Z was *really* ready.
Never assume that version 2,3,4,5,6,7,8 or 9 is any better than version 1.., or that a plain vanilla install is going to be any easier than a bespoke or highly developed one.
Stewart Twynham MBCS MIEE
19th May 2005
Acceptance of the "problem"
What is more worrying is that I am increasingly meeting with suppliers who simply refuse to accept that there is any kind of problem with their work.
Even when faced with a list of bank account numbers downloaded from their application, and a picture of me as the new backdrop on their server, it seems you have to show developers step-by-step the methods used before the little light bulb turns on above their head, usually closely followed by their jaws hitting the table when they realise just what a malicious user *could* do with their application...
As you point out, these tricks aren't new. I used to use similar tricks back in my Unix days over 15 years ago. When it comes to processing user input: trust no-one, suspect everyone, believe nothing, then build the rest of the system on the basis that they've already broken in anyway.
I'll be covering these points in future articles.
26th Apr 2005
PCI Data Security Standard
The information you need is the Payment Card Industry (PCI) Data Security Standard.
This is a roll-up of all the programmes run by all card providers (e.g. in Europe, Visa's progamme was originally known as AIS (Account Information Security), in the USA as CISP - and by other names globally).
It applies to all card providers worldwide.
Visa has a good page which summarises all the requirements plus has a link to the standard. All other providers and most banks have similar pages, but like this one they may be somewhat buried!
The PCI standard is actually a very good document. Normally these kind of standards are very woolly, and years out of date written by committees with little or no technical knowledge. This one actually covers most of the risks pretty succintly, and is well worth reading!
Here is a Mastercard International link as well:
Hope this helps,