"Be specific. This is only for cardholder data. The PCI doesn't say you
can't keep a database on the DMZ, just not sensitive carholder data."

True, but then PCI only addresses cardholder data. To stay in scope that's
all they can mention.

But think about it. What this standard is really saying is data in the DMZ
cannot be considered secure.

" I've yet to hear of a single IBM i being hacked to gain access to data -
cardholder, patient, or otherwise."

Comments like this really make me shake my head. Why are you entitled to be
notified of every or even any breach on the i platform? A breach has to
meet certain criteria before public notification is required and even those
laws have not been in existence the entire time that OS/400 has been
around. Pre-California SB1386 no notifications were required by anyone.
And breaches need to be a certain size before disclosure is mandatory. And
that's only US state law; in other countries YMMV.

Besides, IBM is still releasing PTFs with the following:

*APAR Error Description / Circumvention*
-----------------------------------------------
Integrity Problem.

CORRECTION FOR APAR XXnnnnn :
-----------------------------
Integrity Problem.

CIRCUMVENTION FOR APAR XXnnnnn :
--------------------------------
Integrity Problem.

Which means there are still security issues being addressed. Which means
our beloved platform's security is not perfect. Which means we still need
to take every reasonable precaution.


On Fri, Apr 15, 2011 at 7:40 PM, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx>wrote:

On 4/15/2011 4:36 PM, John Jones wrote:
Sorry I couldn't get back to this earlier. I'll be brief.

For your sake I hope your companies don't accept credit cards through
these
web interfaces. Placing a database in the DMZ is a direct violation of
PCI
DSS 1.3.7.

Be specific. This is only for cardholder data. The PCI doesn't say you
can't keep a database on the DMZ, just not sensitive carholder data.

Even if you aren't subject to PCI directly, know that more and more
security
professionals are using it as their gold standard. Systems set up with
PCI
controls will pass SOX, HIPAA, and virtually all other forms of audit
with
ease.

Sure. Third-party data that you collect is held to a different standard
than corporate data, thus the extra precautions. And of course, the
reason these protections are in place is because lots of sensitive data
was stored on machines OTHER than IBM i's, and thus hacked. I've yet to
hear of a single IBM i being hacked to gain access to data - cardholder,
patient, or otherwise.

Here's an example. One reason I couldn't get back to this on Wednesday
was
that I was helping with a client survey that was evaluating the security
of
one app that we supply for them to use. The client is one of the top 5
largest banks on earth. This issue was directly addressed by an audit
question. Even though the data we store is not subject to PCI we're
being
asked questions as if it were.

Have a good weekend, folks.


Yes, unfortunately auditors are not necessarily technical. If they
were, they'd probably push for ALL data to be on an IBM i, with complete
object auditing and integrated journaling. And they'd also be less
likely to worry about terms like "DMZ", since the same level of security
can be managed just as easily as simply firewalling off all but specific
ports.

Joe

--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.





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.