How do companies handle signing off for auditing on security

Sort:
You are not authorized to post a reply.
Author
Messages
spatterson
Basic Member
Posts: 16
Basic Member

    Our IT department has a report they run which is thousands of pages for our end users to sign off on with regard to security and what individuals have access to. I have two questions:

     

    1. How are other companies getting sign off from the internal audit department on their security access and if they have it down to a few pages, did they go through and take off security they didnt need? Our issue is we as the person signing off does not know what some of these screens means and if we take it away...what else are we taking away that we shouldn't? For example if all the Gl folks do is use RW100, how do we know which access is needed for just RW100?

    2.  Is there someone or something that explains what security access is needed for certain screens. For example, our Property Records Manager only uses 4 screens in Lawson but she has 100's of pages that she is suppose to review. If we knew that we only wanted AC10, AC7 etc how do we know what security we need to access those?

    Any help on security using LAUA would be helpful. We have not yet moved to LSF9 security. We are still on the old one.

     

    stephanie
    Veteran Member
    Posts: 330
    Veteran Member
      Comparatively speaking, our security is pretty simple here, however, we have to rely on the owners of the system/data to determine exactly what access users need. You'd need someone at your organization, too, to "own" who should be able to do what, based on your job descriptions/business process/etc. We pulled in all areas in our organization that use Lawson - accounting gave us information on what anyone on the finance side needed to do in the application, and we on the systems side "fine tuned" the access and then obtained sign off. We did the same thing on the payroll, and then the benefits side, and ulitimately, the Payroll and Benefits Director signed off on everyone's access, since they truly own the system here.

      As a long time Lawson consultant before coming on board as an employee, I was able to guide the users with their access - do you have someone like an analyst, etc. who could possibly help you better determine access needs?
      k-rock
      Veteran Member
      Posts: 142
      Veteran Member
        Many users, myself included, have created databases to analyze and filter the LAUA reports down to a manageable level. Each security class has a record for each screen. This is what leads to the thousands of pages. Start by filtering on SECURED = NO. This will only show what that class has access to.
        spatterson
        Basic Member
        Posts: 16
        Basic Member
          Stephanie, we only have one Lawson person working here and she is in IT and is very new to this position. Our end users know what screens they need access to but is unsure if they tell IT to take away a program name and form from a security class that it will in turn take something away they really needed. As end users we only know what screens we need but we are relying on IT to tell us what behind the scenes will not work or is attached to that form if its taken away...without taking it away and seeing if they cant get to a certain screen they need. Is this something our IT folks should know or is there some document out there that tells you what tables behind the scenes go to what forms and programs etc?
          Ben Coonfield
          Veteran Member
          Posts: 146
          Veteran Member
            One command you should look into is called lstinvk. If a form calls other programs internally, this will show you what it might call. For example, the command "lstinvk productline po10" will show you that the po10 form can call the programs API4, ACAC, IFCU, IFAC, IFSG, SLSE, SLSU, & API3. This does not mean that every use of PO10 will call all of these, it depends on the particular function. But a PO10 user can be impacted by removing access to these invoked programs.

            Regarding what tables go with which forms, I think most users focus on securing the forms and make few changes to the default table security. But I believe that this information is listed in what Lawson calls the "technical text".
            spatterson
            Basic Member
            Posts: 16
            Basic Member
              Ben,

              Thanks I will pass that along to our IT folks but this is a great start. Thank you so much.
              stephanie
              Veteran Member
              Posts: 330
              Veteran Member

                IMO, it's not the IT area that should know this - it's the data owners and users who have the expertise  - someone familiar with the system and how it's used.  Technical text and data file text have the relationships, but again - if you don't know the system, its just a bunch of table names and form numbers.  There's some nice relationship diagrams under the tech section, here -

                If you don't have someone with overall knowledge of the system, do you have a test area that you could use in conjunction with your IT person to actually test out some of your questions?

                 

                You are not authorized to post a reply.