 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
SECURITY LAB SEMINAR
June 2, 1999
1-2pm
1131 EU II
Scott Miller leads a discussion on corporate network security policies.
Scott has been working on developing security policies for a large corporate business - National Semiconductor Service. There is a manager/administrator for each host, but no one is keen on everything. The focus of the discussion is on brainstorming policies, tools to use, things to specify etc., given the following representation of the network. Policy is loosely defined as an approach or procedure that will be followed.
|
|
|
|
|
| Local/Domain administrators are responsible for obtaining and installing patches for all applications when a security alert is issued | Prevent moderately competent hackers from compromising host redundancies | IS Host will run vulnerabilities tools | Time, Cost, Staying current, how to install patches |
| Central administration handles security of all computers on all hosts | Prevent moderately competent hackers from compromising host redundancies | IS Host will run vulnerabilities tools
Protocols, make patches available |
Feasible to upload patches to central authority? Redundancies of work, getting local administrators approval |
| Central administration provides patches at central location | Prevent moderately competent hackers from compromising host redundancies | IS Host will run vulnerabilities tools | Understand how patches interact with each system |
| Apply no patches | Save money, time | ||
| Securing communication: network based protocols | Prevent password sniffing, login hijacking, content sniffing, spoofing. Ensure integrity of messages, traffic flow analysis, authentication (public key infrastructures) | SSH, SSL, Virtual private networking, Stick internal firewalls on IDS, block use of ports 23 and 21 | Key management, compatibility with external protocols (other applications can't use it), key recovery, sharing (Tuomas objects - never need to share communication keys), performance, reliability of security enforcement |
| Ensure availability of bandwidth | Redundant server links, RSVP, backups | ||
| Labeling of data, organization, classification | |||
| Put IDS everywhere | |||
| Access Policy - Discretionary access control | Screening routing, firewalls | How to maintain a list |
Questions/Comments:
TA: You need an extra column for support mechanisms
MB: A policy is a statement of hope, rather than a statement of fact.
KL: Debate policies - X host compromised by competition
CW: Similar situation with systems that are not Y2K compliant. They
decommission them, sell them to competitors, merge with other companies,
etc.
NP: The relationship the local administrators have with the central
group is critical.
MB: There could be a huge problem if hackers break into the central
group and replace patches with malicious programs.
TA: You can require administrators to apply patches, because you can't
monitor them.
CW: If you can't use certain types of applications, the benefit to be
gained by not applying the patches may outweigh the risk.
DK: What if a local branch must run an application or an old system
to function?
CW: The company would look at the revenue being produced by that branch
and decide whether to eliminate it.
JH: Security options to use
CW: Financial transactions can't use enforcement mechanisms. It changes
the mechanism too much, the legal liability, and cost too much considering
there may be billions of transactions/day.
KL: Use a modem as backup? CW: Garfinkle has a paper on modem auditing
TA: Classification of documents
CW: Employee turnover is an issue
TA: A recovery plan is necessary. Most companies do not have one.