Blogs

    Publish
     
      • Keeping Your Code Signing Certificate on the “Straight and Narrow”

        Mar 18 2016, 12:43 PM

        by Quentin Liu 0

        A recent Symantec research report revealed that a China-based Advanced Threat group, dubbed Suckfly, has been targeting the private keys associated with code signing certificates to propagate malware over a period of two years.  This discovery added yet another validation point to a rising trend among cyber attackers to distribute malware disguised as legitimate files and applications.

        Why are cyber attackers targeting the private keys of code signing certificates? The problem lies in the dichotomy of the objective, and the governance in traditional code signing practices.

        Key objectives of code signing are to a) verify the integrity of the content and ensure it has not been tampered, and b) providing attribution and non-repudiation of the creator of the file or application. Code signing elevates the trust level for files and applications in providing assurances that content has not been altered, along with associating the content with an identity has been verified by a third party. Many software companies and industry groups mandate the use of code signing for these reasons.  

        From a practical application perspective, some browsers will protect their users by displaying warnings if the user attempts to download any unsigned applications. In other areas, some security applications mitigate risks by preventing users from downloading and/or executing files and applications that are unsigned, minimizing the executing of code from unknown or unauthorized publishers.  As such, we’ve observed that organizations with an elevated security stance and a high volume of in-house software or application development typically have embraced code signing from both a publishing perspective as well as risk reduction.

        With traditional code signing, the accountability and responsibility of safekeeping the private keys used in the signing is left with the publishing organization. Within these organizations, the security and management of the private keys are typically entrusted to the Development group as files and applications are mostly published by Applications or Software Developers. If the group is not trained on security best practices nor held accountable on the consequences of lost, stolen or misused keys, the larger organization face the risks of having malware signed with their private keys.

        There are some industry best practices that can help organizations prevent stolen or misused keys. These include:

        • Securing the private keys
          • HSMs or in a purpose-built secure environment
        • Tracking of private keys and signing events
          • Provide visibility on who signed what, and when
        • Managing the assignment and revocation of publishers
          • Ensure only authorized users have access to the private keys
        • Capability to audit
          • Drive accountability and forensic insights on code signing activities

        In addition to best practices, some organizations may value the increased security that derives from not having private keys dispersed on-site, but rather in a centralized, secure location with robust key management governance. As a provider of 65% of code signing certificates worldwide*, Symantec provides a next generation alternative to help address the gap on the lack of governance and other challenges in traditional code signing practices and addresses the risk of stolen private keys. Symantec Secure App Service, a comprehensive cloud-based code signing management solution, centralizes key management and tracking of code signing events, as well as user management. 

        Cybercriminals will continue to find ways to breach the security of organizations and steal important data. Strict adherence to industry best practices or leveraging solutions such as Symantec Secure App Service will help deter these efforts and allow code signing to deliver the trust that it was created for.

        *Source: International survey by rsEdge, 2014

        • Products
        • DigiCert SSL TLS Certificates
        • Products and Solutions
        • Symantec Website Security
      • The Challenges of Transitioning Non-Browser Applications to SHA-2

        Mar 01 2016, 8:00 PM

        by Dean Coclin 0

        Two weeks ago, Worldpay, a major international payment processor, approached Symantec and the CA/Browser Forum with an urgent situation.  A small but still meaningful portion of the payment terminals within their global network can only function using the SHA-1 hashing algorithm.

        SHA-1 is an older technology that has been shown to be increasingly vulnerable.  According to the current CA/Browser forum standards, starting Jan 1, 2016 Certificate Authorities are no longer allowed to issue new public SHA-1 certificates (although existing certificates can remain in use until they expire or until browsers and operating systems block them, currently planned for January 1, 2017 by several browsers). 

        While Worldpay made considerable efforts to identify all their servers and believed they had obtained all the required certificates last year, some were missed which service roughly 1% of their credit card terminals and ATM machines globally. Due to Worldpay’s large global footprint, that small percentage translates into a number of potentially impacted businesses and end consumers.   

        Following Worldpay’s request to the CA/Browser Forum, Symantec followed up with each of the major browsers directly.  After a public discussion on the Mozilla Dev Security Policy list, Mozilla proposed an approach that would enable Worldpay to get the required exception while minimizing the risk associated with additional SHA-1 certificate issuances.

        The long-standing concerns about continued use of SHA-1 were reiterated by many as were the practical issues posed by Worldpay. We took this issue very seriously, as we had to weigh the additional risk against the potential negative disruption to Worldpay’s global merchant network and consumers.  After ruling out other possible technical options, we concluded that the approach proposed by Mozilla was the best available option. We issued these exception certificates to Worldpay last week and we will continue to work with them on alternate solutions that will adhere to industry best practices for certificate security, compliance, and management. A key element in our decision to issue these exception certificates was that they will be used only with non-browser clients – allowing the browsers to proceed uninterrupted with their upcoming plans to disable SHA-1 support.

        Recognizing today’s complex technical interdependencies, several in the CA/Browser Forum raised the question of how to avoid this type of issue in the future. We are working with Worldpay and other customers to deploy alternate solutions, such as Symantec’s Private CA offering, that will ultimately separate the handling of encryption in credit card terminals, ATMs, cable boxes, and other non-browser clients from that in popular web browsers.

        Symantec fully understands and promotes the necessity for adherence to best practices for certificate security management. That said, we also understand that real-world implementation is sometimes more challenging than we might anticipate, and we need to work together to not only create the right incentives for 100% compliance, but also to handle these real-world cases with the right level of consideration and nuance. We believe by collaborating with Mozilla and others, we have found a short-term solution that will enable businesses around the globe to keep functioning while providing some additional time, clearly required, to allow for the technical migration to SHA-2.

        • Products
        • DigiCert Code Signing
        • Voice of the Customer
        • Symantec Website Security