Developers copying reports

  • Thread starter brother_of_karamazov
  • Start date

brother_of_karamazov

Legendary Poster
Maybe I am losing my mind (no comments from the peanut gallery- stooge) but I really recall either an enhancement or a discussion somewhere where we were talking about ways to keep our beloved developer brethren in line.

The issue discussed was that a developer could copy a report in OMW and create a 55 object or change the code to circumvent security.

Anyone else recall this? Anyone recall the solution?
 
Go easy on those developers brother.

brother_of_karamazov <[email protected]> wrote: Maybe I am losing my mind (no comments from the peanut gallery- stooge) but I really recall either an enhancement or a discussion somewhere where we were talking about ways to keep our beloved developer brethren in line.

The issue discussed was that a developer could copy a report in OMW and create a 55 object or change the code to circumvent security.

Anyone else recall this? Anyone recall the solution? Brother Of Karamazov/Jeff Stevenson
 
Jeff

No, you are not losing your mind. Stooge is, but we tolerate him anyway. The gist of the thread was that a developer could make a copy of anything, including the application that controls security, and circumvent the system. I don't recall the exact resolution (other than the person doing it was fired), but I think the mitigating control (to use SOX lingo) is to have strong audit control on key tables and on the control table that monitors JDE projects.

In our shop, the first thing the auditors do is look for a correlation between our Enterprise Change Control database and JDE projects. If they find a JDE project that does not have proper sign-off, then they jump on that like a marauding band of mice in a swiss cheese factory.

Gregg Larkin
Praxair North American System Admin
JDE CNC and Security, Websphere, Tidal, Princeton Softech
 
Something you might want to add to the 'control' mechanism.... Not required
by SOX, but one more step that would design that 'control-freakishness' into
the mix.

If you control what a user/developer can move into projects - you control
what they can modify. Think of it old-school; "in order for a green
screener to look at code, they had to talk to the keeper of the library, who
would 'yay/nay' and move a copy to where they could look at it". If that
type of policy was continued into the OMW mix - the deranged would have less
opportunity to corrupt society....

OMW Cycle was/is meant to be used similarly. Meaning, a MANAGER should be
the one creating their project - the owner of the task should be creating
the project (based on their task), moving the required objects into the
task, assigning a developer to the project and adding/removing objects as
the developer requests.... Old school, yes - but it's the real basis of the
development cycle... Developers Develop - Managers Manage. When Developers
Manage - Life SOXs.

Block the developers from managing will impede progress, but it will avoid
one opportunity for fraudulent access.

(db)
ps - I am a developer, and I'd encourage my manangers to know what I'm
working on. If they were aware of what's happening - things would happen
differently. Yes, I probably think differently; It's a Jeep Thing!
 
Daniel speaks the true gospel!

I am in awe of thy clearness of thought

The solution to all SOX issues can ultimately be found in hiring more people or moving work from one pile to another.
 
[ QUOTE ]
Block the developers from managing will impede progress, but it will avoid one opportunity for fraudulent access.

[/ QUOTE ]

I really had so many things to say about this statement. I'm just going to leave it on its own.

Of course, Developers have personal projects too - do we want to control what objects they put in there too ?

Again, I get carried away - and had to delete a bunch of stuff on this post....

Anyway - I heard that there are rumours at the organization that I'm currently engaged at that we're hiring monkeys for each of our developers. The developers will no longer be allowed to type any information into a keyboard, instead they will have to pass any information to the monkey and the monkey will then type that information. By using a monkey, the company is assured of complete unbiased information being entered into the system. Any communication between the developer and the monkey will need to be written down on notes - which provides the company with full documentation. The monkey doesn't have any linguistic system therefore verbal commands will not work. With this system we are assured that developers cannot fraudulently use the ERP system.

Just remember - Government organizations do not have to abide to SOX.

I'm so glad Karl Rove sold his Enron stock before it tanked....
 
Heres a final thought on this on a much more serious note than before.

Why prevent developers from doing stuff IN DEVELOPMENT ? Developers should NOT have access to Production - take away production access, and lo and behold there IS no SOX issue. TEST/DEVELOPMENT is not covered by SOX compliancy - check Section 404.

However, the code promoted into production IS covered by section 404 - and you need to have your developers provide documentation behind how they developed specific applications. THAT is what IS required - trying to put barriers to a developers' working environment in an area completely separated from production is NOT required, and only aggravates the situation.

If, however, you are in a position where your corporate infrastructure seems to only allow your business to run with developers having access to production - then there is something seriously wrong with your architecture. If developers are running SQL Statements in production - then that is wrong and is absolutely against SOX compliancy. On the other hand, if developers are running SQL Statements in, say, PY and then making formal requests through a ticket system for someone to run these statements in production - then that IS fully documented and you have also segregated those duties accurately.

Auditors will always try and make more money by staying around at a company as long as possible. By throwing up what they conceive as barriers to SOX compliancy, only common sense and a high-level understanding of what SOX is should be required for those individuals assisting the auditors. Remember, it was a failure with the AUDITORS that caused the government to create SOX in the first place - not the failure of corrupt companies like Enron.

Keep that in mind with your next SOX audit...
 
[ QUOTE ]
Maybe I am losing my mind (no comments from the peanut gallery- stooge) but I really recall either an enhancement or a discussion somewhere where we were talking about ways to keep our beloved developer brethren in line.

The issue discussed was that a developer could copy a report in OMW and create a 55 object or change the code to circumvent security.

Anyone else recall this? Anyone recall the solution?

[/ QUOTE ]

I think I ended up finding what I was looking for - OMW Allowed Actions by System Code.


"This enhancement increases the resolution with which the OMW administrator can restrict user actions with the OMW Allowed Actions rules, by adding the objects system code and system code reporting to the criteria by which OMW Allowed Actions rules are defined. For example, with this enhancement, the OMW Administrator can give users playing the user role of developer in a project at status 21, the ability to design applications of system code ’55’ and system reporting code of ’55’ but not applications of system code ’66’ and system reporting code ’66’."

I don't remember the rest of the discussion.
 
The original issue, Krazy Karamazov...and Loony Larkin....was brought up by FNORELLI. Kara, believe you two are aquainted.

However, Krazy's original "self help" fix, is the correct way to do it.

I'm not even getting started on the SOX stuff...I see Kara, I see Quarkie, I see Larkin....I've had enough bashing for the day let alone put out a post on SOX compliance!
 
This whole topic is terribly intriguing, but what you fail to take into account is that an ambitious and dishonest person will always be ambitiously dishonest. If you have one of these people on your staff there is probably very little that you can do in terms of process and simple security to stop them. Programmers by default have access to all the software and the database. The nature of enterprise one makes locking them out even more difficult. For instance, I know how to decrypt the passwords held by E1, but I would never have the nerve to risk myself and use that knowledge to do something dishonest. it's just not in my character. Likewise, it would be no difficult task to simply write a little bit of C code to change my role and submit that in a UBE under someone else's sign on (locally of course). No, you need to start farther up the chain and do your best not to let these people in the organization in the first place. Too many locks on the doors will make your programmers feel like they're in a dungeon and that they are untrustworthy regardless of what they do. I'm sure you don't want that kind of environment.

For my part. When I managed a department of programmers I wanted them to do something interesting on their own. When times were slow, they were allowed to take one whole day of each week and write some kind of interesting program or technique that was out of the box, so to speak, and unrelated to their daily assignments. This kept all of us interested and ultimately created at least a couple of small tools that were very useful. This was when I wrote the DLL, ODBC, and Dialog interfaces. Guitarman wrote a technique for passing data between processes/programs without using data structures which turned out to be really slick. Calling a program three levels down that you need to pass some data to? Don't wanna change any Data Structures? Fine, I've got a solution for you (no, no tables). Of course we all got laid off before we could create anything really big.
grin.gif
 
Darren,

Sounds like Oracle could use you and Guitarman on their Fusion development team. Maybe then it would progress out of the vaporware phase.......
 
Fusion isn't vapor-ware ... its the continuing development of E-Business Suite . . .
smile.gif
 
[ QUOTE ]
Fusion isn't vapor-ware ... its the continuing development of E-Business Suite . . .
smile.gif


[/ QUOTE ]

You are probably correct. The message I got from the Oracle bigwigs at Quest was to start to prepare for the new co-existance. The newer releases of all of their products are being designed to co-exist with each other. When Fusion Apps come along, you can co-exist with a specific module. So in the future, we'll be able to have the following conversation:

"I'll take three eggrolls, a pint of fried rice, a pint of Kung Pow Chicken, One large order of JDE, and a side of Fusion Procurement to go please."

Gregg
 
[ QUOTE ]
[ QUOTE ]
Fusion isn't vapor-ware ... its the continuing development of E-Business Suite . . .
smile.gif


[/ QUOTE ]

...prepare for the new co-existance. Gregg

[/ QUOTE ]

I still haven't recovered from the last one.....
 
[ QUOTE ]
[ QUOTE ]
[ QUOTE ]
Fusion isn't vapor-ware ... its the continuing development of E-Business Suite . . .
smile.gif


[/ QUOTE ]

...prepare for the new co-existance. Gregg

[/ QUOTE ]

I still haven't recovered from the last one.....

[/ QUOTE ]

I'm test marketing that phrase, "the new co-existance". It will be fun to see if it starts poping up in other posts.
grin.gif


Gregg
 
[ QUOTE ]
[ QUOTE ]
Fusion isn't vapor-ware ... its the continuing development of E-Business Suite . . .
smile.gif


[/ QUOTE ]

...prepare for the new co-existance. Gregg

[/ QUOTE ]

Gawd I hope not. I hope that some JDE guy from the past stood up and screamed "NO FREAKING CO-EXISTENCE" at Oracle.

Nothing about co-existence was "good".

However, I think that the fusion middleware solution isn't really co-existence in the same sense we had with Xe and prior - if there had been some sort of middleware between Oneworld and World, then "co-existence" would have been a LOT nicer !

Please - don't use "coexistence" - its got horrible connotations.
 
Back
Top