As Symantec recently learned, your intellectual property could be at risk from third parties with whom you do business.
Protecting intellectual property against insiders is tough enough when the insiders are a company's own employees. The problem becomes even more difficult when a third party--whether a vendor or customer--has access to confidential information.
Just ask Symantec. Last week, the company confirmed that a group of hackers had stolen the source code to two of the firm's older products--Endpoint Protection 11.0 and Antivirus 10.2--from a third party. The group of allegedly Indian hackers, using the name "The Lords of Dharmaraja," claimed that the leak came from the Indian government and planned to release the code to the public.
"Symantec's own network was not breached, but rather that of a third party entity," Symantec spokesman Cris Paden said in an e-mailed statement. "We are still gathering information on the details and are not in a position to provide specifics on the third party involved."
"Presently, we have no indication that the code disclosure impacts the functionality or security of Symantec's solutions," he said. "In 2010 alone, we distributed 10 million updates to our products in response to new cyber threats. If you extrapolate to four and five years, you can get an idea of how much our ... code has evolved over the following years."
Yet, a significant question for companies is why did the Indian government, if the code was indeed stolen from the government, keep the code so long, says Rob Rachwald, director of security strategy for Imperva.
Heightened concern that users could inadvertently expose or leak--or purposely steal--an organization's sensitive data has spurred debate over the proper technology and training to protect the crown jewels. An Insider Threat Reality Check, a special retrospective of recent news coverage, takes a look at how organizations are handling the threat--and what users are really up to. (Free registration required.)
Stack-based buffer overflow in ntpq and ntpdc of NTP version 4.2.8p11 allows an attacker to achieve code execution or escalate to higher privileges via a long string as the argument for an IPv4 or IPv6 command-line parameter. NOTE: It is unclear whether there are any common situations in which ntpq ...
The parse() method in the Email::Address module through 1.909 for Perl is vulnerable to Algorithmic complexity on specially prepared input, leading to Denial of Service. Prepared special input that caused this problem contained 30 form-field characters ("\f").
Multiple cross-site request forgery (CSRF) vulnerabilities in totemomail Encryption Gateway before 6.0.0_Build_371 allow remote attackers to hijack the authentication of users for requests that (1) change user settings, (2) send emails, or (3) change contact information by leveraging lack of an anti...
A flaw was found affecting the Linux kernel before version 4.17. By mmap()ing a FUSE-backed file onto a process's memory containing command line arguments (or environment strings), an attacker can cause utilities from psutils or procps (such as ps, w) or any other program which makes a read() call t...