[793] in Kerberos_V5_Development
DECinspect VMS, ULTRIX, SUN and DECsrf VMS - Field Test Site Solicitation Memo
daemon@ATHENA.MIT.EDU (NORMA DONAHUE 226-6597 07-Jan-199)
Tue Jan 7 20:44:36 1992
Date: Tue, 7 Jan 92 11:16:05 PST
From: NORMA DONAHUE 226-6597 07-Jan-1992 1301 <donahue@ultra.enet.dec.com>
To: mail11:;@enet-gw.pa.dec.com@enet-gw.pa.dec.com (@di_srf_ft)
Cc: donahue@ultra.enet.dec.com
Apparently-To: distribution:;@enet-gw.pa.dec.com@enet-gw.pa.dec.com (see end of body)
+---------------------------+ TM
| | | | | | | |
| d | i | g | i | t | a | l |
| | | | | | | |
+---------------------------+
TO:* Distribution *DATE: 7-January-1992
*FROM: Norma Donahue
*DEPT: Secure Systems Group
*DTN: 226-6597
*OUTSIDE: (508) 486-6597
*MAIL STOP: LTN1-1/C07
*ENET: ULTRA::DONAHUE
*INTERNET: DONAHUE@ULTRA.ENET.DEC.COM
*SUBJECT:* Opportunity to Gain an Advantage in System Security -
DECinspect and DECsrf Field Test Nominations
Information system security is an increasingly important customer concern
as an integral element of system management of networked multi-vendor
systems. Increasing numbers of our key customers are saying that they want
better control of security in their network computing environment while
reducing the overhead required to manage it.
Digital's DECinspect and DECsrf products are already helping several of our
key customers implement and maintain better security consistently on their
networked systems. This is a good start -- but to ensure that Digital
becomes and remains a top rated vendor of information systems, we need to
help our customers address these issues for other platforms as well.
We are in the process of making these tools available on other systems
including ULTRIX, SunOS, IBM AIX, PC Network Operating Systems, and others.
To help establish Digital as the leading vendor in this area, both in your
account and as a corporation, we need your help in getting your account
signed as a field test for the new offerings. Being a field test site not
only helps Digital ensure it has a quality winning product, but also gives
you a competitive advantage into this growing area.
Current field tests include DECinspect/ULTRIX V1.0 and DECsrf/VMS V1.2. In
February 1992 we will begin field testing DECinspect/VMS V2.2,
DECinspect/Sun V1.0 and DECsrf/VMS V1.3.
In order to provide you with more information about these products and
their underlying technology, product descriptions are attached to this
memo.
If you have a customer that may be interested, please return the attached
Field Test Nomination form to me AS SOON AS POSSIBLE. Field Test Licensing
is a lengthy process, so an expeditious reply would be most helpful.
If you have any questions, don't hesitate to contact me, information is
provided above.
Regards,
Norma Donahue
Field Test Coordinator
DECinspect - Product Description
DECinspect is a software tool that a security or system
manager uses to establish a custom security analysis and report-
ing system to manage the security of a network of distributed
systems. With this tool, the security manager can implement and
maintain a security standard that is consistent with corporate
security policy for nodes in the distributed computing
environment. Digital highly recommends that customers purchase
security consulting services for assistance in designing and
implementing a security analysis and reporting system that bal-
ances business needs with security requirements. Local Digital
offices can assist customers in determining the appropriate
services for their requirements.
DECinspect software is designed to run on every node in a network
to periodically evaluate compliance with a security policy
defined by the security manager. Optionally, DECinspect
software will work with DEC Security Reporting Facility (DECsrf)
software (SPD 26.N2.xx). DECsrf software is designed to run
on one or more nodes to support centralized collection and
management of compliance reports from DECinspect installations.
Using DECinspect software, the security manager defines set-
tings (that are consistent with the organization's security
policy) for the security-relevant operating system parameters.
DECinspect software establishes processes, called inspectors,
to periodically evaluate the node for compliance with the es-
tablished parameter settings - an inspection. Inspector tests
will evaluate security-relevant parameters in the following
areas:
o Files and directories
o Accounts
o Network connections - TCP/IP and DECnet
o LAT connections
o Auditing
Each DECinspect installation will have a Required Inspector
that evaluates the complete set of parameters on a schedule set
by the security manager. In addition, the security manager may
establish other inspectors to evaluate any set of the parame-
ters, on any required schedule. As inspectors run, DECinspect
software:
o Provides detailed evaluation reports to the local security
manager
o Transmits full evaluation reports to a mail distribution
list (DECnet or IP) established by the local security manager
o Generates a procedure (known as a lockdown file) that can be
run to adjust parameters automatically for compliance with the
security policy
o Reports summary evaluation results to central security man-
agement locations supported by DECsrf software (Required
Inspector only)
After each inspection is completed, the inspector generates a
detailed report indicating the success or failure of each test
performed. By default, the report is mailed to the root ac-
count or the user who initiated the inspector. The detailed re-
ports can also be sent to any electronic mail address specified
on the inspector's distribution list by the security manager.
Lockdown files consist of commands that reset system parameters
to comply with the security policy in force.
Note: Lockdown command procedures should never be run without
assessing the impact of parameter changes to system operations.
Each command in a lockdown command procedure should be examined
to make sure that the suggested solution is compatible with the
particular environment.
The Required Inspector optionally generates summary security
status messages called tokens, which contain a summary of the
inspection of the complete set of security-relevant parameters.
DECinspect software sends the tokens to a central collection
point - a node running the DECsrf security reporting software.
While DECinspect can be used alone in small distributed systems,
managing a large number of nodes or a set of nodes on a dis-
persed network can be very difficult. DECsrf software supports
centralized management for distributed DECinspect client nodes.
DECsrf software extracts data from tokens and maintains this
compliance data in a relational database for management report-
ing. For more information about managing network security with
DECinspect and DECsrf software, see the DEC Security Reporting
Facility for VMS Software Product Description (SPD 26.N2.xx).
DEC Security Reporting Facility (DECsrf) for VMS - Product Description
DEC Security Reporting Facility for VMS (DECsrf) is a software
tool that a security or system manager uses, in conjunction
with DECinspect software (SPD 26.N1.xx), to establish a custom
security analysis and reporting system to manage the security
of a network of distributed systems. With these tools, the
security manager can implement and maintain a security standard
that is consistent with corporate security policy for the VMS
nodes in the distributed computing environment. Digital highly
recommends that customers purchase security consulting services
for assistance in designing and implementing a security analysis
and reporting system that balances business needs with security
requirements. Local Digital offices can assist customers in
determining the appropriate services for their requirements.
DECsrf software is designed to run on one or more nodes to sup-
port centralized collection and management of compliance reports
from DECinspect installations. DECinspect software is designed
to run on every node in a network to periodically evaluate com-
pliance with a security policy defined by the security manager.
Optionally, DECinspect software can be configured to send
summary security status messages (called tokens) to a DECsrf
installation. While DECinspect can be used alone in small dis-
tributed systems, managing a large number of nodes or a set of
nodes on a dispersed network can be very difficult. DECsrf cen-
tralized management capabilities can be very helpful in these
situations.
If centralized management is desired, the customer will estab-
lish one or more DECsrf installations on the network. Typically,
DECsrf installations will be set up to support the organiza-
tional reporting structure (e.g., one DECsrf node per organiza-
tional management domain). The specific DECsrf installation that
a DECinspect node reports to is specified during installation
of the DECinspect software. DECsrf software performs integrity
checks to prevent unauthorized modification of token information
during transmission from DECinspect installations.
Once the system is configured, the DECsrf software collects the
tokens and stores the compliance data in a relational data base
automatically. The DECsrf compliance data includes:
o Node name
o Network address
o Hardware type
o Cluster name (if a cluster member)
o Inspect version
o Operating system version
o Token date and time
o Parameter file identifier and information for validation
o Required Inspector test result summary
DECsrf compliance data are stored so that designated users can
access current as well as historical data to monitor the secu-
rity compliance of nodes on the network. In addition to display-
ing the security status of any network node within the manage-
ment domain of a particular DECsrf installation, the security
manager can use the DECsrf software to do the following:
o Display and print information from the DECsrf database.
o Send noncompliance memos, which report the tests that failed
on each node, to system and security managers automatically
via electronic mail.
o Generate late-token memos, which list any nodes that fail to
send a token within a specified time interval.
o Produce executive summary reports that list the percentage of
nodes in a network that conform to the security standard in
force.
o Forward tokens to another DECsrf installation automatically.
A reporting structure consistent with the customer's orga-
nizational structure (e.g., hierarchical or matrix) can be
established by the use of multiple DECsrf nodes.
o Store and access data about the responsible manager for a
node or a group of nodes.
o Store and access data about valid parameter files used by the
nodes running DECinspect software. DECinspect parameter files
contain the settings established by the security manager
consistent with the organization's security policy. DECsrf
and DECinspect are designed to work together to perform
integrity checks to protect against unauthorized modification
of DECinspect parameter files.
o Schedule tasks, such as producing reports or forwarding
tokens, to run automatically.
o Purge old tokens from the DECsrf database.
The security managers can also write their own programs to ex-
tract data from other sources for storage in the DECsrf database
as well as produce other DECsrf reports using any of the follow-
ing Digital software products.
RDO and SQL utilities of VAX Rdb/VMS (SPD 25.59.xx)
VAX Rdb/VMS precompilers (SPD 25.59.xx)
VAX DATATRIEVE (SPD 25.44.xx)
VAX RALLY (SPD 27.03.xx)
VAX TEAMDATA (SPD 27.02.xx)
DECdecision (SPD 25.62.xx)
Field Test Site Nomination Form
Please check all products that your customer is interested in
field testing.
_ DECinspect for ULTRIX V1.0
_ DECinspect for VMS V2.2
_ DECinspect for SUN V1.0
_ DECsrf for VMS V1.3
Field Test Site Name:
Business Contact should be an individual who will be responsible for Field
Test Agreement signatures, legal documents, correspondence, etc.
Business Contact Name:
Business Contact Phone:
Business Contact Address1:
Business Contact Address2:
Business Contact Address3:
(Include mail stop, if applicable)
Technical Contact should be an individual who will be responsible for all
technical aspects of this field test, such as, Field Test Kit installation,
problem reporting, etc.
Technical Contact Name:
Technical Contact Phone:
Technical Contact Address1:
Technical Contact Address2:
Technical Contact Address3:
(Include mail stop, if applicable)
Technical Shipping Address1:
Technical Shipping Address2:
Technical Shipping Address3:
Technical Shipping Address4:
(No P.O. Boxes will be accepted)
DEC Sales Acct Mgr:
DTN:
Email Address:
DEC CS Unit Mgr:
DTN:
Email Address:
Local DEC CS Rep:
DTN:
Email Address:
DEC SWS Unit Mgr:
DTN:
Email Address:
Describe the basic environment, including number of users, ULTRIX systems,
specify VAX and/or RISC, TCP/IP and/or DECnet, PCs, workstations, etc.
An explanation of your organization and their interest in DECinspect and
DECsrf would be helpful, also.
Thank you
%%% overflow headers %%%
Apparently-To: jis@athena.mit.edu, krbdev@athena.mit.edu, whrahe@sandia.gov,
jtkohl@athena.mit.edu, klensin@infoods.mit.edu,
skapur@ccmail.sunysb.edu, cason@univrs.decnet.lockheed.com,
dbaron@mit.edu, rayan@cs.toronto.edu, billw@pnet51.orb.mn.org,
jpw@vax135.att.com, ckwong@ana.com, whaley@ucs.ubc.ca,
sanjay.waghray@cs.cmu.edu, warmour@ai.mit.edu, leendert@cs.vu.nl,
tytso@athena.mit.edu, turner@smart.sps.mot.com, troj@orion.unomaha.edu,
trier@ins.cwru.edu, struttmann%gps.decnet@consrt.rok.com,
tmstrato@king.mcs.drexel.edu, marks@eng.sun.com,
msdrl!ajs@uunet.uu.net, schell@dockmaster.ncsc.mil,
denis.russell@newcastle.ac.uk, arie@theory.lcs.mit.edu,
rriny@a.isi.edu, rosenblg@nyu.edu, riordanmr@clvax1.cl.msu.edu,
nss1!cjr@uunet.uu.net, mpr@ctt.bellcore.com, john@iquery.pic.com,
rajaram@eng.sun.com, puklich@plains.nodak.edu, spgdrp@ganges.ucop.edu,
plummer@wang.com, pato@apollo.com, michael_parmett@cup.portal.com,
d3e608@pnli.pnl.gov, lhn@atherton.com,
dan_nessett.nsd@lccmail.ocf.llnl.gov, bcn@cs.washington.edu,
jcm0011@usav01.glaxo.com, rob.montjoy@uc.edu,
ellozy@farber.harvard.edu, microsoft!pradym@uunet.uu.net,
milac@amath.washington.edu, marker@mips.com, manion@fccc.edu,
lunt@ctt.bellcore.com, gm.grl@isumvs.iastate.edu,
kreymer@fnalm.fnal.gov, spx@informatik.tu-muenchen.de,
jimkirk@corral.uwyo.edu, kevin@fnsg01.fnal.gov, karger@osf.org,
djohnstn@kodak.com, jiangwd@wmavm7.vnet.ibm.com, serge@optigfx.com,
hunter@ssd0.nrl.navy.mil, hughes@logos.ucs.indiana.edu,
howell@cod.nosc.mil, rhott@relay.nswc.navy.mil,
spx-people@mailer.jhuapl.edu, an288@cleveland.freenet.edu,
opsrjh@uccvma.ucop.edu, hacke@wugate.wustl.edu,
rjg@umnstat.stat.umn.edu, cfraizer@argus.ucs.indiana.edu,
tomfox@cs.utexas.edu, peter@lanl.gov, b8tefeu@umsulx.minc.umd.edu,
microsoft!vincentf, 72040.2460@compuserve.com,
ingr!geo!dorf@uunet.uu.net, ddw@prlb.philips.be, ead@cemax.com,
daniel@netcom.com, geconant@eng.xyplex.com, cheng@sybase.com,
irc@melb.bull.oz.au, j_cerny@unhh.unh.edu, butler@esvax.dupont.com,
anb@computer-science.nottingham.ac.uk, buhle@xrt.upenn.edu,
rnb@stc06.ctd.ornl.gov, acs_hb@enterprise.acc.uwrf.edu,
black@beach.csulb.edu, berg@tc.pw.com, qjb@athena.mit.edu,
sean@coombs.anu.edu.au, batie@aahz.hf.intel.com, paulb@mlacus.oz.au,
rwb@csdvax.gatech.edu, smb@ulysses.att.com, athey@lorien.ocf.llnl.gov,
pwitg!dewey@uunet.uu.net, uunet!ibism!rwu, microsoft!richardw,
peter@msdc.com, bis_dvaman@sitvax.stevens-tech.edu,
swansonc@acc.stolaf.edu, bstrand@cray.com, sgs@ms.secs.csun.edu,
solo@bbn.com, jms@carat.arizona.edu, smaha@dockmaster.ncsc.mil,
jis@mit.edu, dsamperi@citicorp.com, chr@utrcgw.utc.com,
romine@cise.nsf.gov, riceg@mdcbbs.com, mhpower-sp@stan.mit.edu,
doug@jhuvms.hcf.jhu.edu, tri@qsun.att.com, miller_donald@tandem.com,
miller@banyan.com, mjmerhar@eng.xyplex.com,
eplrx7!mcneill@uunet.uu.net, bede@mitre.org, mayhew@utkuxl.utk.edu,
steve@smc.com, dl6@stc10.ctd.ornl.gov, lewis@chouse.iastate.edu,
kml@mosquito.cis.ufl.edu, kml@sware.com, kelly@ipla01.hac.com,
gwi@icf.hrb.com, gregh@mailer.jhuapl.edu, holbrook@cic.net,
markh@crl.labs.tek.com, hawkes@sps.mot.com, hasche@zeus.unomaha.edu,
green@ds17.scri.fsu.edu, u3500
%%% end overflow headers %%%
