Securing CA 2E Model - Best Practices ?

[Henky Saputera]

Hi All,

 

We’re looking for some idea on how to secure our CA 2E Models.  We have hundreds of developers from both onshore and offshore. 

 

And when they use the Models and make any update in any 2E files, they have to do it through the ‘sanctioned’ way, that is through the official CA 2E programs in the Y1* and Y2* libraries.  For example, they cannot ‘backdoor’ changes thru interfaces like STRSQL, YWRKF, DBU or any others that are not part of the original Synon programs/utilities.

 

We’re wondering if there’s any 2E shop out there that face similar challenges, and perhaps have implemented some kind of security approaches to lock down the Synon Model at the object level. 

 

Any feedback is greatly appreciated.  Thank you.

[Legacy User]

Henky,

 

i would start with adding journals to the model files. It may not stop them from updating but at least you will be able to monitor and deal with those doing updates outside of the tool.

 

I would worry about those who are making updates directly.  This is not an advised method for updating models and could lead to a corruption and possible loss of data. YMMV

[Henky Saputera]

Eamonn, thank you for your reply!  It's great to hear from you again...    Hopefully you're doing well.

 

I agree that journaling is useful.  But this will mean additional storage requirements; and this alone can be a big enough hurdle for many shops already...

 

Also journaling won't prevent people from tampering with the Model data, as you've already stated.  It will be useful to figure out who did it, etc (assuming the journal info is still available).  But the recovery works will still need to be done, to restore to the last save point, etc.  There will be time spent, productivity & works lost, angry emails flying around, etc -- you know what I mean

 

What will be better, perhaps, is to have a more pro-active security approach that will enforce Synon users to only use the sanctioned programs/utilities to update Model data.  Any data-tampering attempts through non-sanctioned interfaces should get some authority errors.

[Legacy User]

is this really that dire a situation?  I ask because direct manipulation of the model files is a task best not attempted unless you are very very sure of what you are doing.  And even then it is a risk.

 

The only other thing that *might* work and even then this is a theory not something i've ever done nor would i normally suggest.  Do not try this at home, use suggestion at your own risk, by reading this post you assume all risk.  It is not my fault if you mess up your 2e environment.  I do not suggest trying this in relation to your active development.  

 

*Just a theory*  You could change the authority on the model files to make all users read only and change the y2 programs to be *Owner.  This would in theory prevent manual access of the model files.  This does not take into account possible impact by third party app (change control) and is only a theory.

[Henky Saputera]

FoleyE, thank you for your further input.  I apologize for late reply, works can be often demanding as we all know... 

 

Thankfully, we haven't got any serious situation as far as I know.  But as we all know, a good security approach/model cannot be just based on assumptions that people will always behave well.  We have hundreds of developers onshore and offshore, and contractors from different vendors with various levels of skills etc.  We certainly need a more robust and comprehensive security approach to secure our 2E Models.

 

We're aware that this is a complex subject, and we may not find a good answer...  But you've brought up a good feedback there, with that suggestion to experiment with IBM i features such as Adopted Authority and Authorization List.

 

Ultimately, we want to secure the Model at two levels (maybe...):

1. At object level (ex: FILE, DTAARA, PGM).  For example, people should not be able to delete or alter Synon model objects.
2. At data level.  For example, people should not be able to tamper with data in Synon internal files, or change DTAARA value, or updating any Synon data not using the sanctioned/official interfaces.

 

And maybe this whole security approach can be modeled after the 3 different Synon User Classes: *DSNR, *PGMR & *USER.

 

Assuming we know which objects to secure at which level, maybe some combination of those OS features can then be applied and experimented...  Thanks again.

[Legacy User]

if you are going to the conference this year, lets see if we can get together at lunch or in-between sessions to discuss this.

[Henky Saputera]

FoleyE thank you for the offer    

Unfortunately we may not be able to go this time, due to some budget constraint.  But if you and the CA 2E Team ever comes up with a smart solution of securing the Model, we'll be definitely interested to learn more...  Thanks again.

[Legacy User]

One problem with your approach Eamonn - is that one a program runs that uses adopted authority - any call to QCMD will provide adopted rights - from where you can use YWRKF or SQL to manipulate the internal model files.

[Legacy User]

I would probably look at using database triggers that would then provide notifications if an update is being performed by a non-Y2SY program. I would not stop the update - but just provide a level of notification that someone has done it.

[Legacy User]

Of course disabling and enabling the triggers will nullify this solution.  

 

I think that a combination of solutions, mostly for monitoring, is what you will be looking for.  

 

While journals and triggers don't stop them, they didn't get away with unless they get away without getting caught.  And between the 2 you will catch the name.

[Henky Saputera]

Thank you for the feedback, Darryl_Millington and FoleyE ! 

 

We have existing/old trigger process already, that logs developers' actions in the Model.  The file-journaling is perhaps an additional thing that we can do, so we can have better visibility on any past actions...

 

Hopefully, one day in the future, there can be a more pro-active/comprehensive approach for this.  Thanks again.