× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.