IBM requirement for all z/OS installations:
/z/OS V1R13.0 MVS Authorized Assembler Services Guide -
//SA22-7608-17//- 21.1.2 Installation responsibility//
//
//To ensure that system integrity is effective and to avoid compromising
any of the integrity controls provided in the system, the installation
must assume responsibility for the following:/
* /Physical environment of the computing system./
* /Adoption of certain procedures (for example, the password
protection of appropriate system data sets) that are a necessary
complement to the integrity support within the operating system itself./
* /That its own modifications and additions to the system do not
introduce any integrity exposures. That is, all installation-written
authorized code (for example, an installation SVC) must perform the
same or an equivalent type of validity checking and control that the
system uses to maintain its integrity./
I believe this last requirement should not be limited to just
"installation-written" code but also include ISV authorized code.
////
Ray Overby Key Resources, Inc. Ensuring System Integrity for
z/Series^(TM) www.kr-inc.com (312)574-0007
On 6/18/2013 18:45 PM, Charles Mills wrote:
Sam is correct.
Without giving away a whole lot of details, the code is in a position such
that it could for example (were it malicious) suppress certain security
auditing. (Any APF authorized program can basically do anything, of course,
but it would be fairly trivial for it to do something like I describe.) So
it would not necessarily be in great a position to steal customer data
itself, but if we were malicious, and conspired with a rogue employee, we
could perhaps jointly steal valuable data.
A particular prospect has specifically asked about the possibility of
auditing the source code. I am wondering how that might be handled such that
they were satisfied, but could not steal our IP, nor learn how to defeat our
"keys." I pictured for example opening a folder of code on my PC and letting
them view it by WebEx. I would browse the code for them as they directed. It
would be very difficult for them to steal enough source code in that way to
"steal the product," but it might reassure them. How would they know that
what they saw was what got built? Beats the heck out of me.
My scenario above is not an outlandish hypothesis that could never really
happen. Consider the following, from a presentation I give. I would guess
you can get details from the Google.
Bank of America Insider Theft
Employees sold customer information to prison-based identity theft gang
Cost Bank of America more than $10 million
Celebration, Florida Hospital Records Theft
Registration clerk searched 760,000 patient records for accident victims
Sold data to third party who solicited for chiropractic and legal services
South Carolina Health and Human Services
Employee e-mailed himself 228,435 patient records, including ID numbers
LSU Hospital Identity Theft
Billing clerk used database check images to create fake checks and IDs
416 patients victimized
South Carolina Department of Revenue Breach
74 GB of tax return data including SSNs stolen with employee's credentials
Employee had fallen victim to phishing attack
Texas Department of Health and Human Services
Worker used patient immunization records to obtain credit cards online
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Sam Siegel
Sent: Tuesday, June 18, 2013 3:46 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Auditing vendor source code
On Tue, Jun 18, 2013 at 3:41 PM, Ted MacNEIL <eamacn...@yahoo.ca> wrote:
If that is such an issue, that you really need that level of
assurance, then don't purchase the software.
I think that Charles is asking the opposite question. He works for a vendor
and some of their code runs authorized. He is asking what audit
requirements customers typically have for authorized code from small
vendors.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
