Re: iSeries public WEB access, PCI security issues

Sounds credible, but the computer that runs the web server has access to
the one that runs the database, etc. so, if one computer gets
compromised, from that one it is easy to reach the rest.

Matt Olson wrote:

I also forgot in the my message, the whole basis for segregation of dutys

is a good one. It was explained well by the PCI folks if you ever talk to
an auditor.

The point of segregating out into separate dutys is to minimize the

attack surface of any one machine because you can't trust that every single
piece of software you run on that machine is 100% bug free and will not
destabilize any other component of the system. No one can claim this, not
IBM, not Microsoft, not any one of the OSS dudes. If they do, they are
lying to you.

DNS is a good example, you've seen all the horror storys of many, many

BIND flaws over the years. Just search google for "DNS BIND Flaw" and
you'll find thousands of hits.

So lets say you run BIND on your IBM i box, along with your WAS, your FTP

server, your DB2 database.

Bind flaw X is exploited (whether through denial of service type of

attack or privilege escalation, etc) you expose all the other services on
that box (WAS, FTP, DB2).

So now you have all these other services including your critical DB2 data

at risk. When if you had properly segregated these servers out, you would
have just exposed your DNS data.

Therefore, PCI security councils logic is sound regardless of server OS/

platform, etc if you carry this through to all the potential vulnerabilitys
in WAS, FTP, etc. There are some really nasty FTP bugs out that that can
basically give you root access. And if your looking for websphere bugs,
just search for them, there are LOTS.

So now, is that a better rebuttal, do you understand the PCI security

councils intent a bit better?

-----Original Message-----
From: Matt Olson [mailto:Matt.Olson@xxxxxxxx]
Sent: Tuesday, September 03, 2013 1:18 PM
To: Midrange Systems Technical Discussion
Subject: RE: iSeries public WEB access, PCI security issues

I never said Wintel, you did. I said Intel. Pick your OS flavor and run

with it. FYI, Azure is your thousand of applications proof of concept you
are elusive to find and is very public :-). Or grab yourself a 64
processor x 8 core intel server, pick your OS, and theres your thousands of
applications. Anyone can make something like Azure on premise if you got
the know-how and money to pull it off. The same know how and money is
required for i.

The only thing that destabilizes these systems is the application itself.

Don't go blaming application from vendor XYZ and say "Microsoft" or
"Linux" made a bad product. Vendor XYZ did, or better yet, programmer XYZ
did :-)

There is nothing, zero that you can't do on other intel platforms that

you can only do on an i.

-----Original Message-----
From: Nathan Andelin [mailto:nandelin@xxxxxxxxx]
Sent: Tuesday, September 03, 2013 1:09 PM
To: Midrange Systems Technical Discussion
Subject: Re: iSeries public WEB access, PCI security issues

Matt,

We were talking about distributed application architecture. But you

switched the conversation to hardware redundancy. Foul play. Let's say the
IBM i server is synchronized with a remote backup to recover quickly from
catastrophic hardware failure.

Were you ever going to get around to supporting your claim that Wintel

servers can run thousands of applications "just like i"?

-Nathan

----- Original Message -----
From: Matt Olson <Matt.Olson@xxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Cc:
Sent: Tuesday, September 3, 2013 11:17 AM
Subject: RE: iSeries public WEB access, PCI security issues

Your raid controller just failed on your single i box that runs

EVERYTHING. Instead of just one of the web front ends failing, your whole
system just went down. Hmm. Sounds like poor infrastructure design.

Theres your rebuttal.
--
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.

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