"Businesses" are not in business to steal secrets, someone said (or something 
like that) in an earlier post. But legitimate businesses have unscrupulous 
employees, as many of the pieces of anecdotal evidence in the post below show. 


Then there is this additional piece of anecdotal evidence: large Wall Street 
bank(s) and other financial institutions colluded with high officials of the 
United States government to steal 10 trillion dollars from investors all over 
the world, but especially American middle-class home owners. But there is no 
real evidence and no laws were broken, so no one will be punished. 


Quis custodiet custodies ipsos? (or something like that) 


Bill Fairchild 
Franklin, TN 

“Political language is designed to make lies sound truthful and murder 
acceptable, and to give the appearance of solidity to pure wind.” [George 
Orwell] 

----- Original Message -----
From: "Charles Mills" <[email protected]> 
To: [email protected] 
Sent: Tuesday, June 18, 2013 7:45:09 PM 
Subject: Re: Auditing vendor source code 

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:[email protected]] On 
Behalf Of Sam Siegel 
Sent: Tuesday, June 18, 2013 3:46 PM 
To: [email protected] 
Subject: Re: Auditing vendor source code 

On Tue, Jun 18, 2013 at 3:41 PM, Ted MacNEIL <[email protected]> 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 [email protected] with the message: INFO IBM-MAIN 

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to