Idea Details

Make OK+B audit records audit-adequate

Last activity 05-31-2019 01:53 AM
Josef Thaler's profile image
08-24-2015 02:05 PM

As a Security Administrator, responsible for global monitoring and auditing of security events, I need Top Secret to get "OK-B" bypass-audit-records in a clear and unambigous manner.


Therefore I suggest to change the design of:


"Any resource access that is allowed as a result of one of the NO***CHK Bypass attributes is logged as a bypass event."  (taken from TSS Audit Guide, Chapter 2: Misuse of CA Top Secret, page 15) and interpreted (1) as: "if the bypass attribute is set for a security check then this will be the reason for the event's success and will cause an OK+B Event" (as stated in CA Support case)




"Any resource access that is allowed as a result of one of the NO***CHK Bypass attributes is logged as a bypass event."  (is the same TSS Audit Guide, Chapter 2: Misuse of CA Top Secret, page 15) but interpreted (2) as: "If the ressource access is granted only because of the bypass privilege of an acid (without NOxxxCHK the access would be denied), only then an OK+B record is written.


Interpretation (1) entails

- that OK+B records are written, even if the acid has the regular permission to access the ressource (=misleading)

- that OK+B records are written also if the ressource is not protected by top secret (=overhead and waste of ressources) 

- that under certain conditions (see several technotes) an OK+A record is written in place of an OK+B record. (=misleading) 

- .... ?

while Interpretation (2) exactly puts down, that the privileged acid functionally made use of its privilege. (and this is, what an auditor mostly wants to know.)


If this suggested change to Interpretation (2) is not possible for performance-, never-change-a-design-  or other reasons, I propose the creation of additional bypass privilege attributes (for example to NORESCHK an analogous NORESCKA, which would function the same way like NORESCHK, but cuts audit-adequate OK+B records according to interpretation (2).


08-28-2015 12:37 PM



Please see new idea "Order of Evaluation of Bypass Attributes".


John P. Baker

08-28-2015 12:11 PM

If that would be the solution made work by CA, I would gratefully make use of it.


My suggestions are always intended to describe a patricular need or behaviour, and the suggested solutions are only intended as illustrations to show better what I mean.


So, if you consider the suggestion based on interpretation (2) (above) to be useful or at least to be more reasonable, you might want to support this idea or submit a new one with your particular suggestion, which I definitely would give my vote, because ... as earlier written.




08-28-2015 10:36 AM



It seems to me that all that we need is to have is an option to have CA Top Secret Security change the order of processing such that NOxxxCHK is evaluated last rather than first.


By doing so OK+B events will show up if and only if the accessor ID has no permit that would provide the appropriate access.


John P. Baker

08-28-2015 03:09 AM

Hello Suzanne again,

one workaround / approach to safely remove NORESCHK-privilege could be:

  1. Admin all permissions, that you think are necessary to make the NORESCHK-privilege obsolete.
  2. Copy your Acid to a new acid (CRE(new-acid) USING(active-acid)) and remove the privilege from the copied acid (REM(new-acid) NORESCHK)
  3. Use TSSSIM to Check all OK+B events of the last time against the new-acid(!).
  4. If TSSSIM does report access-violations of new-acid as expected (OK+B records currently do not tell, whether the permission is adequate or not)  you can remove NORESCHK from active-acid with lower risk and finally delete new-acid. 

Maybe this helps, let me know ...


The challenge will be to transform the OK+B records into TSSSIM-Syntax. I will definitely NOT submit an anhancement request to create TSSSIM-records from OK+B records (maybe such a possibility already exists!?) but I would like to ask you to support idea Top Secret TSSUTIL Enhancement  to make TSSUTIL write output records, which are better transformable to what specifically and individually in the installation is needed. (create an EXCEL, make TSSSIM-records, create TSS-Commands and so on ...)


Feel yourself invited to comment, vote or share alternative approaches - for the prosperity of all together ... 




08-28-2015 12:56 AM

Hello Suzanne,

thank you for your update, it's good to know, that there are consensuses. And may I take your comment as a vote? :-) 

In my TSS-mind, I distingush between privileges and permissions, and (NORESCHK)-privileges should be questioned and reworked, and only be used, if there are really good reasons, which are ..... which?

Regards, Josef,

08-27-2015 05:50 PM

I would love to see this implemented.  One of the reasons we are not able to remove bypass attributes where they are inappropriate is due to the risk.  A good part of the risk is because if we permit access, it still appears in report as an OK+B record.  That means we have no good way to validate that the permission is correct and will allow access even after the bypass attribute is removed.