Application Security

7/11/2018
04:45 PM
Dark Reading
Dark Reading
Products and Releases
50%
50%

Former DuPont Employee Pleads Guilty to Stealing Trade Secrets and Lying to the FBI

Took Trade Secrets and Proprietary Information When He Accepted a Job with a Competitor

Josh Harry Isler, age 55, from St. Ansgar, Iowa, pled guilty today in United States District Court in Cedar Rapids to one count of trade secret theft and one count of making a false statement or representation to the Federal Bureau of Investigation. ­ 

As part of his guilty plea, Isler admitted that during August 2013, while employed with DuPont, but after having accepted an offer of employment from a competitor, he stole trade secrets of DuPont.  In a plea agreement, Isler admitted that after he accepted employment with a competitor of DuPont in the ethanol fuel enzyme business, he transferred hundreds of DuPont’s electronic files to an external device.  Isler knew the files he downloaded contained proprietary information and trade secrets of DuPont.  Many of the files also related to DuPont customers who were also customers of the competitor or whose business the competitor was seeking.  Isler kept the files in his new job and also transferred some to his new employer.  Isler also admitted that when he was interviewed by the FBI in November 2013, he falsely denied he had downloaded files containing proprietary information.

Isler faces a maximum combined sentence of 15 years’ imprisonment, a fine of up to $500,000, and eight years of supervised release after any imprisonment.  Isler may also be ordered to pay restitution to DuPont.

Isler was released on bond.  Sentencing will be set at a later date.

The case is being prosecuted by Assistant United States Attorney Richard L. Murphy and was investigated by the Federal Bureau of Investigation. 

Court file information at https://ecf.iand.uscourts.gov/cgi-bin/login.pl

The case file number is 18-CR-2032-LRR.                  

Follow us on Twitter @USAO_NDIA.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
What We Talk About When We Talk About Risk
Jack Jones, Chairman, FAIR Institute,  7/11/2018
Ticketmaster Breach Part of Massive Payment Card Hacking Campaign
Jai Vijayan, Freelance writer,  7/10/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-14084
PUBLISHED: 2018-07-16
An issue was discovered in a smart contract implementation for MKCB, an Ethereum token. If the owner sets the value of sellPrice to a large number in setPrices() then the "amount * sellPrice" will cause an integer overflow in sell().
CVE-2018-14085
PUBLISHED: 2018-07-16
An issue was discovered in a smart contract implementation for UserWallet 0x0a7bca9FB7AfF26c6ED8029BB6f0F5D291587c42, an Ethereum token. First, suppose that the owner adds the evil contract address to his sweepers. The evil contract looks like this: contract Exploit { uint public start; function swe...
CVE-2018-14086
PUBLISHED: 2018-07-16
An issue was discovered in a smart contract implementation for SingaporeCoinOrigin (SCO), an Ethereum token. The contract has an integer overflow. If the owner sets the value of sellPrice to a large number in setPrices() then the "amount * sellPrice" will cause an integer overflow in sell(...
CVE-2018-14087
PUBLISHED: 2018-07-16
An issue was discovered in a smart contract implementation for EUC (EUC), an Ethereum token. The contract has an integer overflow. If the owner sets the value of buyPrice to a large number in setPrices() then the "msg.value * buyPrice" will cause an integer overflow in the fallback functio...
CVE-2018-14088
PUBLISHED: 2018-07-16
An issue was discovered in a smart contract implementation for STeX White List (STE(WL)), an Ethereum token. The contract has an integer overflow. If the owner sets the value of amount to a large number then the "amount * 1000000000000000" will cause an integer overflow in withdrawToFounde...