Learning the GSI Security Ropes
Dillon Connor, Associate Solution Consultant
In my time at GSI, I’ve worked on 3 projects. The first was to determine what a current security model grants access to, as well as to provide analysis to the client. The second consisted of ongoing maintenance for a client’s current model while a new, best-practice model wass created. The third project consisted of implementing a brand-new security model, while not supporting their pre-existing model. These three projects have shown me the full life-cycle of a security project and taught me lessons that can be applied to projects for any client.
Determining the current access in a system is necessary to show a client how it can be improved. The client that I worked with had a system that had been set up years ago by someone who has since moved on. From this setup, only some of the rules were followed. They were changing the contents of the roles, and adding access to them that was never intended to be there, and assigning the roles to new users based on the name alone. This was a result of the disconnect between managers who only see the names of the roles, and the security team who maintains the contents of the roles. This created a variety of problems with their security model that could have been solved with a set of procedures for making security changes and showed me how important developing a robust security model and sticking to it are.
The second stage in the life of a security project is maintaining existing levels of access while a new model is planned. For most clients this is done internally using existing personnel and procedures, but when a significant portion of a security team leaves we have the opportunity to see the working model in action. This shows us something that generally is a bit harder to see: how the existing non-security personnel work with the procedures to handle changes. With this knowledge we can make gradual changes to their procedures in a way that improves issues with the working model and prepares the client to work with the new model. This has shown me the varying levels of success you can have in working with users and the different methods we need to use to allow smooth communication and security changes.
The final stage in implementing a security model – and the one that receives the most scrutiny – is designing the new model. This involves speaking directly with users on-site and breaking down what they need to do their jobs. This can be broken down in multiple ways – typically in relation to either their full jobs or the processes they perform – and is planned at a high level with the client’s management. Working with the users at just one client has showed me how much users typically see of JDE and how to communicate between the functional and developmental levels of JDE usage necessary to design a new system that everyone at the client is accepting of.