-----------------------<snip>-----------------
The scenario you describe is quite possible. In shops where I've
worked, getting caught doing something like that would result in a
speedy promotion: to the street. And DON'T ASK FOR REFERENCES!
I know... But we are talking "security issues" here.
Maybe a disgruntled employee who is about to get a pink slip or about
the send a resignation letter anyway.. doing those kind of actions
could make considerable damage to the company if the timing is right -
while someone succeeding into breaking into a critical account by
brute force seems to me more unlikely. I am going on the premise that
someone caught attempting to circumvent or abuse security measures is
at risk *anyway* !
What I am hinting here is that account locking COULD (in certain
situations) be a security *risk* rather than a security enhancement to
a system - because although brute force cracking of account
credentials is possible, abusing a userid lockout is far easier and
accessible to implement (it doesn't even require any skill) !
And don't ask me about those 'secure' systems that ask you to change
your password every 2 weeks - with passwords that must be at least 32
characters long, with no dictionary words, a mix of
upper/lower/digits/special chars - which invariably get written on
post-it(tm)s and "hidden" under the keyboard.
---------------------<unsnip>----------------------
You're still quite accurate. Here's what I did to avoid an extended
outage: (Keep in mind that this was quite some years ago, before
additional controls were implemented in RACF vis-a-vis started tasks):
1. I installed an exit which would allow all started tasks to run,
whether they supplied valid passwords or not. The Systems Programming
staff had complete control of Started Tasks, and any parmlibs that they
might use.
2. I installed a Started Task that would RESUME selected userid's, with
pre-determined passwords, based on parms provided in a
tightly-controlled PARMLIB.
3. Access to the RACF DB, and its backups, was tightly controlled so
that a brute-force approach, by unloading the RACF DB, wasn't possible
outside the Security Administration staff (Me and one other System
Programmer).
4. LOGON and Attempted LOGONs were audited, whether successful or not. A
regular report of that information was generated, both for security
admin staff and senior management. Information included was, among other
items, USERID, number of attempts and TERMID (Thank you, VTAM).
5. If any DOS attempt was made for production userid's, the Operations
staff had instructions to "Run this Started Task" and notify the ENTIRE
security admin staff ASAP. We could then run some RYO reports to try and
pinpoint the issue and/or offender.
IIRC, there's been a modification to RACF such that a started task will
never be denied LOGON access; what happens after that depends on the
various profiles in the RACF DB.
We had a job scheduling package in place and we used the propogation
features for USERID and password, so NO production job contained either
form of information. Another exit, for TSO SUBMIT, disallowed any USERID
and/or password information to be submitted via TSO SUBMIT commands. A
very few people were allowed to supply USERID information, via the
SURROGATE mechanism of RACF. NOBODY was given SURROGATE authority for
Started Tasks; even the security folks didn't have it. And STC &
Production passwords were unknown. The job scheduler had SURROGATE
access for the various production ID's, so providing a password was not
needed.
Sooner or later, you'll have to invest a certain amount of trust in a
selected, and trusted, few employees. If you can keep that to a minimum,
you can minimize the risks of an extended outage because of "security
abuse"; you just have to decide who you trust.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
