Chuck,
I've had to read your response several times and I have to say I'm at a loss. You seem to be implying the System I doesn't provide any security features, especially ones auditors will accept.
So let me ask you a question...
If someone can log onto a system can they perform any task they are authorized to regardless of how they sign on ( TELNET, FTP, AREXEC, RUNRMTCMD, HLAPPI API )?
Or two... :)
If someone is forced to provide a user name and password to sign onto a system is the system more secure than if they do not have to provide them?
Gary Monnier
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, May 17, 2012 11:18 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: RMTCMD's security?
On 17 May 2012 09:37, Matt Olson wrote:
Using any of these commands is a PCI security auditors worst
nightmare. You might want to consider alternative options to using
these commands, we had to turn them all off after a security audit.
So is using an alternative to those commands, apparently private features that would do effectively the same thing, somehow better for any of the auditors, programmers, users, the security\integrity of the requesting system, the security\integrity of the target system? If so, then in what ways? Seems to me that if the target system was insecure prior to the access to those features being denied, then the same exposures remain at the target; being denied those methods still leaves any other possible exploits... presumably even including the private replacements.
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.