----------------------<snip>------------------
Well.. I know (or at least it, so it appears - since I don't *KNOW* you)
you are indeed a thoughtful "security officer".. (And.. err.. started
tasks bypassing authentication is definitely a solution - yet - doesn't
it give people with access to the console an awful lot of power ? (just
a question.. I'm not a z/OS guy ! maybe I'm getting this all wrong !).
--------------------<unsnip>----------------
You can definitely control what can be run as a started task. You need
to understand JESS2 JCL and control statements but controlling STC
access is definitely possible. And I tried very hard to be a good,
thoughtful security officer. I sometimes "P***ed off" my management
because I refused to reveal certain passwords, etc. to management or
even to security auditors.
------------------------<snip>---------------------------
The message I am sending is that a 'three strikes and you're out'
solution is not a panacea. I wasn't sending the message to you - but
rather - to *everyone* out there who may be confronted with the evil
'know it all' auditor/consultant who is going to *instruct* people to
implement these sort of measures indiscriminately (because that's what
is on his checklist !)... And maybe to those who hadn't thought of some
of implication of such a policy (if it isn't implemented correctly).
-----------------------<unsnip>--------------------------
Nothing is a complete solution in this area. But auditors like to see
some form of "reasonable" limitation in this area. Negative implications
don't interest most auditors; they have, in most cases, their own
pre-conceived ideas. And unfortunately, management is more likely to
listen to them than you, because they paid some (outrageous) fee for the
auditor's opinion.
--------------------------<snip>------------------------
Actually a "100 strikes and you're out" (or some quite large number) may
be a possible solution : it avoids brute force attack through some
TN3270 API - yet - someone doing this will be easily detectable - AND it
avoids the CEO with a bad hair day to be locked out - and starting
firing people by the dozen (because eveyone knows the CEO will *have* a
bad hair day[1] on the critical day).
--------------------------<unsnip>---------------------
See above comment. If the CEO gets hit, that's tough. If he's not
"security conscious", then make him set the standards, in writing. He
can live (or die) by his own pronouncements. Wait'll the auditor sees
it, then watch the "fertilizer hit the Westinghouse".
---------------------------<snip>--------------------
Then again, a script kiddie may be able to lock out people that way..
(but it does lower the risk)..
----------------------------<unsnip>--------------------
The more chances you give that "script kiddie", the better his chances
of success. 'nuff said??
---------------------------<snip>-----------------------
And about the "password" aging problem and complexity.. My (personal)
recommendation is (mind it, I am NOT a security officer.. just an aging
sysprog) : allow passwords to remain unchanged for a long period of time
- yet - force somewhat complicated passwords : This way : people won't
have to write them down, however, they are hard to crack (through
bruteforce attacks on hashes) and - furthermore - once they are
accustomed to their passwords, they will type them fast at the keyboard
(mitigating the 'over the shoulder' attack). My "usual" password isn't
very long - 8 chars.. but I can type it in a matter of ~500 ms.
---------------------------<unsnip>------------------------
Password aging and complexity can be good things, provided they aren't
carried too far. Because of business functions, our users had to logon
at least monthly, on the first business day of the month. So we gave
them 36 days. But if a password had leading or trailing digits, we
required at least two digits and we didn't allow a password to be a
anagram ("scramble") of the user id.
----------------------------------------------------------------------
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
