IBM Mainframe Forum

RACF expert,

Are you, or anyone you may refer, able to answer a RACF userid security question I have and how to prove if it can be done or not?

I've been accused of performing the following, but I did not and want to be able to prove I did not. Please help me to identify the culprit.

"Is it possible to even attempt to physically remove, while logged in, my own ZOS/MVS RACF userid from an active RACF security log or file, thus generating a RACF security violation"?

Is this even possible?
If so how?
If not, how, what or where should one look to verify it can not be done?
What RACF system logs or files may be queried to determine if a RACF security violation even occurred on my RACF userid?
And if so, how to determine if an administrator or manager level RACF security user got access to my userid to perform such a task to generate this type of RACF sercurity violation?

Thanks in advance,

edipedi2

First, create a new topic for a new question -- don't add your totally unrelated issue to a three-year-old-topic (the topic you replied to involved CA-ACF2, not RACF). I split your question out for you.

Second, if I understand what you're asking (and it is NOT clear what you are asking -- you may very well understand it but an independent bystander like myself has trouble figuring out what you're saying), then the answer is yes it can be done. You need to get the security group to generate the log(s) to indicate what happened. You may also need to have the SMF data reviewed if the logs aren't adequate to your requirement. It is quite possible you believed your action(s) to be innocent but the way security works at your site means that something not expected (by you) happened.

Thank you very much. Yes I agree the post is confusing, as it was to me when I was accused. The actual accusation and I quote was... "attempt to remove your racf userid from the racf security log causing a racf security violation". This is why I needed expert advise as to if that is even possible. I am a Mainframe Cobol CICS DB2 application developer and have no interest or intent to remove my RACF userid. That would be nonsense because I would not be able to perform my job if removed.

remove your racf userid from the racf security log

This is very different from

remove my RACF userid

The first involves removing your userid from one (or more) data sets of logged access attempts and results; the second involves removing your userid from the RACF data base and hence prevent you from logging onto the system. In any case, if you don't think you did what you're accused of, get the time pinpointed so you can identify what you were doing at that time. It is possible that you (accidentally such as through a keying error or deliberately out of curiosity or malice) attempted to access a protected resource for update, and that is what you were accused of. It is also possible that something else is going on and the security people might need to review their processes. Mainframes are perceived as being secure and hence it is not uncommon for security procedures to have holes -- I was reading a security presentation this afternoon that talked about penetration testing succeeding on three different mainframe systems (out of three systems attempted); one was using RACF, one was using ACF-2, one was using Top Secret. I am not saying you did or did not do what you are accused of -- I'm pointing out that security holes exist in many (if not most) mainframe systems.

• ”RACF Security Log”
  
  RACF security incidents are written to SMF. In other words, it seems to me you're asking, “Can I remove a single record from SMF data?” This is a two part question.
  
  
  • Can I remove a single record from the “live” MANx data?
    
    My estimate this would be very difficult.
    
  • Can I remove a single record from SMF data after it has been recorded in more permanent media?
    
    Provided you have RACF “update” or “alter” access to the data, it is probably not that difficult, but then you run the risk your access to the media will be noted.
• Another log is the ICH408I messages in SYSLOG. ICH408I messages are much easier to locate and interpret than SMF data You have the same issues as with SMF.