Charles, We don't worry about we have customers who sign NDAs ...but I am old school I resist providing source code, which we have , we have exits that integrate. But then again I am basically a New Yorker ...seen a lot crazy stuff and people ...I would rather protect our code somehow..but the question is how ......
Scott ford www.identityforge.com from my IPAD 'Infinite wisdom through infinite means' On Jun 18, 2013, at 7:45 PM, Charles Mills <charl...@mcn.org> 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
