E9 Configurator Hole

Epicor Support has given me the procedure to hide the Free Form button. Problem resolved.

Essentially, hit the Edit button, and go into Customization again (didn't realize this could be done) and change the size of the Free Form button to 0,0.

Save the Customization as HideFreeForm, for example. Go into Menu Maintenance and add that customization. Create another menu item for the non-customized version. Release one to Configurators and the other to System Managers.

Thanks to all that replied.

--- In vantage@yahoogroups.com, Mark Wonsil <mark_wonsil@...> wrote:
>
> > Back to the original concern about SOX compliance, as long as the engineers (and developers) do not have access
> > to the designer in the Production environment a documented development business process should allow you
> > to pass SOX compliance. As part of the development process all proposed changes should be reviewed,
> > authorized and tested
> ...
>
> Jim is right of course. In order to be SOX compliant, you put in
> controls in place where ever needed. Changing the software helps to do
> that but the same could be done with proper third-party control.
> However, I think Chris's point was a good awareness item to know where
> the controls need to be placed.
>
> Mark W.
>
We've just learned of a gaping hole in the 9.04.505c Configurator such that if we don't restrict its use, we'd fail the SOX audit as well as invite data corruption and giving sensitive information to the wrong people.

The Free Form button allows ANY OpenEdge statement, including ones that create/update/read any item of data, even in another company. And since it can also bypass the business objects, can also cause corruption in the hands of an inexperienced person.

To get around this, we're going to customize the Configurator Designer to hide the Edit button as the Free Form button is below that. We'll have an uncustomized version IT personnel can then use. Needless to say, this is very painful to take that button away from the engineers that maintain configurations and put the additional burden on IT.

We've entered an enhancement request as Epicor has to fix this problem.

Does anyone know if the hole still exists in 9.05?
Not sure I follow your concern. While 9 may make it a bit easier to insert the code, configurators both in 8 and 9 have always allowed you to write back to the database using Progress/OpenEdge code bypassing BOs. In 8 you had to do this to write anything back to the sales order beyond a few specific items, in 9 document rules allow you to write it back using the document rules. Not sure if I have ever built a configurator that didn't include some Progress/OpenEdge code either in on-leave statements or for dynamic lists look-ups.

Jim Kinneman

--- In vantage@yahoogroups.com, "chris_robisch" <bluewine@...> wrote:
>
> We've just learned of a gaping hole in the 9.04.505c Configurator such that if we don't restrict its use, we'd fail the SOX audit as well as invite data corruption and giving sensitive information to the wrong people.
>
> The Free Form button allows ANY OpenEdge statement, including ones that create/update/read any item of data, even in another company. And since it can also bypass the business objects, can also cause corruption in the hands of an inexperienced person.
>
> To get around this, we're going to customize the Configurator Designer to hide the Edit button as the Free Form button is below that. We'll have an uncustomized version IT personnel can then use. Needless to say, this is very painful to take that button away from the engineers that maintain configurations and put the additional burden on IT.
>
> We've entered an enhancement request as Epicor has to fix this problem.
>
> Does anyone know if the hole still exists in 9.05?
>
We're not against allowing code, just giving it to engineers so they can peek at other engineers pay rates or muck up the database because they think they know how to code. The Enhancement we want is to put security on the Free Form button such that we can restrict it to fewer people than have access to the configurator.

--- In vantage@yahoogroups.com, "jckinneman" <jckinneman@...> wrote:
>
> Not sure I follow your concern. While 9 may make it a bit easier to insert the code, configurators both in 8 and 9 have always allowed you to write back to the database using Progress/OpenEdge code bypassing BOs. In 8 you had to do this to write anything back to the sales order beyond a few specific items, in 9 document rules allow you to write it back using the document rules. Not sure if I have ever built a configurator that didn't include some Progress/OpenEdge code either in on-leave statements or for dynamic lists look-ups.
>
> Jim Kinneman
>
> --- In vantage@yahoogroups.com, "chris_robisch" <bluewine@> wrote:
> >
> > We've just learned of a gaping hole in the 9.04.505c Configurator such that if we don't restrict its use, we'd fail the SOX audit as well as invite data corruption and giving sensitive information to the wrong people.
> >
> > The Free Form button allows ANY OpenEdge statement, including ones that create/update/read any item of data, even in another company. And since it can also bypass the business objects, can also cause corruption in the hands of an inexperienced person.
> >
> > To get around this, we're going to customize the Configurator Designer to hide the Edit button as the Free Form button is below that. We'll have an uncustomized version IT personnel can then use. Needless to say, this is very painful to take that button away from the engineers that maintain configurations and put the additional burden on IT.
> >
> > We've entered an enhancement request as Epicor has to fix this problem.
> >
> > Does anyone know if the hole still exists in 9.05?
> >
>
Basic question, what are they doing in the designer if they aren't suppose to code? I'm not sure they can lock it down tight, removing the free form code is only one door, in the method rules you can call programs which can be progress code.

There is the configurator tracker that lets them look but not make changes.

JK

PS in my experience management is the only one that thinks that salaries are still secret :)

--- In vantage@yahoogroups.com, "chris_robisch" <bluewine@...> wrote:
>
> We're not against allowing code, just giving it to engineers so they can peek at other engineers pay rates or muck up the database because they think they know how to code. The Enhancement we want is to put security on the Free Form button such that we can restrict it to fewer people than have access to the configurator.
>
> --- In vantage@yahoogroups.com, "jckinneman" <jckinneman@> wrote:
> >
> > Not sure I follow your concern. While 9 may make it a bit easier to insert the code, configurators both in 8 and 9 have always allowed you to write back to the database using Progress/OpenEdge code bypassing BOs. In 8 you had to do this to write anything back to the sales order beyond a few specific items, in 9 document rules allow you to write it back using the document rules. Not sure if I have ever built a configurator that didn't include some Progress/OpenEdge code either in on-leave statements or for dynamic lists look-ups.
> >
> > Jim Kinneman
> >
> > --- In vantage@yahoogroups.com, "chris_robisch" <bluewine@> wrote:
> > >
> > > We've just learned of a gaping hole in the 9.04.505c Configurator such that if we don't restrict its use, we'd fail the SOX audit as well as invite data corruption and giving sensitive information to the wrong people.
> > >
> > > The Free Form button allows ANY OpenEdge statement, including ones that create/update/read any item of data, even in another company. And since it can also bypass the business objects, can also cause corruption in the hands of an inexperienced person.
> > >
> > > To get around this, we're going to customize the Configurator Designer to hide the Edit button as the Free Form button is below that. We'll have an uncustomized version IT personnel can then use. Needless to say, this is very painful to take that button away from the engineers that maintain configurations and put the additional burden on IT.
> > >
> > > We've entered an enhancement request as Epicor has to fix this problem.
> > >
> > > Does anyone know if the hole still exists in 9.05?
> > >
> >
>
So you're okay with an engineer clearing the password of manager?

--- In vantage@yahoogroups.com, "jckinneman" <jckinneman@...> wrote:
>
> Basic question, what are they doing in the designer if they aren't suppose to code? I'm not sure they can lock it down tight, removing the free form code is only one door, in the method rules you can call programs which can be progress code.
>
> There is the configurator tracker that lets them look but not make changes.
>
> JK
>
> PS in my experience management is the only one that thinks that salaries are still secret :)
>
> --- In vantage@yahoogroups.com, "chris_robisch" <bluewine@> wrote:
> >
> > We're not against allowing code, just giving it to engineers so they can peek at other engineers pay rates or muck up the database because they think they know how to code. The Enhancement we want is to put security on the Free Form button such that we can restrict it to fewer people than have access to the configurator.
> >
> > --- In vantage@yahoogroups.com, "jckinneman" <jckinneman@> wrote:
> > >
> > > Not sure I follow your concern. While 9 may make it a bit easier to insert the code, configurators both in 8 and 9 have always allowed you to write back to the database using Progress/OpenEdge code bypassing BOs. In 8 you had to do this to write anything back to the sales order beyond a few specific items, in 9 document rules allow you to write it back using the document rules. Not sure if I have ever built a configurator that didn't include some Progress/OpenEdge code either in on-leave statements or for dynamic lists look-ups.
> > >
> > > Jim Kinneman
> > >
> > > --- In vantage@yahoogroups.com, "chris_robisch" <bluewine@> wrote:
> > > >
> > > > We've just learned of a gaping hole in the 9.04.505c Configurator such that if we don't restrict its use, we'd fail the SOX audit as well as invite data corruption and giving sensitive information to the wrong people.
> > > >
> > > > The Free Form button allows ANY OpenEdge statement, including ones that create/update/read any item of data, even in another company. And since it can also bypass the business objects, can also cause corruption in the hands of an inexperienced person.
> > > >
> > > > To get around this, we're going to customize the Configurator Designer to hide the Edit button as the Free Form button is below that. We'll have an uncustomized version IT personnel can then use. Needless to say, this is very painful to take that button away from the engineers that maintain configurations and put the additional burden on IT.
> > > >
> > > > We've entered an enhancement request as Epicor has to fix this problem.
> > > >
> > > > Does anyone know if the hole still exists in 9.05?
> > > >
> > >
> >
>
Not sure how you made that leap. I was mainly pointing out that locking down a tool that by design is used to alter the database is pretty tough to do. And maybe a bit clumsy but asking what the engineers will use the designer for.

And if the engineers are mainly in there to look at how the configurator works the tracker would be a good option.

JK

--- In vantage@yahoogroups.com, "chris_robisch" <bluewine@...> wrote:
>
> So you're okay with an engineer clearing the password of manager?
>
> --- In vantage@yahoogroups.com, "jckinneman" <jckinneman@> wrote:
> >
> > Basic question, what are they doing in the designer if they aren't suppose to code? I'm not sure they can lock it down tight, removing the free form code is only one door, in the method rules you can call programs which can be progress code.
> >
> > There is the configurator tracker that lets them look but not make changes.
> >
> > JK
> >
> > PS in my experience management is the only one that thinks that salaries are still secret :)
> >
> > --- In vantage@yahoogroups.com, "chris_robisch" <bluewine@> wrote:
> > >
> > > We're not against allowing code, just giving it to engineers so they can peek at other engineers pay rates or muck up the database because they think they know how to code. The Enhancement we want is to put security on the Free Form button such that we can restrict it to fewer people than have access to the configurator.
> > >
> > > --- In vantage@yahoogroups.com, "jckinneman" <jckinneman@> wrote:
> > > >
> > > > Not sure I follow your concern. While 9 may make it a bit easier to insert the code, configurators both in 8 and 9 have always allowed you to write back to the database using Progress/OpenEdge code bypassing BOs. In 8 you had to do this to write anything back to the sales order beyond a few specific items, in 9 document rules allow you to write it back using the document rules. Not sure if I have ever built a configurator that didn't include some Progress/OpenEdge code either in on-leave statements or for dynamic lists look-ups.
> > > >
> > > > Jim Kinneman
> > > >
> > > > --- In vantage@yahoogroups.com, "chris_robisch" <bluewine@> wrote:
> > > > >
> > > > > We've just learned of a gaping hole in the 9.04.505c Configurator such that if we don't restrict its use, we'd fail the SOX audit as well as invite data corruption and giving sensitive information to the wrong people.
> > > > >
> > > > > The Free Form button allows ANY OpenEdge statement, including ones that create/update/read any item of data, even in another company. And since it can also bypass the business objects, can also cause corruption in the hands of an inexperienced person.
> > > > >
> > > > > To get around this, we're going to customize the Configurator Designer to hide the Edit button as the Free Form button is below that. We'll have an uncustomized version IT personnel can then use. Needless to say, this is very painful to take that button away from the engineers that maintain configurations and put the additional burden on IT.
> > > > >
> > > > > We've entered an enhancement request as Epicor has to fix this problem.
> > > > >
> > > > > Does anyone know if the hole still exists in 9.05?
> > > > >
> > > >
> > >
> >
>
I am sympathetic to Chris's argument. All of the user code included in
Vantage/Epicor can be used to circumvent regulatory and business
logic. This is not only true for the Product Configurator but BPMs as
well. I'm sure that I'm in the minority, but I have little use for the
updateTableBuffer.p routine for this very reason.

I was going to give a talk at Perspectives on the Product Configurator
and this was actually going to be one of my talking points. While the
template-based configurations are far more versatile, one loses all
engineering control because a product can be changed outside the
system with an Excel/Flat file look-up which is not revision
controlled.

In Epicor 9 came the advent of BAQs populating look-ups, one can
regain engineering control. Options can now be added to an "option
BOM" which can be maintained through the normal Engineering Workbench
process.

Epicor 9 now allows one to update Sales Order lines and Purchase Order
lines without the use of the updateTableBuffer.p kluge.

I don't think the situation is untenable. I agree with Jim that the
Tracker is a good start but it would be better if it expanded the code
that is called by configurator events.

Mark W.
Back to the original concern about SOX compliance, as long as the engineers (and developers) do not have access to the designer in the Production environment a documented development business process should allow you to pass SOX compliance. As part of the development process all proposed changes should be reviewed, authorized and tested. All changes should be done in a development environment before being released to a test environment prior to going to Production. The actual release process should be handled by someone other than those that developed it. Just as in the accounting department if proper checks and balances are implemented changes to the system can be done without impacting SOX compliance. Given that just about all Epicor clients customize Epicor to some degree and pass SOX compliance the ability of the configurator to read/write directly to the database shouldn't get in the way of SOX compliance.

JK

--- In vantage@yahoogroups.com, Mark Wonsil <mark_wonsil@...> wrote:
>
> I am sympathetic to Chris's argument. All of the user code included in
> Vantage/Epicor can be used to circumvent regulatory and business
> logic. This is not only true for the Product Configurator but BPMs as
> well. I'm sure that I'm in the minority, but I have little use for the
> updateTableBuffer.p routine for this very reason.
>
> I was going to give a talk at Perspectives on the Product Configurator
> and this was actually going to be one of my talking points. While the
> template-based configurations are far more versatile, one loses all
> engineering control because a product can be changed outside the
> system with an Excel/Flat file look-up which is not revision
> controlled.
>
> In Epicor 9 came the advent of BAQs populating look-ups, one can
> regain engineering control. Options can now be added to an "option
> BOM" which can be maintained through the normal Engineering Workbench
> process.
>
> Epicor 9 now allows one to update Sales Order lines and Purchase Order
> lines without the use of the updateTableBuffer.p kluge.
>
> I don't think the situation is untenable. I agree with Jim that the
> Tracker is a good start but it would be better if it expanded the code
> that is called by configurator events.
>
> Mark W.
>
> Back to the original concern about SOX compliance, as long as the engineers (and developers) do not have access
> to the designer in the Production environment a documented development business process should allow you
> to pass SOX compliance. As part of the development process all proposed changes should be reviewed,
> authorized and tested
...

Jim is right of course. In order to be SOX compliant, you put in
controls in place where ever needed. Changing the software helps to do
that but the same could be done with proper third-party control.
However, I think Chris's point was a good awareness item to know where
the controls need to be placed.

Mark W.
w
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Mark Wonsil <mark_wonsil@...>
Sender: vantage@yahoogroups.com
Date: Sat, 14 Aug 2010 14:16:51
To: <vantage@yahoogroups.com>
Reply-To: vantage@yahoogroups.com
Subject: Re: [Vantage] Re: E9 Configurator Hole

> Back to the original concern about SOX compliance, as long as the engineers (and developers) do not have access
> to the designer in the Production environment a documented development business process should allow you
> to pass SOX compliance. As part of the development process all proposed changes should be reviewed,
> authorized and tested
...

Jim is right of course. In order to be SOX compliant, you put in
controls in place where ever needed. Changing the software helps to do
that but the same could be done with proper third-party control.
However, I think Chris's point was a good awareness item to know where
the controls need to be placed.

Mark W.



[Non-text portions of this message have been removed]