Idea Details

Extend TSS-Command by change-identifier-operand

Last activity 06-13-2019 10:07 AM
Josef Thaler's profile image
12-22-2014 10:02 AM

Based on John P. Baker's reply (many thanks!) to my question ( https://communities.ca.com/thread/241699748?sr=stream&ru=120883015 - ? Possibility to Enforce commenting for TSS Commands ?)

 

I suggest to extend the TOP SECRET  TSS -Command by an operand, where a change identifier can be entered.

 

This change identifier should be applicable to any command where that updates the security file or that updates the configuration (TSS MODIFY).

 

This change identifier should not be applicable to a TSS LIST, TSS WHOHAS, or TSS WHOOWNS command.

 

An exit point should be provided in the TSS installation exit where the change identifier can be validated.

 

The change identifier should be recorded in the TSS recovery file and in the CA Compliance Manager z/OS logstream.

 

The TSS options or administrative attributes should provide a possibility to turn on/off an enforcement, that this operand must be specified in the commands


Comments

03-14-2016 02:24 PM

just to clearify from my last comment: A comment is definitely NOT a change-identifier ...

02-29-2016 03:19 PM

Thanks a lot, Kimberly, to provide this valuable information! It could help to realize a workaround until a comment is made to a change-identifier.

Kind regards, Josef

02-29-2016 02:49 PM

Hi Josef - I asked our Scrum Master and lead engineer, Randy Kemmerer, to put together a description of how you can meet your goals in Top Secret today through different means. I hope it provides some clarity for you.

 

Use two documented features of the product to enforce some form of a change identifier as follows:

 

1. Administrators can add comments to any TSS command. The TSS Command Functions Guide documents the use of comments in the section on command syntax. Comments can be inserted using the characters /* to start the comment and */ to end the comment. To add a change identifier field they can establish an offset from the /* characters and insert a token such as ‘CID=’, it would look something like this

 

TSS ADD(acid) NORESCHK     /* CID=123456   */

 

These comments will be included in the command entry placed in the recovery file after command execution. Many customers already do this and then use our TSSAUDIT utility to extract and report on the content of the recovery file records.

 

2. To enforce and interpret the values associated with the new comments to be added, the customer would use the TSS installation exit documented in the TSS User Guide chapter ‘Extending Security with Site Security Exits’. The installation exit (TSSINSTX) is called from various points in the security product, one of them being for the entry of each command that has passed basic editing and administrative scoping for the administrator entering the command. A parameter list including vital information pertaining to the current command, including the complete command input buffer, is made available to the exit point. Customized code can now be added to the exit to search for the comment section using the /* and CID= tokens. The absence of these values could be interpreted as a breach in enforcement and a non-zero return code can be passed back to TSS to reject the command. Once the CID value is extracted a table lookup process could be performed by the customized code to further enforce defined values, again using the non-zero return code to reject the execution of the command for non-compliance. 

02-26-2016 02:09 AM

Hello Kimberley,

thank you for your update and your positioning.

You wrote, the described goals could be accomplished through different means, and I'd like to ask you for some hints or keywords, which means you mean.

Thanks a lot and kind regards.

Josef

02-25-2016 04:08 PM

Hello Josef and TSS Community - Thank you for your contribution of this enhancement idea!

 

CA is continually working to improve its software and services to best meet the needs of its customers and your input is vital to that effort. The CA Top Secret product team has reviewed your enhancement idea and decided to add it to our Wishlist to maintain this idea for consideration in a future release. The Community will continue to be able to vote on this enhancement idea which can increase the priority of it in the Team's backlog. When the product team knows it will being working on this enhancement idea, the status will be changed to "currently planned."

 

Please note: You can accomplish the goals you describe above in the product today through different means. We recognize, however, this enhancement can improve the usability of the product and have added it to the wish-list.

01-02-2015 05:19 PM

Don,

 

That is exactly what I envision.

 

I would add that I would prefer to see the change ID / reason ID field have a minimum of sixteen (16) characters.

 

I would also note that for a TSS MODIFY command, the change ID / reason ID would only be required when the MODIFY command actually changes a configuration setting.  For example -

 

TSS MODIFY(FACILITY(BATCH))

 

would NOT require a change ID / reason ID, while -

 

TSS MODIFY(FACILITY(BATCH=MODE=WARN))

 

would require a change ID / reason ID.

 

John P. Baker

01-02-2015 04:47 PM

If I understand you correctly you want something like:

 

   TSS ADD(usera) DATASET(datasetb) ACC(READ) REASON(ticket # 123456)

                                   or

    TSS MODIFY FACILITY(tso) MODE(WARN) REASON(ticket # 234567)

 

This seems like a good idea;  The ADMINBY field contains who made the change, but not why.

 

- Don