Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

Sec Lvl 50 - performance considerations?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Sec Lvl 50 - performance considerations?

    Are there any performance considerations to be aware of when running at Security level 50? In particular I am concerned about adding a 6th library to our QSYSLIBL. The vendor of our major application says that we will see performance degradation - can anybody explain this? Many thanks, Ian

  • #2
    Sec Lvl 50 - performance considerations?

    Ian, Yes. There will be a performance impact on your system when changing to level 50. The question is, just how much of an impact? I have heard that it can be anywhere from 2% to 20%. There are some IBM books that mention the extra checking that level 50 performs. As far as the extra system library, I don't see how that will make much of an impact. It will just be another library in the library list. Maybe someone else here has more experience with libraries and the impact when added to the list. Special note: Everyone in my world is simply scared of level 50. Nobody wants to even talk about going there. Guess some people are scared of what they don't know. HTH Scott

    Comment


    • #3
      Sec Lvl 50 - performance considerations?

      Scott, I don't have any knowledge of a performance hit at level 50. It appears the only difference between 40 and 50 is............ Programs fail if they try to pass unsupported parameter values to supported interfaces. I was told 50 was implemented for Federal Government certification of the machine. And you know they love overhead. We are at level 40 which is supposed to provide virus protection. I have no business reason to go to level 50.

      Comment


      • #4
        Sec Lvl 50 - performance considerations?

        Ian, I stayed out of this conversation because I do not reccomend going to level 50 security. Don't get me wrong, I have no, I say again, NO data to back my reccomendation up. I would expect to see some system degradation. Particuarly if you have an older model or inadequate memory to allocate to your respective pools and shared pools. Again, I make this comment just because. Just because I figure that there is more internal security functions occuring at 50 than at 40. If there is not, then IBM owes us and Uncle Sam a big explanation. Level 50 incorporates standards set by the U.S. Government which allowed IBM to achieve a security rating for 'Q' clearance. Even more secret than 'Top Secret', the 'Q' clearance is critical to specific sectors of the Government. Unless you are a Government Agency or a Contractor/Sub-Contractor who is obligated to acquire the 'Q' clearance, I would not bother to implement 50, unless you just want to look prestigious (no problems with that) in the sight of your bosses. Now that I've talked about system degradation, lets talk about enhancing performance. My assumption (no proof) is that the 'extra' security functions happening behind the scenes will require more resources to function. Memory for certain (assuming my performance guess is correct) and quite possibly more dasd to store the security features, if they are not already installed or if they need to be unzipped to be functional. I would talk with your software vendor and question them about specific instances of 'sluggishness' and poor system performance. It may be due to insufficient memory or dasd, which they should be able to document and provide solutions/suggestions to overcome this issue. Next I would ask them AND IBM, about opening an object for the first time, after installing level 50. It may be that objects being referenced after the upgrade may realize a slowed down performance, that goes away after the first open. This is true with objects after and OS upgrade and may be true in this instance. The bottom line here is: I am guessing and assuming out the wazoo. Check with IBM and your vendor(s) and request documentation to support this. Heck, if the /400 can operate just as fast at 50, then why not go there regardless of your need or lack thereof for increased security. -bret

        Comment


        • #5
          Sec Lvl 50 - performance considerations?

          Here is some data: Run the IBM supplied command PRTSYSSECA and look at the spool file. It has your security values and then IBM's recommendation next to it. Also, go to IBM's redbooks site and search for book GG24-4200-00, a security book written back in 1994 that talks about the performance hit on the system. According to the AS/400 System Administration and Control student notebook (1995), security "level 50 adds 10 to 15% more work on the system." The IBMer that taught the course (Chris Pool) advised that he believed the performance impact was around 23%. With today's processors and performance improvements the impact can be much much less. I haven't found any current data. Obviously there are more features to level 50 than meets the eye. If you read between the lines and note that things cannot be monitored for at lower security levels it does make me wonder exactly what the lower levels leave exposed. If my system were directly accessible from the internet, I wouldn't feel comfortable at anything lower than 50. Scott

          Comment


          • #6
            Sec Lvl 50 - performance considerations?

            Bret Myrick wrote: Heck, if the /400 can operate just as fast at 50, then why not go there regardless of your need or lack thereof for increased security. Because. . . . As one reads previous posts concerning upping the security level, one gets the distinct impression, that things that worked just fine before, are all of a sudden failing, AND, , , all one did was to bump up the security level. According to what a few IBMers have told me, Level 50 was implemented to suit government auditing purposes. It actually does not increase security features over level 40. Dave

            Comment


            • #7
              Sec Lvl 50 - performance considerations?

              One thing I have read about level 50 is that it purges a QTEMP library as soon as a job ends. At level 40 and below, QTEMP objects are held "somewhere" until the next IPL. Chris

              Comment


              • #8
                Sec Lvl 50 - performance considerations?

                All, Thanks for your input. My company is required by the government to be C2 compliant. C2 is "a level of security defined by the US government in the Department of Defense Trusted Computer System Evaluation Criteria (TCSEC) document". To meet the requirements of C2 security we must be at security level 50 - I gather C2 requires some specific settings for certain parameters, There's an AS/400 manual "Security - Enabling for C2" for further reading...... Anyway, the boxes are already at sec lvl 50, but the issue is the developer baulked at adding this extra library to QSYSLIBL. I'm now wondering if it is less to do with level 50 (we have ample memory) and perhaps more to do with the contents of the library. Time for me to check back with the developers & the owners of this new library. In the meantime, thanks for all your input. Regards Ian

                Comment


                • #9
                  Sec Lvl 50 - performance considerations?

                  Chris, The QTEMP is one of the areas I would expect to see affected. Back in the 80's some data from the then Soviet Union fell into our hands because of the magnetic drum that was used in photcopiers. Seems that if you accidently mount a highspeed camera in the copier, it can photograph the images which remain on the drum. "Accidently mount the camera" I would expect that viewing joblogs, history and being able to view another users' QTEMP and current screen are curtailed somewhat as well. This is what I base my guess on. The fact that more things are occuring behind the scenes. -bret

                  Comment


                  • #10
                    Sec Lvl 50 - performance considerations?

                    I'm willing to bet that Ian is not your real name (just kidding ;~) It would be interesting if you had access to more than one production AS/400 system to run benchmark tests at different security levels and see if there really is a difference in performance. I am planning to do that here at my shop. If that new library holds mucho objects and program calls are running the library lists to find objects, then I can see where it could cause extra work on the system. Sorry we seemed to get off the performance track a bit. Scott (Not sure if this is my real name either)

                    Comment


                    • #11
                      Sec Lvl 50 - performance considerations?

                      So how many C2 and Q folks use their real name? Or ISP, or anything? -Bret (And I've got documents that prove it)

                      Comment


                      • #12
                        Sec Lvl 50 - performance considerations?

                        Ian, Most of the speculation in the above notes is wrong. I am a C2 VSA (vendor security analysts) for IBM AS/400 and I have never heard of "Q" security. (Except perhaps in a James Bond movie.) ;-) Adding a library to the system library list will not impact performance at security level 50 any more than it will impact performance at any other security level. On the other hand, it may impact security if anyone has authority to add a Trojan horse command or program to this library. Running at security level 50 takes more resources than running at lower security levels. The biggest change at security level 50 is that some programs do additional parameter validation. Any performance impact will depend on how often those programs are called and how much work they do. (For example, if it takes 10 lines of code (LOC) to do parameter validation then that 10 LOC will have a larger impact on a 100 LOC program than on a 3000 LOC program.) The QTEMP library is cleared at the end of each job at all security levels. The difference with QTEMP at security level 50 is that it is a temporary object at security level 50 and a permanent object at all other security levels. The reason this was done is to prevent one user program from passing pointers to a program in another job. It is necessary to prevent this to be sure that you can audit all sharing of data between two users. Ed Fishel, IBM Rochester

                        Comment


                        • #13
                          Sec Lvl 50 - performance considerations?

                          Ed, The 'Q' clearance has been around since before I was. This was a designator defining those of us with Cryptographic Clearance (above top-secret). We could normally walk into a communications center or nuclear research lab, depending on our specialty, and gather information on a 'need to know' basis. When it came to security, we did not have to 'need to know' specifics to get other details, we were authorised to address a situation at our discretion. Lot's of red-tape involved as our access to records was more meticulously kept than others. AFAIK, the 'Q' still lives, perhaps under a different identifier, but when higher levels of secured, rest assured the government will come up with another acronym. Other than that, I feel rather vindicated in my surmise of the effects of sec lvl 50, and wonder if the vendor is just not compatible with the setting because of some points you made. -bret

                          Comment


                          • #14
                            Sec Lvl 50 - performance considerations?

                            Had to chime in. Someone told me that you cannot adopt authority on Level 50. I never remember reading this and swear that I have done it before. Does level 50 affect adopting authority at all ? Oscar

                            Comment


                            • #15
                              Sec Lvl 50 - performance considerations?

                              Does level 50 affect adopting authority at all ?
                              Authority can be adopted at all security levels. Ed Fishel

                              Comment

                              Working...
                              X