RE: RMTCMD's security?

Rob,

I'm arguing that SystemX is being ignored as a possible security risk. To be able to access SystemZ from SystemX you have to have at your disposal

1) The tools to do so. If you don't have access to the tools that allow you to leave SystemX what can you do to SystemZ or any other system for that matter?
Without the tools, you are at a deadend.
2) Authority to access SystemZ. The bulwark of most computer system access is a user name and password.

Whatever authorities an individual has on SystemZ are there regardless of how the user signed on.

It doesn't matter if you have 1000s of systems on your network. Each one is secured using these three basic points.

a. Secure who you allow on it.
b. Secure what the individual can do.
c. Secure where and how the individual can go from the system to another.

How these three points are as you say a large subject all of which rests, from an auditor's perspective, as being cleanly auditable. Making a powerful command such as AREXEC auditable may include writing a wrapper, writing a "This command used by" journal entry to QAUDJRN from within the wrapper and then being able to report the journal entries.

Gary Monnier


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Thursday, May 17, 2012 1:14 PM
To: Midrange Systems Technical Discussion
Subject: RE: RMTCMD's security?

Interesting idea Gary. So what you are saying is that let's say you have SystemX, SystemY, SystemZ. And your concern is that a user on SystemX can get to SystemY and use that to initiate nasties on SystemZ. Others, like Scott and I, are arguing that you should be hardening SystemZ to stop attacks on it. Maybe your concern is that perhaps SystemZ was hardened.
Perhaps they have a strong exit point on it to only accept remote commands from the IP address associated with SystemY. Your argument is that you should then secure SystemY's use of remote commands so that they aren't used to leap frog into SystemZ. Am I right so far? Do I get credit for trying to understand your angle? I suppose one could go on that the full litany of commands that could be executed from there should be secured.
Including, but not limited to: TELNET, FTP and a host of api's and pase and qsHell applications available to attack SystemZ from SystemY. Then there's the defense in depth strategy. Not only do you secure access using certain techniques to SystemZ from only being initiated from SystemY, but you also secure them to only being allowed from certain individuals. For example user SAM can only run a remote command from SystemY.

I think Chuck was referring to the "full litany".

gotta go.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: "Monnier, Gary" <Gary.Monnier@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 05/17/2012 03:51 PM
Subject: RE: RMTCMD's security?
Sent by: midrange-l-bounces@xxxxxxxxxxxx



John,

Answers such as yours amaze me. Isn't part of securing a "target" system
ensuring it cannot be used as a leaping point to other systems at which
point once compromised becomes a host system?

Gary Monnier


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [
mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of John Jones
Sent: Thursday, May 17, 2012 12:19 PM
To: Midrange Systems Technical Discussion
Subject: Re: RMTCMD's security?

Secure the machine(s)/hosts that will be the target of the remote
commands.

Securing the endpoint machines machines that will send the command is near
meaningless. All it takes is a rogue device on the network or a
compromised Internet-facing host and secure endpoints won't mean squat.

On Thu, May 17, 2012 at 2:12 PM, Monnier, Gary
<Gary.Monnier@xxxxxxxxx>wrote:

Scott,

By "to" machine do you mean the target system or the host system?

Gary Monnier


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:
midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Thursday, May 17, 2012 11:12 AM
To: Midrange Systems Technical Discussion
Subject: Re: RMTCMD's security?

You should always secure the "to" machine. Securing the "from"
machine isn't even worthy of being called "security".

On 5/17/2012 11:27 AM, rob@xxxxxxxxx wrote:

Should you be securing the "from" machine (ie the system they
initiate the remote command from), or should you be securing the "to"

machine?

--
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.

--
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.

--
John Jones, CISSP
--
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.