| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Mr. google could not find description for amqoamd |
« View previous topic :: View next topic » |
| Author |
Message
|
| Vitor |
 Posted: Fri Oct 02, 2009 8:07 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
First and foremost: The lack of a documentation page in the WMQ System Admin manual is auditor nit-picking. Yes, it would be better if it was documented, but ...
The amqoamd program is provided by IBM as part of product installation. Like amqsput or crtmqm, it is self-documenting. It provides a consistent view of security settings that are a requirement of an audit.
|
Auditors do nothing but nit-pick. It's the point. There are many applications supplied as part of the product installation which are not in the documentation. This is because they're not intended to be used directly by the end-user, or used outside of a support call. The lack of documentation means that it's behavour cannot be relied upon between versions (one reason for it to fail audit), there's no guarantee that IBM will support it (a second reason) and there are supported alternatives (a third reason).
| bruce2359 wrote: |
| In order to pass audit, you need only demonstrate that you have a procedure, that the procedure produces the desired and consistent results, and that the procedure is followed consistently. |
You have very relaxed auditors. Most auditors who are brought in from outside to do an audit tend to be far more rigourous (or as you accurately termed it, nit picking) and love this sort of thing.
Bottom line - jeevan has to pass an external audit. The options are to confess that this command can't be supported via the documentation, or make your point that there is proceedure, it is and will be into the future produce desired and consistent results and it's followed.
It's a choice, and jeevan will make it. If it was me (and it's not) I'd be going "oops" and finding a different command. If for no other reason that now the auditors have found something to write in their report, they'll stop looking for other things...... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Oct 02, 2009 8:49 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The lack of documentation means that it's behavior cannot be relied upon between versions (one reason for it to fail audit) |
But the behavior can be relied upon (predictable and repeatable results) for this version. The next version will include a version-specific instance of the program. This is not a sufficient reason to fail audit.
| Quote: |
| there's no guarantee that IBM will support it (a second reason) |
Home-grown applications suffer from this, as well. But the app produces predictable and repeatable results. Lack of guarantee of support is not a sufficient reason to fail audit.
| Quote: |
| and there are supported alternatives (a third reason). |
The existence of supported alternatives is not a sufficient reason to fail audit.
| Quote: |
| You have very relaxed auditors. |
Not really. Over the years, we had all of the big-5. All were nit-picky.
But, the only significant requirements to pass audit is that a procedure meet generally accepted business and accounting principles, and that the procedure must produce predictable and repeatable results.
The issues of ownership and/or future version support of the programs are not sufficient to fail audit. While these may be items to be brought to the board of directors, they are not sufficient to fail audit.
The purpose of an audit is to determine if the business is at risk. Amqoamd is a nit in this sense. I've done battle over this kind of issue (we wrote similar apps for RACF and 3rd-party security), and the auditors finally agreed (read: lost).
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 02, 2009 9:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
But the behavior can be relied upon (predictable and repeatable results) for this version. The next version will include a version-specific instance of the program. |
You have an inside track to IBM? You know they're not going to retire this app in the next version? You certainly won't know until it fails because there will not be a reference to it's departure in the "New in this version" document; unless there's a line like "removal of the application that didn't appear here" of course.
| bruce2359 wrote: |
| Quote: |
| there's no guarantee that IBM will support it (a second reason) |
Home-grown applications suffer from this, as well. But the app produces predictable and repeatable results. Lack of guarantee of support is not a sufficient reason to fail audit. |
Home grown applications are supported. Unless your development team have a great lawyers.
| bruce2359 wrote: |
| Quote: |
| and there are supported alternatives (a third reason). |
The existence of supported alternatives is not a sufficient reason to fail audit. |
I was once told it was.
| bruce2359 wrote: |
| The purpose of an audit is to determine if the business is at risk. Amqoamd is a nit in this sense. I've done battle over this kind of issue (we wrote similar apps for RACF and 3rd-party security), and the auditors finally agreed (read: lost). |
Auditors never lose; they just write an appendix. I too have fought the same battle, sometimes winning, sometimes losing. A lot depends on the board, their definition of risk and the auditor in question.
Like I said, jeevan must tackle this as is appropriate to the local situation.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jeevan |
| Posted: Fri Oct 02, 2009 10:13 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| Vitor wrote: |
| bruce2359 wrote: |
But the behavior can be relied upon (predictable and repeatable results) for this version. The next version will include a version-specific instance of the program. |
You have an inside track to IBM? You know they're not going to retire this app in the next version? You certainly won't know until it fails because there will not be a reference to it's departure in the "New in this version" document; unless there's a line like "removal of the application that didn't appear here" of course.
| bruce2359 wrote: |
| Quote: |
| there's no guarantee that IBM will support it (a second reason) |
Home-grown applications suffer from this, as well. But the app produces predictable and repeatable results. Lack of guarantee of support is not a sufficient reason to fail audit. |
Home grown applications are supported. Unless your development team have a great lawyers.
| bruce2359 wrote: |
| Quote: |
| and there are supported alternatives (a third reason). |
The existence of supported alternatives is not a sufficient reason to fail audit. |
I was once told it was.
| bruce2359 wrote: |
| The purpose of an audit is to determine if the business is at risk. Amqoamd is a nit in this sense. I've done battle over this kind of issue (we wrote similar apps for RACF and 3rd-party security), and the auditors finally agreed (read: lost). |
Auditors never lose; they just write an appendix. I too have fought the same battle, sometimes winning, sometimes losing. A lot depends on the board, their definition of risk and the auditor in question.
Like I said, jeevan must tackle this as is appropriate to the local situation. |
I have given a management document to them. I am not sure why the auditor was interested in that particular command. The procedure is well laid in the document. Also, we have a well establshed procedure. But what the auditor will do will only be known then he/she finishes the audit and my manager gets back to me. This is what I can tell now Definitely, this discussion gave me some insight and if my manager comes back, I will try to convince him instead of saying there is not enough documentation of the command. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 02, 2009 10:38 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I will try to convince him instead of saying there is not enough documentation of the command. |
Some final thoughts and a brief summary of my issues with all of this:
Over the life of WMQ, there have been some undocumented options of the documented control programs. Some control programs remain undocumented, but have been part of the distribution for years. Much of the internal behavior of WMQ is proprietary and not documented. New control programs will likely emerge with new releases, and with varying degrees of documentation.
Should lack of absolute and complete documentation (including source code) be a show-stopper? Is it? Is it for your o/s? It isn't for most other applications - home-grown or licensed.
If lack of doc on a supplied utility is all that the auditors have discovered, either your shop is a miracle, or your auditors are idiots. (I feel better now.)
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| jeevan |
| Posted: Fri Oct 02, 2009 11:26 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| bruce2359 wrote: |
| Quote: |
| I will try to convince him instead of saying there is not enough documentation of the command. |
Some final thoughts and a brief summary of my issues with all of this:
Over the life of WMQ, there have been some undocumented options of the documented control programs. Some control programs remain undocumented, but have been part of the distribution for years. Much of the internal behavior of WMQ is proprietary and not documented. New control programs will likely emerge with new releases, and with varying degrees of documentation.
Should lack of absolute and complete documentation (including source code) be a show-stopper? Is it? Is it for your o/s? It isn't for most other applications - home-grown or licensed.
If lack of doc on a supplied utility is all that the auditors have discovered, either your shop is a miracle, or your auditors are idiots. (I feel better now.) |
bruce2359,
As I said, I can not say anything at the moment, how my manager/company approaches this sort of issues. A few month ago, my manage asked me to create a MQ config management document( which tells what we do and how we do). Now the auditor is auditing based on the document provided. Whether he focuses on procedure or insists on the command documentation it is still unknow. It is heavily depends on the idiosyncrasy of an individual. For example. the PCI audotor of this year questions on data on rest issues not data on transit. This was the single question. But last year, the auditor took me more than an hour to answer his various questions.
I will not be surprised to know one more idiot. Don't you think the world is full of idiots? |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Oct 02, 2009 12:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jeevan wrote: |
| It is heavily depends on the idiosyncrasy of an individual. |
| jeevan wrote: |
| For example. the PCI audotor of this year questions on data on rest issues not data on transit. This was the single question. But last year, the auditor took me more than an hour to answer his various questions. |
| jeevan wrote: |
| I will not be surprised to know one more idiot. Don't you think the world is full of idiots? |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Oct 02, 2009 12:06 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Don't you think the world is full of idiots? |
There does seem to be an endless supply.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Sat Oct 03, 2009 1:06 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
apart from the discussion on the amqoamd command itself, I am interested to know what you gave to the auditor?
the actual output of amqoamd or something a little more nicely formatted ?
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| jeevan |
| Posted: Sat Oct 03, 2009 6:12 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| Michael Dag wrote: |
apart from the discussion on the amqoamd command itself, I am interested to know what you gave to the auditor?
the actual output of amqoamd or something a little more nicely formatted ? |
We already have a mq configuration managmeent doc where I have explained the use of it. This time, I gave nicely formatted usage of the command as follows:
amqoamd: dumping current authorization
Usage: amqoamd [-m QMgrName ] [-t ObjType] [-n ObjName] [-f|s]
-f old authorization file format
-s output setmqaut commands
Also, explained each of the switch in greater details. Furthermore, I also gave part of the output and how we parse the file and compare with the existing security record ( which is stored in repository).
I is ridiculous, but true. I saw my manager was also googling ( [probably he could not believe me on that there is not formal doc of a command). I saw that when we were looking something else in his screen.
I have not heard back. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
