Secure by Company - Business Unit Security / ROW Security?

Hi,

I'll try and keep it brief (may be a challenge ) -

In short, security has been more or less overlooked at the site I work at (there's a first!). Yes - there is some basic security defined but a lot of work to be done.

It has been decided that as a starting point or a 'quick win', we need to secure the users to the data they can see / retrieve from the system (using company).

So, I've been having a play with the new Business Unit Security in our release of E1 (8.11). This is fine but requires us to identify a list of transaction tables that we want to secure. This is quite a large task in itself and so the question was raised 'Why don't we use Row Security against *ALL tables for defined Roles?'. Obviously, this will have a performance hit but we are currently testing this on our Dev System and on the whole it does the job.

I have some Apps people currently testing and some errors are popping up e.g. Batch Post fails with security configured at company level (an issue known by Oracle but with no resolution).

Just wanted to get some ideas/thoughts on this whole area. Anyone going through/been through a similar exercise? Is what we are testing the 'proper' way of going about this task?

I have an idea of how security should have been tackled, having worked previously for a company that spent 18 months or so planning/implementing security with a dedicated Security Officer/team. But obviously at my current site, it's fairly late in the day for this . So I really am after how we can achieve the 'quick win' or 'can we?' for the moment.

Thanks / Best Regards,

Sanjeev

ps. I'm a CNC bod

Sanjeev,

My suggestion is simple but painful. The best way to do security is to do it correctly. Don't go looking for shortcuts. The "closed door" approach is the best way to set up security. It takes a lot of work to set up, but it is the right thing to do. I'll mention one piece of software to look at, no plug intended since it is not soemthing I use, QSoft. They have what looks like a slick solution for mananging security from a "modular" perspective. I haven't used their software, so your mileage may vary. Good luck, sounds like you've got a large unpleasent job ahead of you.

Gregg Larkin
North American CNC and Security Officer, Praxair Inc.

Thanks for your reply Gregg.

I share your sentiments and have been trying to get this fact across. Security will become a priority project shortly and the 'closed door' approach will enevitably be the way forward.

Ha! No need to 'pitch', guess what we used at my last company?! Here, they already decided it's too expensive and they will not invest in this product.

In the meantime, as a seperate exercise, we are just trying to secure the data ie. what a user can see/input. So not really a shortcut as such but an 'interim' step.

Thank/Best Regards,

Sanjeev

Sanjeev,

You made two interesting quotes:

[ QUOTE ]
No need to 'pitch', guess what we used at my last company?! Here, they already decided it's too expensive and they will not invest in this product.

[/ QUOTE ]

and

[ QUOTE ]
In short, security has been more or less overlooked at the site I work at (there's a first!). Yes - there is some basic security defined but a lot of work to be done.

[/ QUOTE ]

It sounds to me that you have some inexperienced project managers. At least inexperienced from a JDE perspective. Once you have gone through one or two JDE implimentations, you realize that you cannot postpone security. You also realize that it is now cheap. How can a management team that let security slide be qualified to dismiss out of hand as "too expensive" a piece of software and a methodology to quicker security implimentation?

What your company needs is two quality estimates on implimenting security. Have one estimate using the native toolset and methodology, and one using the software package. For good measure, do an estimate using internal resources vs using some hired guns to get things started. If they did an honest assesment, they would come to realize that hiring a consultant or three and/or bringing in some software would be very cost effective.

Gregg Larkin
Praxair, Inc.

I am with you on this one Greg. Upon arriving at my present employer I had to hammer home the fact that security needed to be a pre-go live issue and not a post go live issue. As others may be able to testify too - going to an "all doors closed" policy after the fact can be next to impossible, even with QSoft. I talked my employer into purchasing it here and it has come in quite handy even though we are actually implementing an "all doors open" policy now and going back role by role and implementing a closed policy. There are three main components of an all doors closed policy. Application, Action, and Processing Option. Right now we are "all doors closed" in the processing option arena only. Next we will be going role to role and implementing "all doors closed" for action security. We may never get around to implementing it on the application side.

I must say that an "all doors open" policy is attainable it to is difficult and essentially consists of a lot of exit and action security. Either way you go, I can't imagine doing it without the benefits that QSoft has given us. Just my thoughts....

A word on the Business Unit Security functionality - bear in mind that, at the end of the day, this new application is acting merely as an engine for creating and managing row security records in the Security Workbench table. After evaluating it twice now, I still end up thinking it's not ready for prime time yet, since it generates many more row security records than simply setting up the row security records directly. Maybe, I'm old school, but I prefer the capability to manipulate the file directly rather than working through an intermediate application that isn't adding that much value.

Second, beware "quick wins". Denying access to companies is actually addressing only a fairly moderate risk. It is much more imperative to address the separation of duties issues that can lead to Sarbanes-Oxley audit findings, or worse, money walking out the door. I would hate to see the urgency you've successfully created around this issue dissipated because you've "done something" about it. Security is all about risk management - address the biggest risks first.

[ QUOTE ]

So, I've been having a play with the new Business Unit Security in our release of E1 (8.11). This is fine but requires us to identify a list of transaction tables that we want to secure. This is quite a large task in itself and so the question was raised 'Why don't we use Row Security against *ALL tables for defined Roles?'. Obviously, this will have a performance hit but we are currently testing this on our Dev System and on the whole it does the job.


[/ QUOTE ]

Hi Sanjeev,

This is exactly what I did when implementing row security at our company. Specifying individual tables was just going to take far too long and end up being too complex, so I added security against *ALL for Company. We had some teething problems, mainly performance problems with indexes, but it's now running like a dream for about 1000 users.

[ QUOTE ]

I have some Apps people currently testing and some errors are popping up e.g. Batch Post fails with security configured at company level (an issue known by Oracle but with no resolution).


[/ QUOTE ]

We had similar 'random' errors like this and I can remember spendings weeks trawling through log files before finding the causes. One major thing I did was to ensure that I didn't secure the 'default' companies. On our system these are 00000 and 99999. Unsecuring those fixed all the random problems. Maybe you could try this?

[ QUOTE ]

Just wanted to get some ideas/thoughts on this whole area. Anyone going through/been through a similar exercise? Is what we are testing the 'proper' way of going about this task?


[/ QUOTE ]

It sounds like you're going about things the right way. I was in a similar position to you when I inherited our old security setup. I had to make changes - including adding row/company security - to a live system and just kinda hope it would work. Our major problem was performance, but we worked through the problems as methodically as we could and we got there in the end.

My understanding of BU Security (we are on Xe) is that it is just as Joel said - a front end to row security. Which may have big performance ramifications. We only use row security in very limited cases as we have a 2 TB prod DB.

What we have done - which may be an option for you - is to set up either separate environments, or just OCM mappings by group (which you can't do in 8.11 due to multiple roles so you are stuck with OCMs for environments) with a 'shadow table'. For example, we have one set of users that can only see 10 specific business units. We created a new data source and put a new F0006 in there just with the 10 business units. Then we OCM mapped those users (who are in one group) to this new F0006. No performance impact but definitely fiddly for CNC. This limits those users to those 10 Business Units.

Hope this helps.

Sue
Xe SP23J1 iSeries V5R3 Coexistent

I just wanted to comment on the performance of using row security, because this subject is frequently brought up and the usual point of view does not make sense: it generally should have no negative effect, because what you are essentially doing is retrieving less data from the database, which is a performance-improving thing to do, similar to using any other "WHERE" clause filter.

E.g.: if there's a good index (which includes BU fields in this example) and the row security restrictions are supposed to filter out 90% of rows, then it should improve the performance of the resulting SQL ten-fold.

On the other hand, all security gets cached by JDE, so there would be a small overhead of managing it, which would grow with the size of the security table.

Realistically, using row security can only cause performance issues, if the database optimizer gets confused (because of bugs, or incomplete stats, etc.) and opts to use an incorrect index. This should be an exception, rather than a rule and can usually be rectified by tuning.

Just to append to what Alex has stated - Row Security can have and adverse affect.

At one site - the client had over thirteen rows of security on Business Unit. Simple financial reports were taking several hours to complete. When the SQL statement would be captured and run in 'Aqua' - the SQL statement was taking several hours to complete... When we omitted several clauses from the statement - it ran in seconds.

Eventually we got them to remove several rows of securety from the Business Unit - and the report completed (with NO OTHER CHANGES) in less than ten minutes.

We never determined the magic number or the cause - just identified that the issue was security.

(db)

Thanks for all your replies. There are a lot of valid and interesting comments been made and I'll try to bare some of these in mind.

Best Regards,

Sanjeev

Very likely, the DB in this case was selecting a wrong index - when the statement has lots of filters on one field, the DB may decide that because it's so selective, it may be a good idea to start using an index based on this field instead. Which, of course, can be an incorrect decision. Maybe the stats were out, or a good index was missing.

Yes it can be somewhat touchy at times. But it should not cause such issues in general. And any such issues can typically be avoided by DB maintenance/tuning.

I wish what Alex is saying is more widely understood - that row security requires monitoring and tuning at the database level to maintain performance, but does not inevitably cause performance degradation. Unfortuantely, historically JD Edwards has stated in the documentation that row security has a flat out negative impact on system performance, and those statements are taken as gospel. Administrators and users are left trying to do all sorts of tricks and workarounds to achieve the same result without using row security when it would be simpler to adopt a good row security design and tune the system accordingly.

Thanks! That was exactly the point I was trying to make.