Re: Looking for information on PCI Code Security Reviews -- MIDRANGE-L

Also note that while some PCI requirements, ie. concerning the
handling CC# itself, may require inspection/changing of the current
application; the code review requirement applies to custom code
_changes_.

You are not technically required to review all existing custom code to
insure compliance with current secure coding recommendations.

It might be a good idea for public facing web apps, but internal 5250
could be another story.

Charles

On Tue, Jan 27, 2009 at 12:45 PM, Alan Shore <AlanShore@xxxxxxxx> wrote:

"My guess is that there is nothing specific to System i, which is what my
client is looking for. My recommendation will very likely be that they
look at moving those applications covered by PCI off the System i because
it will be simpler to fulfill the requirements of the regulatory bodies.
Which will unfortunately end up with another System i decommissioned."

Has anybody just sat down to quickly analyze what may need to be changed in
the present system.
We converted 2 System i's (U.S. and U.K.) The second conversion (UK) was
MUCH easier as the groundwork was mostly done in the first one (US)
Your possible recommendation to move to another system will probably cost
MUCH, MUCH more than a group of people analyzing the present system to make
it PCI compliant.
The U.S. system took 18 months all told to convert
The U.K. system 6 months
In both cases, changes were constantly being made to the system for other
projects at the same time.

From past experiences, what may be the simpler method CAN turn out to be

the MUCH harder and MORE expensive method

Alan Shore
Programmer/Analyst, Distribution
E:AShore@xxxxxxxxxxx
P:(631) 200-5019
C:(631) 880-8640
"If you're going through Hell, keep going" - Winston Churchill

midrange-l-bounces@xxxxxxxxxxxx wrote on 01/27/2009 11:02:52 AM:

Jim,

That still leads me back to my original question. When the referenced
document says:

---Quote-->
Properly implemented, one or more of these four alternatives could meet
the intent of Option 1 and provide the minimum level of protection

against

common web application threats:

1. Manual review of application source code
2. Proper use of automated application source code analyzer (scanning)
tools
.
.
.
Manual reviews/assessments may be performed by a qualified internal
resource or a qualified third party. In all cases, the individual(s) must

have the proper skills and experience to understand the source code

and/or

web application, know how to evaluate each for vulnerabilities, and
understand the findings. Similarly, individuals using automated tools

must

have the skills and knowledge to properly configure the tool and test
environment, use the tool, and evaluate the results.
<---End Quote

Are there any tools for System i to do the automated scanning of RPG code

related to security (and associated training) or training focused at
qualifying an individual for the manual review process?

My guess is that there is nothing specific to System i, which is what my
client is looking for. My recommendation will very likely be that they
look at moving those applications covered by PCI off the System i because

it will be simpler to fulfill the requirements of the regulatory bodies.
Which will unfortunately end up with another System i decommissioned.

Kendall Kinnear

From:
"Jim Franz" <franz400@xxxxxxxxxxxx>
To:
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date:
01/26/2009 09:33 PM
Subject:
Re: Looking for information on PCI Code Security Reviews

This is an explanation of the code review, from the PCI Security

Standards

Council (that wrote the
PCI requirements). It's not a 5 or 10 or even 30 word answer... it's a
several pages answer and that
is what you have to read.

https://www.pcisecuritystandards.
org/pdfs/infosupp_6_6_applicationfirewalls_codereviews.pdf

btw - I wonder how many in our community of iSeries shops have no clue as

to
the requirements (
entities that transmit, process, or store payment card data) that is due
this Oct and the
consequences of inaction ... https://www.pcisecuritystandards.org/

Jim Franz

----- Original Message -----
From: <KKinnear@xxxxxxxxxx>
To: <MIDRANGE-L@xxxxxxxxxxxx>
Sent: Monday, January 26, 2009 10:42 AM
Subject: Looking for information on PCI Code Security Reviews

I've been inactive for awhile due to medical issues but I'm back and
fully
involved again so I thought I'd turn to some of the best experts

around

for some help.

I have a client looking for experience with or information concerning

Code
Security Review processes related to System i and/or Infinum. The
Mastercard/Visa PCI requirements specify that when there is custom

code

that accesses credit card data someone trained in code security must
review the code prior to production implementation. Any information

on

best practices or education specifically targeted at System i is
appreciated.

We disagree on the intrepretation of some of the wording. Everything
I've
read says an organization that is trained in Code Security Review

must

audit the changes. That could be intrepreted to say that an outside
organization must review the code. My client believes the code can be
reviewed by someone else within the company not involved in the
development project. Any ideas of which intrepretation might be

correct.

Thanks for any help!

Kendall Kinnear
Senior Systems Architect

KS2 Technologies, Inc
1020 Mustang Dr
Grapevine, TX 76051

Office: 817.310.1817
Fax: 817.310.1801
Mobile: 214.676.3146
email: KKinnear@xxxxxxxxxx

http://www.ks2inc.com
--
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.

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