Many contributors have posted comments on this subject during the last few
days and the postings have divided between those who feel they have to have
source and those who dont. Both groups have offered views which have merit
and reflect their individual backgrounds.
Having spent a few decades working on security issues, lurking on this list
is been very interesting. One thing I have seen is people re-discovering
techniques and technologies which were first discovered a long time ago.
Much of my experience has been in the military and intelligence environments
for the simple reason that these were the markets prepared/forced to spend
time and money on addressing IT security. The communities have built up
considerable experience but that doesnt mean they are right in the views
they hold.
The dismissal of 'security through obscurity' is not entirely well founded.
Having worked in three different environments I have found good points in
each and it would be great if the best items could be collected together and
the worst dumped. That may not be practical because of the different
cultures.
What the long established security users did was to establish standards and
test criteria. The concept was sound even if the practice is not always
good. The main draw back of security criteria has been that an incorrect
model of the IT industry is used. In the early days, and in terms of
government procurement, the model was not that bad, but it doesnt hold up in
today's COTS environment and the widespread use of public information
highways.
Part of the underlying rules of security criteria assumed that the vendors
would be companies which had been carefully investigated and that all
employees had been vetted so that there was a basic level of trust which
could be applied to human aspects. That was fine when only a handful of
companies offered products of this type and usually kept the people in a
small tightly controled division. Thats not very practical in an
environment such as Inet where there are armies of consultants selling their
'expertise' and each day sees a new vendor appearing with some sort of
product or tool kit. In this environment customers can have very real
difficulties in deciding who to believe and for many source is not much more
than a comfort factor. Buying source presumes that there is an employee with
both the time and the experience to benefit from it.
Having headed a team providing military systems under war conditions where
delivery yesterday was the norm, I know the benefits of a tight central
control but this can be extremely difficult to apply in peacetime and
particularly in commercial organisations where personnel movement and
changing politics create a state of flux and encourage management by
fire-fighting with very short term views. Under tight central control it is
possible to develop and distribute IT products and systems which the users
cannot play with and it is possible to ensure that every user has the same
version of every application. New versions can be issued to every user on
the same day and be loaded at the same time give or take a half hour.
However, that environment demands careful vetting of personnel in the
control team, efficient logistics, total blind obedience and the use of
tightly defined methodologies amongst other things. That would be difficult
to achieve in a commercial environment, not least because very few
corporations would be prepared to fund the central control team necessary,
implement the culture required, accept that level of standardisation and be
able to control the unavoidable external contractors.
Under a central control system, security by obscurity can work. It does mean
that a uniform level of trust is applied but not necessarily the highest
possible level of trust. It demands that the central control is fully
trusted and there is the question of how far an operating system which is
'open' can really be trusted. If a proprietary system is used, such as from
Microsoft, there is also the big question about how far you trust the OS
authors. If the OS is produced under tight controls, which probably means
limited volume is achieved, there may be much more well founded trust than
if the product is produced in volume with frequent issue of new versions.
Where the OS is tightly controled and carefully worked/re-worked for
security, it will soon be a long way behind the functionality levels offered
by untrusted OS. There are some very secure versions of UNIX which have been
evaluated under a security criteria and then maintained through RAMP or its
equivalents. The same authors will also continue to produce their own
untrusted flavour of UNIX. By comparison, the trusted version soon begins to
look obsolete.
Therefore, unless a new more flexible and responsive method of evaluation
can be developed and companies are prepared to introduce highly qualified
central control teams, most of the approaches which have worked reasonably
well for military users are not particularly effective or attractive for
commercial organisations.
But does the possession of source really help the typical commercial users?
Probably not.
Many sites will simply not have the time and skills necessary to fully use
information from multiple locations to maintain and develop the security
abilities of their IT systems. Some information will be provided by people
who do not know what they are doing and will be blindly followed by others
who dont know any better. Where sites do work with source code, a high
proportion will not adequately document what they have done and will not
employ structured or formal methods. In these cases, working with source
will increase risks rather than decrease them.
An academic answer is to test everything until it breaks. Thats fine if you
have plenty of time and know what you are testing for.
It really all comes back to how well you analyse risk and how you produce
your risk policy. If you leap in at the technology stage whatever you do is
likely to be defective. Whatever you do will not be 100%, but without a risk
policy you wont know what you are trying to achieve and where you made
necessary compromises.
Ian J-B.
Follow-Ups:
|
|
