Some Brief Ideas for Corporate Security
John M. Salomon


I.	What

Many Organizations seem to ask themselves how to go about information
security.  The "whether", or "why" no longer are really an issue.

This is an attempt to suggest a rough organizational structure for 
a corporate IT security division.  Furthermore, I would like to
make a few observations on security organization and operations
based on my daily personal experiences in network security.

Please bear in mind that I am not a manager, I have the chutzpah
to call myself an engineer, and I am incredibly opinionated,
and in many areas, quite possibly ignorant.  That said, have fun.

II.	How

Let's have a look at how the Byzantine drama of an IT security
organization unfolds by peeking at its protagonists.  No, they're
not all guys, but ("(s)/he") and its variations grow tedious.

Please reference the accompanying pdf, with which I've tried
to outline the structure I'm about to explain.

	
A. The Management
	
Like it or not, large corporations consist of many layers of politics.
Without going into detail, these are often chracterized by human
greed, vanity, ignorance, suspicion, and venality.  Furthermore,
corporations exist solely for the purpose of making money.  This 
requires large numbers of accountants, part of whose job it is to
save money by not spending money.

An IT Security division, on the other hand, should have as its
goal the protection of assets, whose compromise could have, ultimately,
negative financial consequences for the company.  Such consequences
can include theft of trading data, some sort of exposure of 
embarrassing company secrets, destruction of information-bearing media,
or loss of advantage to a competitor through undesirable transfer of
internal information.  Whatever.  Ours is not to question why...

IT Security costs money.  Unless the corporation's focus is on security,
it does not earn money.  Furthermore, part of IT security's work 
will inevitably involve impedance of project work, which will not make
certain project managers happy.  Hence, Management.

An IT security manager's role is to ensure the awareness of a corporate
upper-level management, and to shield the operational aspects of security
work from the abovementioned politics and accountancy as best possible.
He should be able to sell recommendations and policies based on technical
analyses to the corporation as a whole, and supply his group with the clout
required to effectively fulfill its daily role.  In short, act as a shield
from all the bad bits that could prevent IT security from working well, 
or which might divert its attention to nonessential tasks.  This will
most likely be a very thankless task, which is why we hire very serious,
conniving, and dedicated characters for this job, and pay them a lot of money.

	
B. The Consultants
	
These are the ladies and gentlemen who advise and consent.  They set policies
based on the very high-level mission-statement-type things released by upper
management.  The consultants' job is mainly theoretical;  that is, they set
guidelines within which technical design work is done.  

Their role is threefold:  first, they should create and distill the sort of
information their boss can use to support his points to senior management, and 
thus to the rest of the company.  They should be able to give the technical-yet-
not-too-technical type of information required at management meetings.

Second, the consulting staff should be able to "sell" and explain the IT security 
group's policies to other teams and organization units around the company.
This includes presentations and documentation for technical staff, end users,
and management.

Lastly, the consultancy team must act as a resource for the more technically
oriented parts of the IT security group.  They are thus essentially a diplomatic
corps liaising with all the individuals involved in the security decision-making, 
design, implementation, and usage process.

The good consultant should be a generalist with a technical background.  You also
want to pay these people well, as this of position is a potential breeding
ground for just the sort of management flunkie an effective IT security organization
needs must avoid at all costs.  

	
C. The Technical Experts
	
The third group involved in the security organization is expected to advise the
technical design and implementation teams on a theoretical basis.  These individuals
sould possess strong technical backgrounds, and realize the broader implications of 
any design or architecture.  

The job of a technical expert is threefold;  first, he should act as a "competence
center", for the engineers and technicians he works with.  A specialist in his area,
he must be able to track down answers to arcane technical questions, and serve
as a helpdesk of last resort for high-level or extremely in-depth technical questions.

Additionally, the technical expert's job is to review any new designs for
possible security flaws.  He may be the last pair of eyes to review a planned
implementation or standard before it is put into production.  Hence, he may 
be called upon to take a leading role in the evaluation of new security-related
products.

Finally, the expert's job is to review and detect flaws in any application
used by the corporation--while it is unreasonable to expect a line-by-line source
code review of every proprietary product to walk through a company's doors, 
there exists a wealth of information on the internet and in professional publications
related to newly discovered security vulnerabilities and recommended fixes.  
Most systems administrators are too thinly spread and harried to constantly keep up
with all new technical developments in their fields, especially where "only"
security, as opposed to functionality and reliability, is concerned;  they
have a center of expertise which presents them with digests and summaries of 
security vulnerabilities, and suggested fixes, it makes their job a lot easier.

Needless to say, these people should be spending a great majority of their team
reading web pages and usenet newsgroups, and attending training sessions;  they
should have an extremely strong background in their particular field.

	
D. The Engineers
	
These are the designers, the creators, the doers of the whole shop.  The engineering
teams' task consists entirely of the technical side of things.  They liaise with
the technical expert group to design new infrastructures, help evaluate and
test new products, and implement and install things.  

The engineering group should be reasonably specialized on its area of focus,
but broadly experienced enough to be able to lend a hand in other areas of 
security technology, should it be needed.  They will create templates for 
configurations, build prototype installations of security-related technology,
and act as both a training source for technical support teams when new products
are introduced, and as a higher-level support outfit for helpdesks and technical
teams.  

For example, this team might evaluate a new firewall platform, figure out how
to roll it out in the corporate environment, create standardized installations
and documentation for its handling, and actually administer the package
while handing it over to an operations team.  Furthermore, they could deal
with complex infrastructure changes, and field "advanced" queries from
frontline support staff, which may not be immediately evident in the 
documentation.  


This work is in progress
Copyright March 2002, John Morgan Salomon