Re: BYPASS privilege !!

In article <1181606749.449032.311320@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>, BaxterD@xxxxxxxxxx writes:

First of all, I would like to say that this discussion came about
during a meeting on SOX requirements, which morphed into a discussion
about how it would be possible to "trick" our application if the
villain had certain knowledge, programming skills and system
privileges. We managed to come up with a surprising number of ways
to work mischief, that would be difficult to detect immediately, and
possibly even more difficult to figure out.

That is why they are called privileges. They should be handed out
_very_ sparingly. In the case of the SYSTEM username, that is done
by disabling it for Interactive, Network and possible Batch access.

The only unique capability of the SYSTEM username is for logging in
from the console when under breakin evasion denial of service attack.
The same capability that allows that situation to avoid the breakin
evasion also allows it to avoid the situation where lack of Interactive
access prevents login. To allow access in this limited situation,
consider the description in the second paragraph at:

http://www.ljk.com/ljk/LJK_SECURITY_DOCUMENTATION/ljk_security_d_032.html

If you (or your SOX auditors) want to take that further, consider
dual generated passwords stored behind separate glass.

Thanks to you all for your responses, and I want to start by
saying that we agree with all of you. Whether BYPASS is freely
given to the SYSTEM account or not, there is really no way of stopping
a malicious admin from reeking havoc with your system, should he
choose to.

We were looking at it more from the point of auditability (?).

VMS is incredibly auditable, and that is the answer to all issued
regarding privileges that are actually needed for individuals.
There will always be someone with full control, so Separation
of Duties, as mandated by AC-5 within NIST 800-53 (which is
already a requirement for US Federal Systems, unlike 800-53A
which is still in draft form) is a requirement.

2. be able to determine, after the fact, exactly what was done to
your App, or Data, and be able to recover from it.
and,
3. To be able to determine, again after the fact, exactly who did
it.

As far as SOX is concerned, they are primarily interested in objective
#2. However objective #3 is still important if you want to avoid
it happening again.

Those two go hand in hand.

Obviously, Identifiers and ACL's provide a way to lock down the files
and directories which make up the application, and the UAF provides
the means to control the app users.

I think the most underused VMS security capability is Protected
Subsystems. Make sure none of your applications are installed
with privileges related to file access (BYPASS, GRPPRV, etc.).

However, If there happen to be multiple Administrators, all using the
SYSTEM account for their admin duties. How do you determine who
did what?

NOBODY should use the SYSTEM username for ANY interactive use. That
is basic to having an auditable system.

2. Lock down the SYSTEM account for use only when carrying out
Maint, Upgrades or Patching.

Not even for that. Only for the breakin evasion case I cited.

3. Enable auditing of Privilege use and UAF modification.

If that is a future step, the site is not even close to complying
with _any_ reasonable security system.

1. Does anyone know of any function, particularly during system
startup, which "absolutely" requires BYPASS" privilege.

I think your SOX auditor does not really know VMS. Does she realize
that the system startup process has BYPASS privilege independent of
any settings in the UAF ?

2. Does anyone know of any Admin function which "absolutely"
requires the SYSTEM account.

The breakin evasion case is the only proper requirement for the SYSTEM
username. Anything else you find is a software defect.
.