Categories
Newsletter Old site

Newsletter Mar 2006

News update 2006-03: March 2006
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe AT louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe AT
louisepryor.com. (Change ” AT ” to “@”). Newsletter archived at
http://www.louisepryor.com/newsArchive.do.

In this issue:
1. Farcical bid evaluation
2. Black box models
3. Data protection
4. Newsletter information

===============
1. Farcical bid evaluation

“This is farcical; a spreadsheet error on a multi-billion pound
contract… ” and OCG Buying Solutions has “egg on its face”: these
are just two of the comments after the Government’s IT procurement
body admitted that the discovery of an error in a spreadsheet may
lead to some companies losing their accredited status in the new
Catalist procurement programme. Public sector managers can buy
goods and services more easily from accredited suppliers than
others, so losing accredited status can make a significant
difference to a company.

A leaked letter said “Unfortunately, [we are] not, as we had hoped,
in a position to accept your tender at this time…. This is
because an error in the original evaluation spreadsheet has been
identified, necessitating rescoring of all tenders for this
project… this error has now been corrected and this has caused a
small number of changes to the original award decision.”

This is unlike many of the spreadsheet errors that come to light,
in that it isn’t the organisation whose spreadsheet it is that is
suffering in this case. The OCG probably isn’t affected much if its
reputation takes a hit, and hasn’t lost a lot of money because of
the error. It is other stakeholders, ie the suppliers wanting
accreditation, who have the problems; and they can’t do anything
about it, except to go through a possibly lengthy appeals
process. Not surprisingly, they are a bit fed up, hence the quotes
at the start of this article.

We don’t know exactly what was wrong with the spreadsheet, but one
supplier believes that there was a formula error: too much weight
was placed on environmental factors, and not enough on pricing and
discounts. The OCG said “Every effort is made to ensure that
mistakes do not happen, and OGC Buying Solutions has a quality
assurance process that has been enacted in this instance.” Apart
from the rather mangled language in the second half of this
sentence, there are other criticisms to be made.

A successful quality assurance process would have caught the error
before suppliers were told that they had achieved accredited
status, rather than after. Making an effort to avoid mistakes in
spreadsheets is not enough: what is needed is an effective
development process, which includes appropriate testing and review
stages. If there are routine ways of performing testing and review
they are less likely to be skipped, and more likely to catch
errors. And spreadsheet errors can affect your reputation and hurt
others as well as losing you money.

http://www.channelregister.co.uk/2006/03/10/ogc_spreadsheet_snafu/
http://www.vnunet.com/crn/news/2151405/ocg-revises-catalist-line-third

===============
2. Black box models

The latest Life Insurance newsletter from the FSA has a section on
Actuarial Systems and Controls. As it says, “Accurate output from a
life office’s actuarial area is important because any shortcomings
can potentially cost a firm dearly.” The FSA visited six firms, and
found quite a range of standards; but no firm was completely
satisfactory in every area. And the areas in which most improvement
was possible were those of documentation and spreadsheet use. The
FSA appears to have the following concerns:

– Systems and processes should have up to date documentation

– Every actuarial system should have a full audit trail

– Documentation and systems should have proper change processes and
version controls in place

– Documentation is especially important for systems supported by
just a few knowledgeable individuals

– Data and assumptions should be fully documented, consistent
across the business, and validated

– Financial models should be fully understood, and actuarial
departments should be able to demonstrate why their models should
be believed

– Spreadsheets should be taken as seriously as any other software
development environment.

Regular readers of this newsletter will recognise a number of these
themes. If you’ve read my short article on “Believing your Results”
it should all be very familiar. I find it interesting that the FSA
are now paying more attention to how the modelling results are
achieved, in the life insurance area at least. Models will
undoubtedly increase in both number and complexity as the ICAS
process becomes more mature in both life and non-life insurance,
and their care and feeding will become ever more important.

Just to state the obvious, I can help you to set up development
processes for financial models and spreadsheets, advise on suitable
methods of documentation, change processes and version control,
help you implement appropriate forms of testing and review for
models and spreadsheets, and provide training on these and related
issues. There’s information on my web site, and please get in touch
if you’d like further details.

http://www.fsa.gov.uk/pubs/newsletters/li_newsletter6.pdf
http://www.louisepryor.com/papers/actuary_04_08_08.pdf

Climate change actuary

===============
3. Data protection

There’s an awful lot of data about each and every one of us hanging
around on various computer systems, and not all of it is very
secure. This matters both to the people whose data is held, and
those doing the holding (or, in some cases, letting go). The risks
are many in the areas of both fraud and privacy.

There seems to have been a minor epidemic of laptops going missing
recently. Both Fidelity and Ernst & Young have lost laptops
containing employee data from their clients.

E&Y appear to have lost at least five laptops, one of which held
data on BP, Sun, Cisco and IBM employees. It’s not clear how many
people are affected, but one source has estimated that it’s over
100,000 IBM employees alone. HP staff were told that the laptop
lost by Fidelity exposed 196,000 current and former HP
employees. The data apparently includes names, addresses, US Social
Security numbers, and tax identification numbers, providing an
absolute bonanza for identity thieves.

http://www.theregister.co.uk/2006/03/30/ey_nokia_lapop/
http://www.theregister.co.uk/2006/03/24/hp_fidelity_laptop/

Laptops are inherently much less secure than desktop machines, as
it is much easier for unauthorised people to gain physical access
to them. Organisations should both have and enforce strong policies
on what data should be allowable on laptops, and should use
appropriate security measures, including strong encryption. Simple
password protection is unlikely to be effective. The password
protection in Microsoft Office products is particularly
ineffective, with password cracking programs readily available on
the internet. It’s not only personal data that is vulnerable, but
also commercially sensitive information: would you like your
business or marketing plans, or details of a planned takeover, to
be available to all and sundry?

Even personal data held on desktops or mainframes isn’t safe if the
wrong people get hold of it. Because of the physical access
problems, it’s usually an insider job. A call centre employee in
Leeds apparently stole confidential customer information from two
banks, enabling his gang to defraud the banks of over
£400,000. They targeted customers who didn’t use their credit cards
regularly, obtained their names and security codes, and then
impersonated them in order to change the account address and get a
new card and PIN.

Call centre employees are regularly targeted by identity thieves,
according to a story in The Guardian. They work the bars and pubs,
looking for low-paid call centre workers who might be willing to
make a bit on the side.

http://www.finextra.com/fullstory.asp?id=15025
http://money.guardian.co.uk/saving/banks/story/0,,1744116,00.html

Having good policies in place around the protection of data on
laptops isn’t enough to avoid problems; you’ve got to enforce the
policies too. A recent survey (by a company that sells web content
filtering) found that 70% of companies recognised that an
acceptable internet use policy was crucial to the security of their
IT systems, but 38% of employees governed by a policy are unaware
of its contents. 40% of respondents said that a policy was in place
but was not enforced.

http://www.smoothwall.net/information/news/newsitem.php?id=971

The existence of a policy isn’t going to make any difference to how
things actually happen unless people know about the policy,
understand the point of it, and find it easier to comply with the
policy than to breach it. This applies just as much to software
development and use as to security issues.

===============
4. Newsletter information

This newsletter is issued approximately monthly by Louise Pryor
(http://www.louisepryor.com). Copyright (c) Louise Pryor 2006. All
rights reserved. You may distribute it in whole or in part as long
as this notice is included. To subscribe, email news-subscribe AT
louisepryor.com. To unsubscribe, email news-unsubscribe AT
louisepryor.com. All comments, feedback and other queries to
news-admin AT louisepryor.com. (Change ” AT ” to “@”). Archives at
http://www.louisepryor.com/newsArchive.do.

Categories
Notes Old site

Project financing spreadsheets

In 2004 a paper on “Financial Modelling of Project Financing Transactions” was presented to the Institute of Actuaries of Australia Financial Services Forum. It’s well worth a read if you are involved in any sort of financial modelling, whether or not you are an actuary and whether or not you are modelling project financing.

The paper includes an analysis of the risks of models and some ideas for managing the risks, gives a clear introduction to Monte Carlo simulation and why you might use it, and has a section on why actuaries might be good people for modelling project financing.

It also includes some statistics on the error rates the authors have found in spreadsheet models of project financing. The authors say “Research has shown that error rates in project financing models can be as high as 10%. Section 5 of this paper provides some statistics on error rates collected by Mercer Finance & Risk Consulting. Out of the thirty highest value projects reviewed during the 2004 financial year, nine (that is, 30%) exceeded the 10% threshold; four exceeded the 15% threshold; and one exceeded the 20% threshold.”

The wording may be misleading here. They are not saying that, for example, 10% of the models have errors. In fact, all the models (100%) that they reviewed contained errors. They are saying that in four of the models they reviewed over 15% of the unique spreadsheet formulae contained errors, and that one model had errors in over one in five of the formulae. This model was one of the smaller ones, too, so it’s no use saying “it’s only a small model, so it’ll be OK”.

Although the spreadsheets they reviewed were all modelling project financing, there is absolutely no reason to suppose that the high error rates are peculiar to the project finance field. Financial models of any sort are complex, and it’s hard (but not impossible) to write a spreadsheet that doesn’t contain errors.

So let me say, once again, that it’s important to get the process right when developing financial models (whether using a spreadsheet or specialist modelling software). Be clear what it is that you want the model to do: write a specification that is detailed enough to test against. Use appropriate techniques when building the model: something that looks like a really cool way of doing things may be difficult for other people to understand. Document the design decisions you make. Use a good change control process to keep track of what’s going on. Test the implementation against your specification. Record the tests, so that other people have some reason to believe you when you say the system has been tested. And, above all, don’t trust yourself. You are bound to make mistakes in the coding, and if you don’t look for them you won’t find them.

Categories
Notes Old site

Kodak earnings restatement

In November 2005 Kodak restated its Q3 results by $9 million. The restatement was attributed to restructuring and severance costs, plus a real estate gain. The restructuring costs were apparently because they got the accounting treatment wrong; we were told that “the magnitude of the worldwide restructuring program the company is undertaking imposes significant challenges to ensure the appropriate accounting”

There was also an error of $11 million in the severance calculation for just one employee. The error was traced to a faulty spreadsheet: apparently “too many zeros were added to accrued severance”. No payment was actually made to the employee in question (which was lucky for Kodak, but maybe unlucky for the employee). It sounds as if the error was either a simple data entry problem, or, possibly more likely, that the spreadsheet was expecting an entry in $’000 but got one in $.

This could be yet another example of a spreadsheet that is theoretically correct, but is not easy to use. If the wrong
information is used for the calculations, then the answers will be wrong: it’s our old friend, Garbage In, Garbage Out.

Categories
Notes Old site

Nevada City budget problems

In January 2006 it was discovered that there was a deficit of $5 million in the budget for Nevada City. The budget spreadsheet was the same as the one for 2005, updated for 2006. Apparently it was working correctly until sometime in late December, when it developed a problem. The difference was a $5M deficit in the water and sewers fund, that wasn’t present on 14 December but was there in the version discussed at a meeting on 3 January. Evidently some councillors noticed the change. The finance director hadn’t noticed, as he had a printed version that didn’t show the error. Once the error was noticed, it took the finance director about a day to fix it. As he was doing so, he found other errors.

Obviously the spreadsheet had changed after it had been printed out. We have no information about how the error was introduced. We are not told whether the other errors that were found and corrected were actually in the 2005 version of the spreadsheet, but it wouldn’t surprise me.

It appears that the actual Excel file was sent round to the councillors, and indeed posted on the city’s web site. This raises other concerns, unless it was protected so that it couldn’t be changed.

Categories
Notes Old site

SunTrust earnings restatement

In late 2004 one of the big US banks, SunTrust Banks, announced a restatement of earnings for the first two quarters. This followed problems they had found with their loan loss allowances, or more specifically, with the model they were using for their loan loss allowances. Part of their press release says: “There were numerous errors in the loan loss allowance calculations for the first and second quarters, including data, model and formulaic errors.” In other words, they are saying that the data that went into the model was wrong, the model itself was not a good fit to reality, and on top of that they hadn’t even implemented this faulty model properly. That covers pretty much everything that can go wrong with a model, if you count data as including parameters (see my article how to believe your models).

The fall out from the modelling problem was definitely non trivial. Q1 earnings were restated by 1%, Q2 earnings by 6%. In Q2, the loan loss allowances changed by 90%. The loan loss allowances had been overestimated, so this means that in the second quarter they were out by an order of magnitude. Three people lost their jobs as a result of the problem, including the Chief Credit Officer. The Financial Controller was reassigned to a position “with responsibilities that involve areas other than accounting or financial reporting” – ie, neither finance nor control.

Moreover, SunTrust’s directors were unable to sign off under section 404 of Sarbanes-Oxley at the next year end. They said that they were likely “not be able to conclude that the Company’s internal control over financial reporting was effective at such date.”

So why did all this happen? Well, apparently they were bringing in new processes and a new model in order to comply with Sarbanes-Oxley. This evidently proved more difficult than they anticipated. They say “The Company’s implementation of a new allowance framework in the first quarter was deficient. The deficiencies included inadequate internal control procedures, insufficient validation and testing of the new framework, inadequate documentation and a failure to detect errors in the allowance calculation.” They also point to deficiencies in spotting the problem, and then in doing something about it. In particular, “certain members of the Company’s management did not treat certain matters raised by the Company’s independent auditor with an appropriate level of seriousness.”

The morals are fairly obvious. First, models matter, and mistakes in models can be significant. Second, change is risky. It can be very risky. (On the other hand, not changing also has its risks). Thirdly, take problems seriously.

Resources

The following external links are relevant:

Categories
Newsletter Old site

Newsletter Feb 2006

News update 2006-02: February 2006
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe AT louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe AT
louisepryor.com. (Change ” AT ” to “@”). Newsletter archived at
http://www.louisepryor.com/newsArchive.do.

In this issue:
1. The tools for the job
2. Email: is it safe?
3. Russian viruses?
4. Attachment
5. Newsletter information

===============
1. The tools for the job

How do you decide what tools to use? Yes, it’s possible to beat an
egg white with a knife, or loosen a screw with a nail file, but an
egg-beater or screwdriver would be a better choice. Not
surprisingly, the same goes for software. Excel is a bit like a
Swiss Army knife: you can do most things with it if necessary, but
specialist tools often work better.

This was recently demonstrated at Roll-Royce, where engineers were
asked to calculate how many times a simple pendulum hit a target
pin. Those who used Excel came up with three as the answer, while
those using specialist mathematical software came up with four
(which was the correct answer). Even using a much smaller time step
in Excel made no difference.

http://tinyurl.com/kpb9f

It’s well known that Excel’s statistical functions are less than
perfect. For a start, its functionality is limited; there are many
analyses that you just can’t do. Then there’s the issue of
accuracy: Excel doesn’t use the best available algorithms. The
values differ in the third digit and beyond. Some of the problems
are more evident in the tails of the distributions. A number of the
statistical functions use non-standard definitions. The random
number generator is not really random enough (and in one version of
Excel it actually produced negative numbers, which are definitely
outside the [0,1] range).

http://www.practicalstats.com/Pages/excelstats.html

Microsoft has made improvements, but this means that current
versions of Excel are not consistent with earlier versions. The
same workbook will give different results depending on which Excel
version is used. Also, it is claimed that some of the fixes have
made the problem worse: “Microsoft attempted to fix errors in the
standard normal random number generator and the inverse normal
function, and in the former case actually made the problem worse.”

http://support.microsoft.com/default.aspx?kbid=828888&product=xl2003

Some improvement can be gained by using specialist statistical
add-ins for Excel, but if you are doing any serious statistical
work you should probably consider using a specialist tool. The nail
file might do for one screw, but if you are putting a shelf up a
screwdriver is more or less indispensable. A Swiss Army knife,
although handy, can’t replace a whole toolbox.

On a somewhat related note, I’m currently chairing the GIRO working
party on software use, which is looking into what software GI
actuaries (and others) use, and how they use it. As our first step,
finding out what software is actually used, we are conducting an
online survey. So, if you work in General Insurance, as an actuary
or otherwise, we’d really appreciate if you’d help us out by
completing the survey, which is at
http://www.surveymonkey.com/s.asp?u=891841542723. There’s a prize
of a bottle of champagne for one lucky participant!

===============
2. E-mail: is it safe?

Fifteen years ago e-mail was new and shiny and more or less unknown
in the business world. Nowadays it’s hard to imagine how businesses
could operate without it. In some ways, though, we haven’t really
got to grips with it. Those physical carbon copies, one into the
file and one into the day book, certainly meant that records of
outgoing letters were kept. Morgan Stanley must wish that life was
that easy. The firm has just made an offer of $15 million to settle
an investigation by the SEC into an alleged failure to produce
email evidence during a legal dispute. Morgan Stanley was involved
in a court case, and failed to produce e-mails and documents sought
by the opposing side’s lawyers. The regulators were concerned that
this indicated a breach of federal regulations, and began their own
investigations. Meanwhile, the judge was so annoyed that she
reversed the burden of proof in the court case, so Morgan Stanley
had to prove its innocence.

http://www.out-law.com/page-6656

Of course we all know that the Cc: designation on an e-mail means
“Carbon copy”, and Bcc: means “Blind carbon copy”. Was it easier to
make sure that copies went to right people when actual carbon paper
was used? I suspect that mistakes happened back then, just as they
happen now. Every business day, the US Defense Department is meant
to announce contracts awarded valued at $5 million. A new employee
at the Air Force dropped the Defense Department from the e-mail
distribution list for new contracts in December. Nearly $4 billion
in contracts slipped through the net before the error was
discovered. “It’s awfully embarrassing,” said an Air Force
spokesperson.

http://cwflyris.computerworld.com/t/296929/664274/9136/0/

It turns out that not expecting an e-mail is no excuse for not
reading it. Bernuth Lines Ltd listed an e-mail address in the
Lloyd’s Maritime Directory, and on their web site. When they were
involved in an arbitration case, both the arbitrator and the other
party to the dispute sent e-mail to the listed address, even though
it had not been specifically notified to them. It appears that the
e-mails weren’t read, and may even have been deleted as spam. This
cut no ice with the judge who said that receiving an e-mail is no
different to the receipt at a company’s office of a letter or
telex. He ruled that e-mail counts as a “recognised means of
communication”. The moral of this story is pretty obvious: if you
publicise an e-mail address, for goodness sake make sure that you
read the e-mail that is delivered to it.

http://tinyurl.com/ftff6

And, finally, having made sure that you keep copies of your
e-mails, that they go to the right people, and that you read the
ones that you receive, how effective is e-mail as a communication
medium anyway? A recent article in the Journal of Personality and
Social Psychology argues that people tend to believe that they are
much better e-mail communicators than they really are. The authors
of the article conducted five separate studies to investigate the
communication of humour, sarcasm, and other emotions. The study
found that the people tend to look to their own perspectives when
attempting to understanding messages from others. The problem is
made worse when the other parties to the communication are coming
from rather a different perspective.

E-mails are often less formal than written letters, and we may be
tempted to introduce humour or sarcasm in order to lighten the
tone. This is probably a mistake, if we want to make sure that the
intended message is getting across.

http://arstechnica.com/news.ars/post/20060214-6176.html

===============
3. Russian viruses?

Stock exchanges and viruses just don’t mix. Early in February the
Russian Trading System (RTS) was infected with a virus, and trading
was suspended for an hour. The virus generated a large amount of
outgoing e-mail traffic, and disrupted legitimate e-mail, both
outgoing and incoming.

“The virus got into a computer connected to a test trading system
from the Internet,” RTS vice president Dmitry Shatsky said in a
statement. “The infected computer started generating huge volumes
of parasitic traffic, which overloaded the RTS’s support
routers. The result was that normal traffic – data going into and
out of the trading system – was not processed.”

Note that it was only a test trading system that was infected; you
have to be careful with any machine connected to the internet,
regardless of what function it is performing.

http://www.finextra.com/fullstory.asp?id=14867
http://news.zdnet.co.uk/internet/security/0,39020375,39250774,00.htm

That was a virus in Russia; it was a virus from Russia, or at least
operated by Russians, that was used to steal more than 1m euros
from bank accounts in France. The virus, or “sleeper bug”, is
downloaded from a web site, or received in an email, but doesn’t do
anything until the user starts using online banking. The bug then
records passwords and security codes and forwards them to the
thieves. Yet another reason, if one were needed, to have up to date
virus and malware protection.

http://www.guardian.co.uk/france/story/0,,1703777,00.html

It appears that those Russian thieves were using old
technology. The newest malware programs on the block are Trojans
that don’t bother with your password and security details, they
just wait until you’ve done that bit for them and then access your
bank account directly. These new Trojans are programmed to work
with specific online banking web sites. Remember, just don’t click
on that unsolicited and unexpected e-mail attachment.

http://news.zdnet.co.uk/internet/security/0,39020375,39253433,00.htm

===============
4. Attachment

The BlackBerry addicts among us can sleep a bit easier for the
moment, as the possible shutdowns of service in the UK and US
look less likely to happen. RIM, the makers of the BlackBerry, had
in any case announced that there would be a work around that would
let the service continue in the event of the threatened US
injunction. It’s not over until the fat lady sings, though, and
things could still go horribly wrong for RIM and BlackBerry users.

http://news.ft.com/cms/s/130ae8b0-9410-11da-82ea-0000779e2340.html
http://techrepublic.com.com/2100-1035_11-6037169.html?tag=nl.e019
http://www.finextra.com/fullstory.asp?id=14964

One survey showed that 81% of asset managers questioned consider
the Blackberry service as “vital” and “critical” to their
business. Let’s hope they, and everybody else, were making suitable
contingency plans. To me, this whole saga underlines the problems
associated with relying on a proprietary technology for which there
is a single supplier. Personally, I don’t expect to have to take a
view on the likely validity or otherwise of a set of patents before
I invest in a new piece of equipment.

As so many people appear to be addicted to their BlackBerry, maybe
somebody will start making clothes with special BlackBerry
pockets. Don’t laugh too much; apparently you can now get a tie
(yes, one of those things that goes round your neck) that will hold
your iPod.

http://www.reghardware.co.uk/2006/02/23/pink_ipod_tie/

===============
5. Newsletter information

This newsletter is issued approximately monthly by Louise Pryor
(http://www.louisepryor.com). Copyright (c) Louise Pryor 2006. All
rights reserved. You may distribute it in whole or in part as long
as this notice is included. To subscribe, email news-subscribe AT
louisepryor.com. To unsubscribe, email news-unsubscribe AT
louisepryor.com. All comments, feedback and other queries to
news-admin AT louisepryor.com. (Change ” AT ” to “@”). Archives at
http://www.louisepryor.com/newsArchive.do.

Categories
Newsletter Old site

Newsletter Jan 2006

News update 2006-01: January 2006
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe AT louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe AT
louisepryor.com. (Change ” AT ” to “@”). Newsletter archived at
http://www.louisepryor.com/newsArchive.do.

In this issue:
1. Control freakery
2. Doing without
3. Safe documents
4. Reports and surveys
5. Newsletter information

===============
1. Control freakery

I admit it. I’m a control freak. Not necessarily in all aspects of
life, but as far as my computer is concerned, there is no
question. I don’t let anything (Microsoft included) update my
software automatically, and if I change a setup in any way I want
it to stay changed. I don’t like it when my computer tries to be
helpful, by guessing what I want to do. It’s just not that clever,
and certainly isn’t a mind reader, and often guesses wrong.

In July 2004 I discussed how Excel tries to be clever when
importing data by recognising dates and converting them to date
values. It also automatically converts strings that it believes are
floating point numbers. For example, the string “2310009E13” is
converted to the number 2.31E+13. In both cases the original data
is irretrievably lost.

It is possible, although not easy, to avoid these automatic
conversions, but you have to remain vigilant. You can’t turn them
off, but have to take special steps each time you import data. Some
solutions are described by Microsoft in
http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q214233

The auto-completion feature is another source of problems. When you
type data in, Excel tries to guess what you mean by looking at
other values in the same column. If you are entering credit
ratings, for example, and the first one you enter is AAA, if the
next one you enter also starts with an A, Excel will suggest AAA as
an auto-completion. If you hit enter, it thinks you are accepting
the suggestion. So if you are actually trying to enter A, you type
A, enter, and Excel helpfully puts AAA in the cell. This one is
easier to fix: simply turn off auto-completion. On the Tools menu,
click Options, and then click the Edit tab. Once there, select or
clear the “Enable AutoComplete for cell values” check box.

Dean Buckner has just found another example of what might be called
(if you are feeling charitable) over-helpful behaviour. He writes:

I’ve always tried to discourage our users from MS ‘shortcuts’,
i.e. little files that can be placed on the desktop and which
point to applications. The problem is that they sometimes point
to the wrong thing – we had a case last year of an emailed short
cut pointing to a correspondence log which was an old version.
Thus some people were using a correct version, some were
updating an old one in parallel. The business of merging the
two streams was a nightmare.

Anyway I forbade this practice, and restricted the use of
shortcuts to those which are centrally maintained and have a
strict change control. (For they can be useful in that they can
control the way an application is called, for example with a
security file).

Or so I thought. I took our main system down over the break in
order to do maintenance work. I did this by deleting the main
production file, and working on a copy, as one would. However,
someone tried to access it over the break, and it turned out
that when a shortcut fails, it will “search” around until it
finds an application that looks similar. In this case it found
one of the backup files which we save down every week. Once
this happens, it then changes not only the user’s own desktop
version of the shortcut, but also the central file itself. I
only spotted this when, working on the application, I noticed
some clearly out of date information.

Ouch. As Dean goes on to say, it’s difficult to find out what is
going on and work out how to turn it off (the help system is
decidedly unhelpful on this). The answer is in the following
Microsoft document:
http://support.microsoft.com/default.aspx?scid=kb;en-us;299780&sd=tech
The document says: “If you disable a shortcut, the NTFS File System
in Windows XP and Windows 2000 automatically attempts to locate the
shortcut destination by searching all paths that are associated
with the shortcut.” One of the solutions involves editing the
Registry, which is not for the faint-hearted. Also, if you make
backups or copies of files in a nearby directory, it’s probably
best to change the name so that Windows will not identify the copy
with the original.

===============
2. Doing without

I moved house about 3 weeks ago, and have had problems getting
broadband connected. It’s more accurate to say that I am having
problems, as I haven’t actually succeeded yet (though progress is
being made). Apparently my order “got stuck in the system”. I
suggested WD40, but apparently that wouldn’t work. Anyway, I have
had to fall back on good old dial-up, and the effects have been
much wider than I anticipated. I hadn’t quite realised how much I
had come to rely on the always-on, high bandwidth access. Even when
doing things that I thought were definitely off-line in nature,
I’ve found it frustrating not to be online. There’s a lot of
information out there that I have never bothered to download,
because it’s so readily available on the web… but when you have
to connect explicitly (tying up your phone line) and download over
what now feels like a piece of wet string, the term “readily
available” takes on a whole new meaning.

What’s interesting about this is that it shows how ingrained habits
can become. After all, there are many people in this country (and
elsewhere) who don’t have broadband, and who manage very happily
with dial-up. But in the three and a bit years that I have had
broadband, I appear to have changed my working patterns quite
radically, and it’s proving difficult to revert to the old ones.

One thing I don’t have is a BlackBerry. When travelling, I manage
quite happily with my Palm hooked up to my mobile via
bluetooth. It’s slightly clunky, but surprisingly effective. There
are, however, large numbers of people who do have BlackBerries, and
who rely on them quite heavily. Are they right to do so? How would
they manage without them?

We know that some people can cope, for short periods at least,
because in October we heard how the BBC had suspended its
Blackberry service because of email problems. But many more may
have to cope for long periods if not for ever, and there may be
more short outages.

As BlackBerries become more popular and hence more mainstream, they
become more attractive targets to the bad guys. Early in January
there was a news story about security vulnerabilities that provided
loopholes through which hackers could launch denial of service
attacks. No actual problems were reported, but it’s probably only a
matter of time.

Meanwhile, Research In Motion (RIM, the makers of the BlackBerry)
are involved in a US court action over a patent infringement. A US
federal appeals court wanted to use US patent law, which bars
unauthorised use of a patented invention within the US, to block
the BlackBerry service. The Supreme Court refused to consider RIM’s
argument that the law should not be used to block the service,
which is run from Canada. The end result could be a lot of unhappy
US BlackBerry addicts, though they would doubtless soon find usable
alternatives. FT readers certainly think they would, according to
an online poll.

http://news.zdnet.com/2100-1035_22-6029671.html
http://makeashorterlink.com/?P6392309C

This story also emphasises one difficulty caused by the
globalisation of services: just what jurisdiction do they come
under?

===============
3. Safe documents

Last month I mentioned how Westpac had been forced to halt trading
on its shares and deliver its annual profit briefing a day early
after it accidentally sent its results by email to research
analysts. It had sent out a spreadsheet containing the results for
previous years; it also contained the latest results, obscured by
blacking out the relevant cells. The cells may have looked black on
the screen, but it didn’t need advanced technical skills to find
out what they contained.

The US National Security Agency (NSA) has now issued a document
that describes how to issue an electronic document that has no
sensitive information hidden in it.

http://www.fas.org/sgp/othergov/dod/nsa-redact.pdf

The document is 14 pages long, and covers some of the ways in which
problems can arise, as well as how to avoid them. In brief, the
recommended procedure is:

1. Make a copy of the original document, and work on the copy.
2. Turn off change tracking etc.
3. Delete sensitive text and diagrams.
4. Change the document name to make it clear that it’s an edited
version.
5. Open a new blank document.
6. Copy the contents of the edited document into the new one.
7. Convert the new document to pdf.

The NSA gives detailed instructions for doing all this in a Word
document, but the same principles apply to spreadsheets and other
formats.

===============
4. Reports and surveys

If you work in General Insurance, you’ll probably know about GIRO,
the general insurance conference held each year by the Actuarial
Profession. I’m currently chairing the GIRO working party on
software use, which is looking into what software GI actuaries (and
others) use, and how they use it. As our first step, finding out
what software is actually used, we are conducting an online
survey. So, if you work in GI, as an actuary or otherwise, we’d
really appreciate if you’d help us out by completing the survey,
which is at http://www.surveymonkey.com/s.asp?u=891841542723.
There’s a prize of a bottle of champagne for one lucky participant!

The FSA has just issued its annual report on the Financial Risk
Outlook. One of the main points that is made is the need for stress
testing: how firms would respond to extreme risk scenarios. The
scenarios imagined by the FSA include natural disasters (possibly
driven by climate change), global pandemic, political instability
in a major economy, a large terrorist attack, or a major corporate
bankruptcy.

http://www.fsa.gov.uk/Pages/Library/corporate/Outlook/fro_2006.shtml

Although these scenarios are important, there are undoubtedly
others, possibly as yet barely imagined, that could cause similar
levels of disruption. The FSA emphasise that it is important to use
historical experience to inform hypothetical scenarios, rather than
simply re-running past events. Another important aspect of
effective stress testing is the effect of unsuspected risk
correlations across the different parts of large, complex
businesses.

===============
5. Newsletter information

This newsletter is issued approximately monthly by Louise Pryor
(http://www.louisepryor.com). Copyright (c) Louise Pryor 2006. All
rights reserved. You may distribute it in whole or in part as long
as this notice is included. To subscribe, email news-subscribe AT
louisepryor.com. To unsubscribe, email news-unsubscribe AT
louisepryor.com. All comments, feedback and other queries to
news-admin AT louisepryor.com. (Change ” AT ” to “@”). Archives at
http://www.louisepryor.com/newsArchive.do.

Categories
Newsletter Old site

Newsletter Dec 2005

News update 2005-12: December 2005
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe AT louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe AT
louisepryor.com. (Change ” AT ” to “@”). Newsletter archived at
http://www.louisepryor.com/newsArchive.do.

In this issue:
1. You get what you wish for
2. Supplying risks
3. Mistakes will happen
4. Seasonal greetings
5. Newsletter information

===============
1. You get what you wish for

Every child knows that you have to be careful when you make a
wish. It’s something that Midas learned the hard way.
Unfortunately, it’s something that a number of other people are
learning the hard way, too, even though they weren’t the ones to
make the wish.

Imagine you are designing a mobile phone, in the early days of
their use. You realise that you should have a way of locking the
keypad, so that calls aren’t made by accident when the phone is
knocking around in someone’s pocket or bag. Then you introduce a
further safety measure: it will always be possible to dial the
emergency numbers (999 or 122) when the keypad is locked; in an
emergency, nobody is going to want to fiddle around unlocking the
keypad.

The unintended consequence is that the centres handling emergency
calls get around one call every four seconds that is from a mobile,
and on which there is no communication at all, just silence. Most
of these calls are from phones that have accidently dialled 999 or
112. After all, if the 9 key is jogged by accident, it’s really
quite likely that it’s going to be jogged 3 times. Worse, if it’s
jogged 3 times by accident, it’s often jogged three more times, and
three more times, so there are many mistaken calls from the same
phone.

The operators answering the emergency calls have procedures to deal
with this problem. If there is nobody speaking into the phone, they
ask the caller to tap on the screen; if they get no response, they
put the call through to an automated system, which asks the caller
to press one of the keys. If there is any response at all, the call
is put through to the police.

Now, imagine you are badly injured, alone except for you
mobile phone. You can just manage to dial 999, but can’t get the
phone near your head, so can’t speak into it or hear what the
operator is saying to you. You hope that by making several calls in
quick succession the operators will realise that something is up,
trace the calls, and send help.

Sadly, no help will arrive. You are just one of the 900 silent
calls per hour coming in from mobiles. The operators can’t tell the
difference between you and a jogged keypad in someone’s bag.

There are no easy answers, given that mind reading is impossible.
Make keypad locking lock out the emergency numbers, and there will
be some people who can’t dial the emergency number in an
emergency. There just aren’t the resources to send help to all the
silent, repeated calls, just on the off-chance that they are
genuine. And as things are, some people won’t get help when they
need it.

Could all this have been foreseen? With hindsight, obviously, but
at the time? I don’t know. But the good news is that the number of
silent calls is decreasing as the proportion of folding mobiles
increases.

There was a programme on BBC Radio 4 that covered this and related
issues. The transcript is available from
http://news.bbc.co.uk/1/hi/programmes/file_on_4/3708232.stm

===============
2. Supplying risks

There has been some comment in the press recently about how
companies are getting more worried, and hence more clued up about,
risks to their supply chains. This worry is easy to understand in
the case of manufacturing companies, who often have long supply
chains with very little slack. Others should also be worried.

I heard an interesting story recently about a transport company in
the USA. Just as Hurricane Katrina struck New Orleans, they had
finished a major risk identification exercise. It had been an
extremely thorough affair, they thought, and they were feeling
pretty satisfied with a job well done. Of course they missed a
biggy. They hadn’t realised that all the steel they needed for
their fleet replacement programme passed through New Orleans. Ouch!

Closer to home (to my home, at any rate) the explosion at the
Buncefield oil depot raised many health and safety fears; it was
very lucky that nobody was killed, and the fallout from the smoke
doesn’t appear to have been as bad as it could have been. But some
of the knock-on effects were unexpected.

One of the businesses affected was Northgate Information Solutions,
whose head office is right next door to the depot. The building was
seriously damaged, and the on-site backup systems were, as they
say, “rendered inoperable”. Not surprising, really. Northgate had a
business continuity plan which they were able to put into action,
but there was a break in service. A number of their customers were
quite seriously affected. These included Richer Sounds, the hifi
retailer, whose web site and email systems were affected, the
Labour party, whose web site was down, and Addenbrooke’s hospital,
in Cambridge. Their internal information system of patient data was
in the destroyed Northgate building. They had to revert to manual
records for a period.

Who would have thought that an explosion in Hemel Hempstead would
affect the running of a hospital in Cambridge? (For those who don’t
know, the two are about 50 miles apart.) But of course, with modern
technology there is no particular reason why the data centre should
be anywhere near the hospital. And it’s not just large
organisations who outsource some of their IT functionality; my own
web site is hosted in Canada. Nowadays there are long supply chains
even in the services sector, subject to just the same risks as any
other supply chain. There are around 50 other oil depots like
Buncefield around the country; I wonder how many other data centres
are near them.

http://www.theregister.co.uk/2005/12/14/oil_blast_prangs_newlabour/
http://news.yahoo.com/s/ap/20051212/ap_on_bi_ge/britain_explosion_business

===============
3. Mistakes will happen

To death and taxes I would add mistakes, as being something you can
be sure of. However hard you try, mistakes will happen. You may be
able to reduce the number of mistakes, or limit the damage they
cause, but you can’t totally eliminate them.

Trying to reduce their incidence and severity are both valid risk
management strategies, but in most cases it’s a mistake (another
one) to rely totally on the former. It’s always a good idea to have
good ways of picking up the pieces when something does go wrong.

This is a lesson that Takuo Tsurushima, chief executive of the
Tokyo Stock Exchange (TSE), and two of his colleagues, have learned
to their cost. The nightmare started when a broker mis-keyed a
deal, placing an order to sell 610,000 shares in J-Com at 1 yen
apiece instead of 1 share at 610,000 yen. The company in question
had only around 15,000 shares outstanding, so selling 610,000 of
them was always going to be problematic. Commentators have said
that more or less anywhere else in the world such an aberrant order
would have been spotted and could have been de-keyed. In fact, it
appears that the mistake was spotted quite quickly, but the TSE
systems had no method of cancelling the order.

Oddly, there was a similar case almost exactly four years earlier,
when a trader intended to enter an order to sell 16 Dentsu shares
at 610,000 yen but actually keyed in 610,000 shares at 16 yen. The
recent press coverage doesn’t appear to have picked up on this
coincidence, though it does seem odd: is 610,000 a special number
in some way?

There are some obvious things that could be done to try to prevent
errors of this type, such as some sanity checks on the number of
shares in a deal, and the price, asking for confirmation if they
are outside certain limits. Of course, these things always turn out
not to be as simple as they seem to an outsider, and we have all
encountered situations where you just click through vital warning
boxes, because too many of the wretched things appear.

http://www.economist.com/displaystory.cfm?story_id=5310558
http://catless.ncl.ac.uk/Risks/24.12.html#subj8.1

===============
4. Seasonal greetings

I do like it when I can say “I told you so.” Back in June I wrote a
piece in my newsletter about hidden data in documents, and pointed
out that the problem existed in Excel as well as Word; early in
November Westpac was forced to halt trading on its shares and
deliver its annual profit briefing a day early after it
accidentally sent its results by email to research analysts. It had
sent out a spreadsheet containing the results for previous years;
it also contained the latest results, obscured by blacking out the
relevant cells. The cells may have looked black on the screen, but
it didn’t need advanced technical skills to find out what they
contained.

http://makeashorterlink.com/?I23D21A5C

May all your communications be intended, all your spreadsheets
reliable, and all your risks well managed in 2006!

===============
5. Newsletter information

This newsletter is issued approximately monthly by Louise Pryor
(http://www.louisepryor.com). Copyright (c) Louise Pryor 2005. All
rights reserved. You may distribute it in whole or in part as long
as this notice is included. To subscribe, email news-subscribe AT
louisepryor.com. To unsubscribe, email news-unsubscribe AT
louisepryor.com. All comments, feedback and other queries to
news-admin AT louisepryor.com. (Change ” AT ” to “@”). Archives at
http://www.louisepryor.com/newsArchive.do.

Categories
Newsletter Old site

Newsletter Oct 2005

News update 2005-10: October 2005
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe AT louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe AT
louisepryor.com. (Change ” AT ” to “@”). Newsletter archived at
http://www.louisepryor.com/newsArchive.do.

In this issue:
1. Reputation risk
2. Blackberry jam
3. Where does the buck stop?
4. If it can go wrong…
5. Newsletter information

===============
1. Reputation risk

It’s early days yet, but it looks as if Southern Water are handling
a big problem well. The story so far: Southern Water were
implementing a new billing system. Among the checks that they
performed as they did so, they reconciled the results that it
produced for various aspects of customer service to the known
results. They found that the new system showed much larger numbers
of customer complaints than they were expecting. They called
auditors in, to check that there was indeed something wrong, and
then reported the problem to Ofwat (the water industry regulator)
and the Serious Fraud Office. Southern Water have asked external
lawyers and accountants to conduct an investigation to examine
“certain inconsistencies” in internal procedures.

The number of customer complaints, and how they are handled, is an
important issue because as part of the regulatory framework water
companies are required to handle complaints in a timely manner, pay
compensation to customers when they fail to do so, and turn in a
report to Ofwat each year with details of numbers of complaints,
how quickly they were handled, and so on. Last year’s report showed
that all 2,500 written complaints received by Southern Water were
replied to within 10 days (the customer gets compensation if it
takes longer). In fact, it now appears that there were closer to
8,000 written complaints, not all of which received timely
replies. In addition, there were other forms of compensation that
had not been paid to customers, for things such as failed
supplies. The current estimate of the outstanding compensation bill
is £2.5m.

In the radio interview that I heard, Les Dawson, the new MD of
Southern Water (this all happened less than a week after he was
appointed) was pressed hard to say what had gone wrong, and who was
responsible. He very reasonably pointed out that the point of
having an investigation was to find these things out. If Southern
Water had stayed quiet about this until after the investigation,
they would have been accused of hiding it.

This episode does, I think, have wider implications. First, the
report the water companies have to submit to Ofwat is externally
audited. So as well as the investigation into internal procedures,
questions will have to be asked about how the auditors were
misled. Second, there are other non-financial reports made to
regulators in other industries. I should imagine (and hope) that
some hasty checking is going on all over the land. Third, it shows
the value of performing proper checks and tests when implementing
new systems. It was obviously some kind of regression testing that
exposed the problem. Also, when you perform regression testing, you
shouldn’t necessarily assume that a difference shows that there is
a problem in the new system. Finally, you have to wait for the
results of an investigation before being able to say what its
conclusions are. We just do not know yet how the problem arose:
incompetence, fraud, poor systems design, or something else.

http://tinyurl.com/96v3x
http://news.independent.co.uk/business/news/article322320.ece

===============
2. Blackberry jam

Are you one of those people who is almost physically addicted to
your Blackberry? Never go anywhere without it, and check for new
emails every five minutes? Then be thankful that you don’t work for
the BBC, which has suspended its Blackberry service. Apparently
they were getting the equivalent of crossed lines: people reported
receiving parts of messages not intended for them. When the problem
became known, users started frantically checking that they had not
sent any confidential or potentially embarrassing messages that
could have gone astray. Apparently the service has now been down
for a week, and it is likely to stay down for at least another
fortnight.

I haven’t been able to find anything out about what the problem is,
except that there was one reference to an “obscure bug.” Well,
that’s all right then. If it’s obscure, it can’t matter too
much. Actually, no. In this case, obscure probably just means “it’s
not something we thought of checking,” or “it can only happen in
really weird circumstances, which turn out to have actually
occurred.”

I also don’t know where the problem is: in the Blackberry software
itself, in the BBC’s email system (run by Siemens), or somewhere in
Vodaphone’s systems (who supply the wireless bit). If it’s in the
Blackberry software itself (or in Vodaphone’s systems), a lot of
users should be very worried indeed. If it’s in the BBC’s email
system, which from some hints in some of the press coverage seems
the most likely, the problem is less wide ranging, but could still
affect other organisations using the same type of email system.

This episode shows that you can never be sure that complex systems
will work properly. Presumably the BBC folk had been happily using
their Blackberries for some time, with no obvious signs that there
was anything wrong. Then, probably, some small change was made to
the system, that wasn’t expected to have any very serious effects,
and hey presto! Little fragments of stray emails all over the
place.

Meanwhile, people at the BBC are having to slum it with other,
older, technology: phones and computers.

http://www.guardian.co.uk/uk_news/story/0,3604,1601142,00.html

===============
3. Where does the buck stop?

Whose fault is it when there is a security hole in a piece of
software, or an implementation bug in a financial model? A former
White House cybersecurity adviser recently said that software
developers should be personally responsible for security holes in
the software they write. Howard Schmidt said “In software
development, we need to have personal quality assurances from
developers that the code they write is secure.”

Although this idea may seem attractive at first, it shows a
misunderstanding of how software is written. It is only rarely that
a single person is responsible for all aspects of code design and
development.

On a large project, there might be the following people involved:
business analyst, software architect, lead developer, several other
developers, database specialist, usability specialist. For some
projects there may be more. In addition, there may be inputs from
the marketing and quality assurance (testing) teams. Even during
code development (leaving aside the specification and design
stages) there may be collaboration between developers, and formal
code reviews. How can you possibly assign the blame for any
problems to a single person?

Even pinning it down to a small group is difficult, as there are so
many different influences affecting the final form of the
code. Whatever the size of the project (a single spreadsheet
through to an enterprise level software solution) there are always
trade-offs between the functionality that is included, the
usability, the delivery time, and the level of testing and
review. The developers often feel that the marketing folk are the
most responsible for errors: if they hadn’t promised the
impossible, the developers might have been able to deliver a
quality version of the possible. It is unreasonable to give the
responsibility for errors to a group of people if you don’t also
make it possible for them to deliver an error-free product, for
example by giving them enough time and budget to do so.

Even when there is just one person developing a simple spreadsheet
there would often be a good argument that the developer should not
be held responsible for all the mistakes. If there is intense
pressure to produce an answer to a deadline, there may not be time
to perform all the necessary testing and reviewing. The corporate
culture may not encourage (or even discourage) a disciplined
approach to spreadsheet development. The developer may have had no
training in software development techniques (after all, anyone can
write a spreadsheet, can’t they?)

Although spreadsheets are often used as part of routine business
processes, they have often not been through the type of quality
control that other software has. Again, it may not be the fault of
the individual developer, but the fault of the managers who don’t
understand the risks involved.

If you would like to know how I can help you have more confidence
in the spreadsheets and other user-developed software that your
organisation uses, send me an email at the address below.

http://news.zdnet.co.uk/0,39020330,39228663,00.htm

===============
4. If it can go wrong…

You may have noticed that there has been a slight hitch in the
monotonous regularity with which these newsletters appear. One
thing I have learned over the past few months is not to take things
for granted. For example, don’t assume that getting your boiler
serviced just after major house redecoration is a mere
formality. You might find that you have a blocked flue and have to
resite the boiler. A house sale can fall through up to about three
weeks before the moving date (and possibly later, though I don’t
have an actual example of that). Even if you are generally healthy,
don’t assume that you won’t break your leg just before you move
house. Just because both BT and your ISP say that your line is
fine, it doesn’t mean that either ADSL or dial-up will actually
work without a visit from the BT engineer. However, normal service
has now been resumed, and we apologise for any inconvenience
caused.

As ever, if you have any comments on any items in this newsletter,
or any suggestions for future issues, just drop me an email at the
address below.

===============
5. Newsletter information

This newsletter is issued approximately monthly by Louise Pryor
(http://www.louisepryor.com). Copyright (c) Louise Pryor 2005. All
rights reserved. You may distribute it in whole or in part as long
as this notice is included. To subscribe, email news-subscribe AT
louisepryor.com. To unsubscribe, email news-unsubscribe AT
louisepryor.com. All comments, feedback and other queries to
news-admin AT louisepryor.com. (Change ” AT ” to “@”). Archives at
http://www.louisepryor.com/newsArchive.do.

Categories
Newsletter Old site

Newsletter Jun 2005

News update 2005-06: June 2005
===================

A monthly newsletter on risk management in financial services,
operational risk and user-developed software from Louise Pryor
(http://www.louisepryor.com).

Comments and feedback to news-admin@louisepryor.com. Please tell me if
you don’t want to be quoted.

Subscribe by sending an email to news-subscribe AT louisepryor.com.
Unsubscribe by sending an email to news-unsubscribe AT
louisepryor.com. (Change ” AT ” to “@”). Newsletter archived at
http://www.louisepryor.com/newsArchive.do.

In this issue:
1. Hidden text and meta-data
2. What is a spreadsheet?
3. Forthcoming events
4. Phishing
5. Newsletter information

===============
1. Hidden text and meta-data

Every so often there is an article in the press about hidden text
being left in a file that is released to the public: it usually
involves a Word file, but it’s possible for the same sort of thing
to happen in Excel, or even PowerPoint, too. For instance, in April
the Pru managed to send out a version of their first-quarter new
business figures in which recipients could see many of the changes
that had been made during the preparation of the document. It’s not
only text from previous drafts that may be present for all to see,
but also other information, such as the original author of the
document.

I am always slightly surprised that important documents are sent
out as Word or Excel files in the first place: surely a format that
is intended to be edited just isn’t suitable, unless you want the
recipients to edit it? Just think of the risks that may arise if
the recipient can either edit the file or see changes that were
made in the past. You may be misrepresented, fraudulent use made of
the modified documents, confidential information may leak, and so
on. Although there has as yet been no big scandal from this sort of
problem, I am sure that there are many more occurrences and many
more problems, some of them resulting in monetary losses, than we
hear about in the press.

There are some simple steps that can be taken to minimise the
risks. They are not foolproof, but add little extra burden on to
the user (so are at least practical to apply). Useful techniques
include:

– Password protect the file to make it read-only. This doesn’t
provide a lot of protection (Microsoft Office passwords are
generally easy to break, and it’s possible simply to cut and
paste the contents into another document) but does at least stop
inadvertent changes.

– Use the options that Word and Excel have to “Remove personal
information from file properties on save”.

– Use the Word option to “Warn before printing, saving or sending a
file that contains tracked changes or comments”. To remove
tracked changes, accept them all and turn tracking off before
saving.

– Don’t allow fast saves in Word: if these are enabled, old text
may be saved even if you don’t track changes.

– In Excel, protect sheets and workbook structure so that users
can’t make unwanted changes.

– Use Microsoft’s “Remove Hidden Data” add-in, which lets you
remove hidden data from Word, Excel and PowerPoint files.

– Send out pdf files instead. Although it is possible to edit these
if you have the right software, most people can only read
them. There are various ways of producing pdf files, including
some commercial software packages, but the easiest is to install
a free package like pdf995, PrimoPDF, or CutePDF Writer. These
add an option to your list of printers, so that instead of
printing to paper you print to the pdf creator which makes a pdf
file.

http://makeashorterlink.com/?C1CF23A4B (Pru’s new business figures)
http://makeashorterlink.com/?A27814267 (Microsoft’s add-in)
http://www.pdf995.com/
http://www.primopdf.com/
http://www.cutepdf.com/

===============
2. What is a spreadsheet?

How many spreadsheets do you have in your organisation? In your
department? On your machine? It’s a tricky question to answer: it
depends on what you mean by a spreadsheet.

You could simply count the files that have an extension of “.xls”
(assuming you use Excel). But then you may well be double counting,
especially if you are a careful person and save interim versions as
you develop a complex spreadsheet. It’s also possible (though
unlikely) that some other application creates files with the same
extension as .xls files. You may be under-counting, if some files
are zipped up to save disk space.

Then there are those half-worked out spreadsheets that were never
actually used for anything, and the others that simply served
instead of the back of an envelope.

And what about all those spreadsheets that are nearly but not quite
the same? Ones that do essentially the same calculations, but on
different data–perhaps for monthly reporting, or for pricing
potential contracts. In many cases these are derived from a central
template, or simply from last month’s version.

Another complication is raised by files that have the same name but
different contents. A naive way of counting might assume that they
are in fact the same spreadsheet, when in fact they might come into
the previous group (same calculations on different data) or might
simply have been given the same name by accident, and in fact
contain totally different calculations.

Of course, the actual count probably doesn’t matter too much in the
end. What does matter is that you know what spreadsheets there are,
what they are used for, and how they are related. It’s important to
have good processes in place both for developing them and keeping
track of them. For instance, if you use a template for pricing, you
should know for any given spreadsheet whether it was derived from
that template, and if so what version of the template, and if there
were any changes from the template. All this is important if you
want to be sure of the results coming out of the spreadsheets. You
must to be able to trace back from the results to the data and
assumptions, and to be able to trust the calculations that are
performed. If you can’t do this, you may run foul of Sarbanes-Oxley
(if it applies to you) or of the FSA, who consistently stress the
importance of systems and controls, especially in ICAS work.

There are a number of techniques you can use to do this, including
documentation inside the spreadsheets themselves, using
systematic naming conventions for both files and folders, and
having good backup and archiving processes. Poor naming conventions
can lead to big problems: natural gas prices in the USA were
significantly affected when a company submitted the wrong week’s
gas storage figures in November 2004. “One explanation for the
error was that the company had used the same computer file name for
each week’s storage balance report, making it easy for the wrong
one to be sent.” Not only easy, but positively likely, I should
have thought. Apparently the company in question has now changed
its naming conventions. (Thanks to Patrick O’Beirne for noticing
this report, and posting it on the EuSpRIG spreadsheet errors
page).

http://makeashorterlink.com/?W65C21A4B
http://www.eusprig.org/stories.htm

===============
3. Forthcoming events

The 2005 EuSpRIG conference is being held at the University of
Greenwich on 7th and 8th July. Details are at
http://www.eusprig.org/ . The theme this year is “Managing
Spreadsheets in the light of Sarbanes-Oxley”, so it promises to be
both interesting and timely.

The FSA is holding a summer school from 21st-24th August at St
John’s College, Cambridge. Its aim is “To provide firms with a
unique insight into strategic thinking of senior levels within the
FSA.” There will be presentations from senior FSA staff, and some
case study work in small groups. Details are at
http://www.fsa.gov.uk/Pages/Doing/Events/events/summer.shtml .

There is a half day seminar on “The strategic management of risks”
at the Institute of Actuaries in London on 23rd November. Details
are at
http://www.actuaries.org.uk/files/pdf/cpd/risks_seminar_20051123.pdf

The Actuarial profession will be holding a seminar on Operational
Risk in December; no details have yet been announced.

===============
4. Phishing

There is so much phishing spam at the moment that sensible people
won’t reply to, or click on any link in, any email from a financial
institution. Many of them rely on people reading their email in
html: I read mine in plain text, and the links in the emails are
often perfectly genuine. It’s only in the html, in which the
highlighted text need have nothing to do with the actual link that
will be used, that the danger applies. Even then, some simple
observation will often indicate that something is wrong. When I
view email in html, and hover the cursor over a link (without
clicking) the link destination is displayed. If it is not the same
as the text of the link, smell fish!

Phishing isn’t limited to email, either. I recently received a
telephone call purporting to be from a bank with whom I have a
credit card, saying that they had noticed possible fraudulent
activity on my account. Would I give them the day and month of my
birthday in order that they could be sure they were speaking to the
correct person? Well, no, I wouldn’t. But it wasn’t my full birth
date, only the day and month. I still refused, and asked if there
was a number I could call them back on so that I could be sure I
really was talking to the bank. They gave me an 0845 number, but it
just got through to a recorded message. I later checked this out
with the real bank, and they confirmed that it was a scam, and that
the number was not one of theirs.

Apparently techniques similar to those used in phishing attacks are
now being used to gather commercially or economical valuable
information from companies. The National Infrastructure Security
Co-ordination Centre (NISCC) has recently issued an alert
describing these attacks. The alert says:

“The emails employ social engineering, including use of a spoofed
sender address and information relevant to the recipient’s job or
interests to entice them into opening the documents.

“Once installed on a user machine, trojans may be used to obtain
passwords, scan networks, exfiltrate information and launch further
attacks.”

Apparently the attacks, which appear to originate in the Far East,
normally focus on people who work with commercially or economically
sensitive data.

Just like phishing, these attacks rely on the unwitting cooperation
of the recipient of the email. As a reminder, NISCC confirms that
the following precautions are sensible:

– Don’t open attachments unless the email is consistent with
previous communications from the sender, and the attachment has
been scanned for viruses

– Don’t use the preview pane in your email program

– View emails in plain text, not html

These are all precautions that the home user should take, too. In
addition, you should make sure that you use a good virus and
malware detection program on your home machine, and have applied
all security updates to your operating system and other software.

As an aside, the phishing problem is the reason that I now use
www.makeashorterlink.com to abbreviate URLs. When you click on one
of their links, you will be shown the actual URL before you are
taken to the page.

http://www.niscc.gov.uk/niscc/docs/ttea.pdf

===============
5. Newsletter information

This newsletter is issued approximately monthly by Louise Pryor
(http://www.louisepryor.com). Copyright (c) Louise Pryor 2005. All
rights reserved. You may distribute it in whole or in part as long
as this notice is included. To subscribe, email news-subscribe AT
louisepryor.com. To unsubscribe, email news-unsubscribe AT
louisepryor.com. All comments, feedback and other queries to
news-admin AT louisepryor.com. (Change ” AT ” to “@”). Archives at
http://www.louisepryor.com/newsArchive.do.