• Hackers Playing Grinch Could Dampen Your Holiday Sales

        May 18 2016, 6:57 PM

        by Russell Roering 1

        hackers grinch thomas hawk flickr.jpg

        As the holiday shopping season descends upon retailers and shoppers, storm clouds of apprehension from recent data breaches continue to darken the perception of safety among some consumers. A recent study conducted by and reported on by Huffington Post found that 45% of gift-grabbing respondents would “definitely not” or “probably not” shop at major retailers that suffered data breaches this year. The study also noted that 48% of shoppers said they would use cash instead of debit or credit cards, due to the high number of recent data breaches.

        Given that retailers depend on holiday sales to meet their annual goals, losing nearly half of its holiday customer base either online or at a brick-and-mortar store could have devastating financial implications for these outlets. Make no mistake: Trust drives sales. And as the data above shows, once that trust is shaken, it can be difficult to rebuild.

        Double check the security of transactions

        Organizations need to focus on both continuing to shore up their defenses and their customers’ trust, as today’s vulnerability could be tomorrow’s casualty. During the holiday season, the temptation for hackers is at its highest. Below are a few steps your organization’s IT department should consider putting in place to ensure security this holiday season:

        • On-site security. Online retailers should help consumers feel safe right away when visiting their site.This can be done by using the Extended Validation (EV) SSL green address bar, Always On SSL (AOSSL) throughout the entire shopping experience, and posting the Norton Secured Seal at any areas where the consumer needs to make a decision (e.g. login, order page, payments page)
        • Secure data transfer. Various studies have shown that 56% of all data breaches could be stopped by having encryption protecting network data. Use network security solutions (even between internal corporate networks) such as Symantec Endpoint Protection to harden endpoints, encrypt data, and provide layered protection against malware.
        • Train employees to spot social engineering. Remember, many attacks happen due to “social engineering”: Manipulation of people into performing actions or divulging confidential information. Hackers being able to attack one employee’s computer can leave the remainder of the internal network at risk of exposing critical data or protection between individual parts of the corporate network is just as important.
        • Integrate with the company’s crisis communication plan. IT can help the overall crisis communications plan by developing “dark pages” on the corporate website. Dark pages should include pertinent contact information and communication channels which could be pushed live in the wake of a breach. Pages should also include frequently asked questions and placeholders for answers to quickly get facts out ahead of third-party articles, opinions from experts and a spike in brand conversation on social media channels.

        Respond promptly to any issues

        Because of this loss of trust, IT security staff of breached retailers should be especially vigilant during the holiday season; becoming deeply involved in helping the organization repair besmirched trust with customers to reinforce the assurance of safe shopping will be critical to this process.  If your organization happens to experience a breach during the holidays, or even during the rest of the year, here are a few steps IT can take to help to restore trust:

        • Create an online support forum on the corporate website which is easily located and visible to provide customers with official information regarding the breach your organization suffered, a way to report fraudulent activity (some states even require this), and a way to notify the organization directly if they suspect another breach has taken place. Respond to all serious inquiries and assume any could be legitimate.
        • Anticipate questions and lend expertise to help guide restorative messaging to customers. IT is uniquely positioned on the front lines of a breach, which is important at the moment of breach, but we become important again in offering customers assurance post-breach.
        • Spread the word. Provide communications both on the corporate website as well as on the company social media channels to explain how the company took steps to manage security. Also note that this messaging should be Legal- and CISO-approved.
        • Be mindful of new threats from scammers looking to take advantage of potential vulnerabilities in the wake of a breach. IT can aid the investigation, reporting and communicating with the public and board members about damaging content.
        • Learn from a breach. In the days and weeks after a breach, share website referral traffic stats with the security response team to help guide a post-breach communication and monitoring strategy for the future. For example, finding that a great number of users clicked links to your website from a single news outlet or social network.

        The holidays are by far the most critical time for retailers to be thinking about security, but it shouldn’t be the only time. Breaches can happen out of the blue; use your position in IT to help keep grinches at bay and keep your customer’s information—and their trust in your business—secure. Breached organizations should follow these guidelines year-round, disclosing breaches quickly and transparently, and keeping the communication focus on protecting users in the future.

        • Products
        • Symantec Security Insights Blog
        • Data Breach
        • Symantec Enterprise Security
        • Thought Leadership
        • SSL verification
        • Symantec Website Security
        • DigiCert Code Signing
        • Endpoint Protection
        • Trust Services
      • How does SSL work? What is an SSL handshake?

        Sep 15 2014, 10:24 AM

        by Robert Lin 0

        A special request was made today: "How does SSL work? What is an SSL handshake?"

        Here are some quick info.

        SSL/TLS are protocols used for encrypting information between two points. It is usually between server and client, but there are times when server to server and client to client encryption are needed. For the purpose of this blog, I will focus only on the negotiation between server and client.

        For SSL/TLS negotiation to take place, the system administrator must prepare the minimum of 2 files: Private Key and Certificate. When requesting from a Certificate Authority such as Symantec Trust Services, an additional file must be created. This file is called Certificate Signing Request, generated from the Private Key. The process for generating the files are dependent on the software that will be using the files for encryption.

        For a list of the server softwares Symantec has, have a look at: Symantec CSR Generation

        Note that although certifcates requested from Certificate Authorities such as Symantec are inherently trusted by most clients, additional certificates called Intermediate Certificate Authority Certificates and Certificate Authority Root Certificates may need to be installed on the server. This is again server software dependent. There is usually no need to install the Intermediate and Root CA files on the client applications or browsers.

        Once the files are ready and correctly installed, just start the SSL/TLS negotiation by using the secured protocol.  On browser applications it is usually

        Remember to use your secured website address. Above is just a sample address.

        That will start the SSL/TLS negotiation:

        Keys and Secrets during RSA SSL negotiation

        The following is a standard SSL handshake when RSA key exchange algorithm is used:

        1. Client Hello
          - Information that the server needs to communicate with the client using SSL.
          - Including SSL version number, cipher settings, session-specific data.
        2. Server Hello
          - Information that the client needs to communicate with the server using SSL.
          - Including SSL version number, cipher settings, session-specific data.
          - Including Server’s Certificate (Public Key)
        3. Authentication and Pre-Master Secret
          - Client authenticates the server certificate. (e.g. Common Name / Date / Issuer)
          - Client (depending on the cipher) creates the pre-master secret for the session,
          - Encrypts with the server's public key and sends the encrypted pre-master secret to the server.
        4. Decryption and Master Secret
          - Server uses its private key to decrypt the pre-master secret,
          - Both Server and Client perform steps to generate the master secret with the agreed cipher.
        5. Generate Session Keys
          - Both the client and the server use the master secret to generate the session keys,  which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session
        6. Encryption with Session Key
          - Both client and server exchange messages to inform that future messages will be encrypted.

        (Wikipedia: Transport Layer Security)

        Tools such as OpenSSL can be used check the SSL/TLS negotiations:

        OpenSSL s_client -connect -state -ssl3
        Loading 'screen' into random state - done
        SSL_connect:before/connect initialization
        SSL_connect:SSLv3 write client hello A
        SSL_connect:SSLv3 read server hello A
        depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5

        SSL_connect:SSLv3 read server certificate A
        SSL_connect:SSLv3 read server done A
        SSL_connect:SSLv3 write client key exchange A
        SSL_connect:SSLv3 write change cipher spec A
        SSL_connect:SSLv3 write finished A
        SSL_connect:SSLv3 flush data
        SSL_connect:SSLv3 read finished A
        Certificate chain
         0 s:/ Organization/serialNumber=2158113/C=US/postalCode=94043/ST=California/L=Mountain View/street=350 Ellis Street/O=Symantec Corporation/OU=Corp Mktg & Comms - Online Exp/

        There it is. SSL and SSL Negotiation summarized. Mission complete.

        Now! Do Not Forget To Back Up Your Private Key and Certificate in a Secure place in case of system issues!

        • Public Key Infrastructure (PKI)
        • DigiCert Code Signing
        • certificate
        • Security Community Blog
        • Products
        • SSL Negotiation
        • TLS
        • Symantec Enterprise Security
        • Thought Leadership
        • Symantec Website Security
        • SSL
        • private key
        • #CSR
        • Trust Services