% fortune -ae paul murphy

Questioning IT

This is the 16th excerpt from the first book in the Defen series: The Board Member's IT Brief.

This section is concerned with things you should talk to your CIO about - informally, but with attention.

Topic Two: Maintaining Information Integrity

Mainframe and Client-Server Architectures

The mainframe itself is usually considered very secure but the reasons for that are not the ones the people in the community will usually cite. They'll tell you, for example, about internal hardware redundancies and multi-year failure free "up- times," or about virtualization and the user access controls embedded in the OS and its applications.

Those claims are true - but mostly beside the point. What the PC community means by security: i.e. protection against malware, genuinely isn't an issue for the mainframe - there isn't much mainframe malware, and the batch processing model combines with rigid usage controls to enforce strong protection against software based external attack in mainframe applications.

On the other hand the resulting sense of security can be a dangerous illusion. Basically, the usual PC threats don't apply, but if you deal with real secrets you should be aware that these environments are trivially open to long term penetration by trusted staff with the right skills - in part because the evolution of the data processing organization has focused so much on internal controls that typical management cannot readily comprehend the nature of the threat and therefore denies it.

In contrast malware and simple external attacks dominate information integrity issues in the Microsoft client server architecture. Here your desktops, your servers, and your network gear will be continually subject to relentless attacks from worms, viruses, spyware, and a dozen other forms of "malware." The threat of failure, of worldwide epidemics of failed desktop or server integrity, is a continual fact of life for Windows users -and this week's cure-all magic bullet will inevitably go the way of last week's: you write the check, your IT people work hard on implementation, your environment gets more complex, and the threat re-surfaces somewhere else.

Thus a good Windows CIO asked about systems integrity will simply tell you that PC security is a losing game - he'll talk about the necessity of keeping up with industry norms: about routinized hardware and software upgrades, about patching, about firewalls, anti-virus software, and a whole litany of clever attack notification technologies -and then add that none of this stuff is either sufficient or even demonstrably effective.

As a result the critical issues you want to hear your Microsoft centric CIO talk about are things like legal protections (liability disclaimers, published non-confidentiality policies), user notification policies (how to tell your customers when it happens to data about them), and asset management systems that actively track things like backup tapes, laptops, or wireless access controllers to trigger remedial action when these are stolen or lost.

Most should, furthermore, mention having identified and empowered a security "czar" whose word carries the weight of the CIO's office on desktop and server security related matters.

You should also expect to hear a bit about palliative steps like permanent network disconnection on machines handling obviously sensitive data, or the default use of "no permits" (controls on what can't be run or transmitted based on allowing only explicitly authorized applications).

In general, however, PC environment systems integrity work is an after the fact business - necessarily aimed far more at living with loss than preventing it.

Unix Architectures

At present, (spring 2008) Linux and older Macintosh computers continue to enjoy almost total immunity from much of the malware plaguing the PC world. Whether that changes as market share increases remains to be seen.

The pure Unix model - big servers, smart display desktops- is, in contrast, almost 100% secure in both the PC malware sense and the real data integrity sense, and likely to continue so.

In other words, if your Unix CIO spends more than a minute or two on these issues, you've got a problem: because these things shouldn't be a problem for him.

What you want to hear him talk about instead are internal risks - the things your Wintel CIO never gets to, like enterprise identity management and a general belt and suspenders approach to dealing with the human side of enterprise data integrity.


Some notes:

  1. These excerpts don't include footnotes and most illustrations have been dropped as simply too hard to insert correctly. (The wordpress html "editor" as used here enables a limited html subset and is implemented to force frustrations like the CPM line delimiters from MS-DOS).

  2. The feedback I'm looking for is what you guys do best: call me on mistakes, add thoughts/corrections on stuff I've missed or gotten wrong, and generally help make the thing better.

  3. When I make changes suggested in the comments, I make those changes only in the original, not in the excerpts reproduced here.

Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.