| Title: | -={ H A C K E R S }=- |
| Notice: | Write locked - see NOTED::HACKERS |
| Moderator: | DIEHRD::MORRIS |
| Created: | Thu Feb 20 1986 |
| Last Modified: | Mon Aug 03 1992 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 680 |
| Total number of notes: | 5456 |
================================================================================
Note 151.30 The Probe 30 of 31
VLNVAX::MDLYONS "Michael D. Lyons DTN 297-5911" 161 lines 14-OCT-1986 15:20
--------------------------------------------------------------------------------
-< AUDPACK >-
I stripped off some of the headers, but left the original ones
on so everyone could see the intended audience....
Message-class: DECMAIL-MS
From: NAME: MEGNA
INITLS: JOE
FUNC: DIGITAL TELECOM
ADDR: VRO5-2/Y3
TEL: 273-3100 <MEGNA@DECMAIL@HYPER@MRO>
Posted-date: 29-Sep-1986
To: DISMC:: ROGER BEDARD @VRO,
HASKELL CEHRS @VRO,
MIKE CONNOR @PKO,
GINNY COVINO @AKO,
BEL CROSS @VRO,
SERGIO GIACOLETTO @GEO,
PAT GILLOGLY @CHM,
KEN GORDON @VRO,
JIM HOGAN @AKO,
DAN INFANTE @MLO,
LANA LEE @VRO,
RUSS PITTENGER @VRO,
MARTY SACK @VRO,
SUZEE WOODS @VRO
Cc: NAME: MAGUIRE
INITLS: ED <169093 @DECMAIL@DONJON@VRO@*>
Cc: NAME: MCCAULEY
INITLS: BOB <70002 @DECMAIL@DONJON@VRO@*>
Subject: AUDPACK
FOLLOWING IS A DESCRIPTION OF THE AUDPACK PROGRAM WHICH HASKELL
DISCUSSED WITH YOU AT A RECENT DISMC MEETING. HASKELL ASKED
THAT I SEND IT TO YOU IN HIS ABSENCE. PLEASE REVIEW IT AND PROVIDE ME
YOUR APPROVAL AND/OR COMMENTS. REGARDS.
Remote Security Testing
Following is the program summary to develop, implement, and support
a security software tool called AUDPACK. The intent of this program is to
provide an integrated security diagnosis and management reporting system.
This program is an integral part of our strategy to provide written
standards, which are implemented at the node level using SECURPACK, and
monitored remotely using AUDPACK.
I. Development
-----------
In its present form, AUDPACK is only capable of testing password
management and the protection of User Authorization lists. These
functions are important; therefore, the system will be implemented in
its present form. However, there are other security vulnerabilities
that AUDPACK will not diagnose. Two examples, are World Writable COM
files and PASSTHRU logs. The tool must be upgraded to include these and
other security vulnerabilities. Plans are to include these security
tests in a future version of AUDPACK or a similar security software
tool, by the end of FY 87.
II. Implementation
--------------
A. Operating Procedures
1. Responsibilities
Since this software could be misused to gain access to nodes on
EASYNET, AUDPACK use is restricted to Digital Telecommunications.
The Network Security Program Manager has overall responsibility
for running the program throughout the United States and GIA
EASYNET Areas.
The EASYNET Area Managers are responsible for assuring that the
security shortcomings identified by AUDPACK are corrected.
2. Schedule
Each EASYNET Area will be tested at least quarterly. Approximately
10% of the nodes will be tested weekly. The tests will be performed
on week ends, according to a published schedule.
3. Operating Procedure
The process which will be followed is:
(a) The EASYNET Area Managers will be notified by electronic mail
before nodes in their Area are tested.
(b) The Area system managers will receive two electronic mail
messages before their systems are tested. These mail messages
will request acknowledgment by the system managers.
(c) The node registration data base will be the reference data
base for testing. The EASYNET Area Managers will assure that
their respective nodes are properly registered.
4. Metrics and Reporting
(a) The EASYNET Area Manager will be provided with a detailed
report of their respective areas, after each weekly run.
(b) The system managers will receive electronic mail, in cases
where AUDPACK detects an insecure system.
(c) Appropriate graphs will be prepared for publication in
management reports. These graphs will be of a generic nature.
5. Responsibilities for Resolving Security Problems
(a) The system manager should promptly correct security problems
identified by AUDPACK.
(b) The EASYNET Area Managers are responsible for the security
of the nodes in their respective areas and to make sure
that the system managers have corrected the security problems
identified by AUDPACK. Follow up security tests will be
scheduled to monitor compliance.
(c) The appropriate DISMC member will be notified when the
identical security problem is identified on two successive
AUDPACK runs.
III. Support
-------
(a) Digital Telecommunications will coordinate support and
enhancement of AUDPACK with European IS Network Management.
IV. Security Plan
-------------
(a) Copies of software will be strictly controlled. Three
copies exist in the world.
(b) Processing will be from a dedicated system.
(c) The system will be in a physically secure area.
(d) The process will be performed by one person for
accountability.
(e) The system will be disconnected from EASYNET, whenever
security tests are not being performed.
(f) The software and files will be encrypted using the DES
algorithm and a key known only by two persons. The key will
be changed monthly.
V. Legal Requirement
-----------------
(a) GIA legal issues will be reviewed with the GIA Telecom
Manager and the Legal Department, prior to implementation
in this Geography.
VI. Internal Audit Group
--------------------
(a) Digital Telecom will provide security testing support for
Internal Audit Group. The notification procedures
specified in section II-3 will be followed.
================================================================================
Note 151.31 The Probe 31 of 31
PASTIS::MONAHAN 6 lines 15-OCT-1986 04:56
--------------------------------------------------------------------------------
As the person who wrote AUDPACK, I have suggested that any further
extensions should be directed towards checking Ultrix and possibly
RSTS systems rather than attempting more detailed checking of VMS
systems which the memo in .30 suggests.
Comments??
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 333.1 | its the P R O B E !!!!! | ACE::BREWER | John Brewer Component Engr. @ABO | Wed Oct 15 1986 23:44 | 12 |
OK... A free New Mexican dinner to anyone who can write something
to "auto reply" to the " P R O B E" . (Travel and accomidations
not included!)
Something like "I see you big Brother!" or some such, automatically
returned to the prober upon being probed.
All in (semi) fun,
-John
(Do it Jym!)
| |||||
| 333.2 | SUBSYS::LAWLER | Real Pilots do it on Grass! | Thu Oct 16 1986 15:05 | 2 | |
How about trying to load a worm back onto the probing system?
| |||||
| 333.3 | The best defense is to be offensive | MDVAX3::COAR | A wretched hive of bugs and flamers. | Thu Nov 26 1987 16:45 | 16 |
Presumably, the network and accounting logs on a probed system will
identify the probing node. How about a bunch of worms throughout
the net that watch for that node becoming reachable, and then bombard
it? Wouldn't it be fun if the prober succumbed to penetration during
its probing?
Of course, the reasonable thing for them to do would be to switch
node IDs between probes of individual systems, so that such worms
*couldn't* get back to it. However, that leave a finite set of
node IDs, although still large.
Maybe something that intercepts accounting records as they're written,
filters out login failures on network access to standard accounts,
and activates the worm?
#ken :-)}
| |||||
| 333.4 | as the person who wrote it ... | PASTIS::MONAHAN | I am not a free number, I am a telephone box | Fri Nov 27 1987 00:44 | 10 |
I think I don't understand the last suggestion.
Audpack is the security guard, going round to check that windows
are closed and doors are locked at night, protecting Digital's
property, and maybe yours too if you have left anything personal
on the premises (disks).
Sure, you can beat him unconscious and go home leaving the door
open, but I thought the sense of the original was "How do you give
him a polite 'Good evening'".
| |||||
| 333.5 | Reality vs. perceptions | SQM::HALLYB | Profitus Interruptus | Fri Nov 27 1987 01:16 | 12 |
Pat, you probably know more about this process than other readers
of this file. The concern seems to be that Audpack somehow does
an evaluation of how well the system manager has done the job.
If Audpack manages to break into my node, what happens? Does my
Cost Center manager get a telegram from Bel Cross ordering me to
be hung, drawn, and quartered? Maybe not, but the impression is
that somehow system managers are being "evaluated" by some cold
piece of software. Under the circumstances its mighty tempting
to fight back...
John
| |||||
| 333.6 | Mea culpa, sort of | MDVAX3::COAR | My hero? Vax Headroom, of course! | Thu Dec 17 1987 20:24 | 8 |
Indeed. I personally have no squabble at all with the process of
the probe, as long as the results are kept confidential between the
probe and the manager involved. Repeat offenses (more than, say, two)
I can understand going higher in the management chain. Even in
an open, trusting environment (which some parts of DEC are), a `snitch'
is generally disliked, despised, and subject to abuse.
#ken_who_felt_a_twinge_at_your_analogy_of_beating_the_guard_unconscious :-(
| |||||