PCI Compliance Protect Customers' Identities Too
•Download as PPTX, PDF•
0 likes•596 views
This document discusses the importance of website security and protecting online customers' personal information. It notes that 92% of websites lack adequate security protections. While SSL encryption is widely used, over half of implementations have issues. The document recommends practices like using SSL on all pages, secure cookies, and valid certificates to better safeguard data. Adopting an "always-on SSL" approach can boost customer confidence and online sales.
Recommended
Recommended
More Related Content
What's hot
What's hot (12)
Similar to PCI Compliance Protect Customers' Identities Too
Similar to PCI Compliance Protect Customers' Identities Too (20)
More from Symantec Website Security
More from Symantec Website Security (20)
Recently uploaded
Recently uploaded (20)
PCI Compliance Protect Customers' Identities Too
- 1. Does PCI Compliance Protect My On-line Customers’ Identities Too? Mike Smart Sr. Manager, Products and Solutions Symantec Website Security Solutions Website Security 2
- 2. A 3600 View on Website Security Strategy Strategy Evolving Web Use Evolving Web Threats Assurance of Persistent Protection Enterprise SSL Security
- 3. UK Mobile Web Usage Evolution 82% Of UK population use the Internet 58% Of European population use the Internet Website Security Source 2011 Tecmark Research 4
- 4. Evolving Usage Place of education -0.25% Hotspot (wi-fi) 17.3% 2011 Another person's home 3.1% 2010 2009 2008 Place of work (other than home) -0.4% Home 0.9% 0 20 40 60 80 100 Website Security Last 3 Months Usage - UK Office of National Statistics 2011 5
- 5. 18.1% Increase Evolving On-line sales from 2011. Internet Retail £489m per week 8.5% of all retail sales Excl. Auto fuel All Retail: 0.4% £5,724m per week Increase from 2011. Internet All Retail Website Security UK Office of National Statistics 2011 6
- 6. On-line Retail Growth Website Security http://www.retailresearch.org/onlineretailing.php 7
- 7. Personalising the Web Social-Personal Financial-Personal Website Security 8
- 8. A 3600 View on Website Security Strategy Strategy Evolving Web Use Evolving Web Threats Assurance of Persistent Protection Enterprise SSL Security
- 9. Are we doing enough to protect customers? 92% Of websites Lack adequate security Verisign Inc / Netcraft 2012 52% Of of websites have a poor implementation of SSL Trustworthy Internet 2012 Website Security 10
- 10. SSL Deployment Audits Website Security 11
- 11. A 3600 View on Website Security Strategy Strategy Evolving Web Use Evolving Web Threats Assurance of Persistent Protection Enterprise SSL Security
- 12. Website Security Threat Analysis Website 1 in 4 have 6,000 get 35.8% have 1 in 156 Get Black-Listed Comes CRITICAL Vulnerability Infected Online Vulnerability Per DAY 61% Compromised Sites are Legit 36% Growth in Blocked Web Attacks Source Symantec 2012 / Business Week 2012 13
- 13. ‘Always-On SSL’ Only 10% Sites are ‘Secure’ 190,000 sites - 2012 Scorecard – Based on SSL & Server Configuration Testing Recommendations • Use HTTPS on all pages • Use only secure cookies • Resolve and avoid mixed • Use valid SSL certificates content from trusted CA’s • Encrypt all identifying and • Patch, update, and harden private information systems
- 14. What about the Protection of Our customers? Learn more: go.symantec.com/always-on-ssl Enterprise SSL Security
- 15. Leading Browsers All Major Certificate Authorities Organization Validation Domain Validation Extended Validation Authentication of organization Stringent, industry- Encryption Proof of applicant’s standardized right to request cert authentication of Validation of domain for domain organization control Organization details Business-beneficial Padlock in browser in Certificate Info green address bar Issued in minutes Blue address bar in in browser browser Issued in 7-10 days Issued in 1-2 days
- 16. Mobile Browsers & SSL – iOS Safari 43% of shoppers will abandon cart if a browser warning message pops up Green EV bar increases confidence (60% of online shoppers) Source: Symantec & OTA 2012 17
- 17. Internet Trust Marks 86% of shoppers recognize the trustmark Website Security 18
- 18. Key Takeaways SSL & TLS Best Practices Private Key & Certificate Validation & Configuration Re-assess Application Performance Design Source: Qualys SSL Labs / Trustworthy Internet 19
- 19. Configuration • Just one certificate is normally not enough, more are needed to Valid Certificate Chain establish complete Chain of Trust. • Multiple Certificates may expire at different times. Use only Secure • At minimum SSL v3 & TLS v1.0 are ‘OK’ – Check Logs for impact! • TLS v1.1 & 1.2 are without known issues, but have limited browser Protocols /server support Use Only Secure • Force your servers to select the use of the strongest suite the Cipher Suites & Control browser can support. Which Ones are Used Mitigate Known • Patching, server software updates Problems • Keep an eye on the latest standards and advice Website Security 21
- 20. Application Design & implementation (HTTP) • If you don’t have SSL - get it; if you have it - turn it on! Always-On SSL • if you have it on – keep it on all the time! Secure Cookies • Mark all cookies as ‘secure’. No Mixed Content • Think about Java files, pictures, CSS files. • HTTP Strict Transport Security – the SSL ‘Safety-net’. Enable HSTS • In case you have config error, Its easy, limited browsers. Disable Caching of Sensitive • With the increase in ‘External IT’, be clear about what is Content sensitive and what is not. Understand & Acknowledge • 3rd party services downloaded from another server. 3rd Party Trust • Understand your risk. Website Security 23
- 21. Your Action List Discover your Risk Exposure: Audit your website security infrastructure Review Configuration and design for benchmarking against industry Make positive changes to design like turning on the ‘Always-On SSL’ switch to protect customer’s 60% identities and strengthen your brand Growth Consolidate your certificate issuing process and use more stringent standards to demonstrate best practice and increase customer confidence to drive online sales 25
- 22. Summary Drive More Protect Your Reduce Your Business To Customer Data Risk Exposure Your Site & and Their and Time to Increase Financial Records Compliance Revenues 27
- 23. Thank you! Mike_Smart@Symantec.com Copyright © 2011 Symantec Corporation. All rights reserved. Symantec and the Symantec Logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners. This document is provided for informational purposes only and is not intended as advertising. All warranties relating to the information in this document, either express or implied, are disclaimed to the maximum extent allowed by law. The information in this document is subject to change without notice. Website Security 28
Editor's Notes
- Website Security Series Workshop 1 – Does PCI compliance protect my on-line customers' identities too?With the adoption of SSL encryption for protecting on-line financial transactions at an all-time high, does this really mean that you customers' identities are also protected?In this session Mike Smart will review some of the changes that have happened to on-line businesses in terms of the types of customers and the devices they use to visit on-line storefronts.He will also outline some of the risks that websites and their visitors face as they browse and buy on these sites.During the workshop you will discover;The risks website visitors and owners face in today's modern threat landscapeHow to leverage existing PCI compliance investments to extend the protection of vulnerable website visitorsThe simple steps website owners can take to increase customer confidence and drive additional revenues and loyalty.
- Everyone in the security industry has a part to play in combating such security issues. Given our assets and expertise, we think about how the Trust Services business can help.There are 3 aspects: end-to-end protection of user experience on website, assurance of that persistent protection, and the protection on the website itself against malware, vulnerabilities
- Mashable Article on Mobile App vs. Mobile Websitehttp://mashable.com/2011/02/24/mobile-app-dev-cost/Mobile device Web usage from Tecmark August 2011: http://www.netmagazine.com/news/uk-sees-huge-mobile-web-traffic-growth-111340UK Internet Users stats June 2010 http://www.internetworldstats.com/eu/uk.htmEU stats March 2011: http://www.internetworldstats.com/stats4.htmCloud Adoption Stats (count 450 UK businesses) December 2011: http://www.cloudindustryforum.org/cloud-adoption-2011
- http://www.ons.gov.uk/ons/rel/rsi/retail-sales/april-2012/stb-april-2012.html#tab-Internet-Sales
- http://www.retailresearch.org/onlineretailing.phphttp://www.retailresearch.org/images/online_retail_share_2011.jpgOnline Retailing: Britain and Europe 2012E-commerce is one of the fastest growing markets in Europe. The statistics are problematic as state statistical research organisations tend to underestimate the size of the sector. Based on CRR research commissioned by Kelkoo, 2011 online sales in the UK were £50.34 billion (€59.4 billion) or 12.0% of UK retail trade. In 2008, online was equivalent to only 8.6% of retail sales.For Europe (including UK), the total market was worth £169,880 million (€200.52 bn) in 2011 (up from £143,720 million [€169.63 bn] last year). Online retailers in only three countries, UK, Germany and France accounted for 71% of European online sales. In 2008, online sales in Europe were £101,840 million (€117.84 bn).Online sales in Germany were £38.18 billion (€45.07 billion), 9.0% of retail sales (+13% over 2010). In France, where online retailers grew at one of the fastest rates in Europe, 2011 online sales were £32.75 billion (€38.66 billion) or 7.3% of retail sales (+24% over 2010).What's Happening in 2012?We are, as usual cautious in our UK forecast. As last year, we expect a 14.0% increase in UK online sales to reach £57.39 billion (€67.74 billion) in 2012. This means that the UK online will have 13.2% of retail sales (last year was 12.0%). Last year's forecast of 12.0% was spot on.In 2012, online sales in Europe are forecast by CRR to grow by 16.1% (compared to 18.7% last year) to a new total of £197.19 billion (€232.76 billion).We expect the rate of growth of online retailing in the UK and elsewhere in Europe to be slightly lower than 2011, reflecting the continued economic slowdown. But with European expected online retail growth of 16.1% this year, it is still a cracking pace. US Online SalesAs the country that taught us all how to do online sales and once had annual sales growth of more than 25%, growth online in the US has diminished (see Figure below). Online retail sales in the US have a market share somewhere around 9%. Taking into account the different sizes of Europe and the U.S. online trade shares are about the same in both regions.Forecast Growth in Online Sales 2012 Increase Online Sales 2011-122012 online share of all retail business UK 14.0% 13.2% Germany 13.0% 10.0% Switzerland 16.0% 9.9% Denmark 14.0% 9.1% Norway 17.0% 9.1% France 22.0% 8.7% Sweden 18.0% 8.0% N/B/L 14.0% 5.7% Spain 16.0% 4.1% Poland 24.0% 3.8% Italy 18.0% 1.6% Average Europe16.1%8.8%
- Websites are becoming more Social:Tracking users behaviorCollecting more personal dataSocial networks integrationTargeted advertisingThe Sony Breach highlighted that Regulated PCI data was well protected, but it was the social data that wasn’t..Web sites are collecting more and more Personal information;Finance-Personal & Social PersonalCookies are used to track userStandard uses for browser cookiesWebsite servers set cookies to help authenticate the user if the user logs in to a secure area of the website. Login information is stored in a cookie so the user can enter and leave the website without having to re-enter the same authentication information over and over.More informationSession Cookies are also used by the server to store information about user page activities so users can easily pick up where they left off on the server's pages. By default, web pages really don't have any 'memory'. Cookies tell the server what pages to show the user so the user doesn't have to remember or start navigating the site all over again. Cookies act as a sort of “bookmark” within the site. Similarly, cookies can store ordering information needed to make shopping carts work instead of forcing the user to remember all the items the user put in the shopping cart.Persistent or tracking Cookies are also employed to store user preferences. Many websites allow the user to customize how information is presented through site layouts or themes. These changes make the site easier to navigate and/or lets user leave a part of the user's “personality” at the site. For Information on session and persistent and tracking cookies, see here
- Everyone in the security industry has a part to play in combating such security issues. Given our assets and expertise, we think about how the Trust Services business can help.There are 3 aspects: end-to-end protection of user experience on website, assurance of that persistent protection, and the protection on the website itself against malware, vulnerabilities
- [1] Source: VeriSign Inc.’s Internet Profile Service (IPS) January 2012. The Internet Profile Service classifies resolving websites into various functional categories. Those results were then matched with SSL details from NetCraft data. Reporting and results are based on e-Commerce sites with .com or .net domain only, and do not include country code top-level domains (ccTLDs, such as .co.uk), or other gTLDs.
- Everyone in the security industry has a part to play in combating such security issues. Given our assets and expertise, we think about how the Trust Services business can help.There are 3 aspects: end-to-end protection of user experience on website, assurance of that persistent protection, and the protection on the website itself against malware, vulnerabilities
- 1) Web site comes on-line2) Web site has a vulnerability (35.8%)3) Web site has a critical Vulnerability (1 in 4)4) Hacker finds vulnerable website and uploads malware (1 in 156) – (8.2Bn URLs scanned)5) Website gets black listed or blocked by search engines / security tools;Google block 6,000 sites per day!http://mobile.businessweek.com/articles/2012-05-07/protect-your-companys-website-from-malware61% of malicious sites blocked by Symantec.cloud are legitimate sites that have been compromised!
- http://WWW.otaLLiance.org/neWs/reLeases/2012scorecard.htmL
- This is a quick summary of the different between
- Minimum standards for certificate authoritiesPotential restrictions on use of DV SSL & wildcard certificatesIntroduced minimum key strength (2048)& certificate lifetime validity.The industry has come together!Organisations keep asking us to work better together – here’s the validation!CA/B Forum – released the EV standard to propose best practices around cert issuanceShow the different types of certs and explain the weakness (i.e. phishing sites use DV)OTA – pushing Always-ON SSLExplain what this isBaseline Requirements 1.0 for managing publicly trusted certificatesStandardizing Vetting Rules for OV CertsEliminating long-life certs >39 monthsRequiring RA AuditsMinimum Standards for Certificate AuthoritiesInfrastructure OperationsApplication SecurityBreach ReportingEnforced through browsers' root-embedding program requirementsPotential Restrictions on Use of DV SSL CertsRestricted from use on ecommerce sites where authentication is criticalApproved for use for encryption onlyPotential restrictions on Wildcard certs
- https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.0.pdf
- Section 1 - Private Key & Certificate: - EV, TrustMarks!The quality of the protection provided by SSL relies on the private key, which lays down the foundation for the security, and the certificate, which communicates the identity of the server to its visitors. 1.1 Use 2048-bit private keys Aim to use 2048-bit private keys for all your servers. Keys of this length are secure and will stay secure for a very long time. Your existing 1024-bit keys can stay in place, but you should plan to upgrade them the next time the certificates are up for renewal, or within the next two years. 1.2 Protect private keys Treat your private keys as an important asset, restricting access to the smallest possible group of employees while still keeping the arrangements practical. Recommended policies include the following: • Password-protect encryption keys to prevent keys from being compromised when they are stored in backup systems. If there is a compromise, revoke old certificates and generate new keys to use with new certificates. Renew certificates every year—always with new private keys. 1.3 Ensure sufficient domain name coverage Ensure that your certificates cover all the names you wish to use with a site. For example, your main name is www.example.com, but you may also have www.example.netconfigured. Your goal is to avoid invalid certificate warnings, which will confuse your users and weaken their trust. Even when there is only one name, remember that you cannot control how your users arrive at the site or how others link to the site. In most cases, you should ensure that the certificate works with and without the www prefix (e.g., for both example.comand www.example.com). The rule of thumb is this: a secure web server should have a certificate that is valid for every DNS name configured to point to it. Wildcard certificates are generally best avoided. Although they are not any less secure from a strict technical point of view, the way in which they are typically handled (especially in larger organizations) makes them less secure in practice. 1.4 Obtain certificates from a reliable Certificate Authority Select a Certificate Authority (CA) that is reliable, that is, one that is serious about its certificate business and about security. Consider the following criteria while selecting your CA: Substantial market share: A CA that meets this criterion will not likely have all its certificates easily recalled, which was the case with some smaller ones in the past. Business focus: CAs whose activities constitute a substantial part of their business have everything to lose if something goes terribly wrong, and they will not neglect their certificate business by chasing potentially more lucrative opportunities elsewhere. Services offered: The CA should provide support for CRL and OCSP revocation as well as allow you to reissue your certificates online and as many times as necessary. Freedom of deployment: No certificate licensing limitations (i.e., you can deploy your certificates on as many servers as you like). Certificate management options: If you need a large number of certificates, choose a business with a good management user interface that enables you to manage all of your certificates as well as to delegate management to multiple user accounts. Technical support: Choose a business that will give you good support if you need it.
- Section 2 – Configuration:With correct SSL server configuration, you ensure that your credentials are properly presented to the site’s visitors, that only secure cryptographic primitives are used, and that all known weaknesses are mitigated. 2.1 Ensure that the certificate chain is valid In most deployments, the server certificate alone is insufficient; two or more certificates are needed to establish a complete chain of trust. A common problem is configuring the server certificate correctly but forgetting to include other required certificates. Further, although these other certificates are typically valid for longer periods of time, they too expire, and when they do, they invalidate the entire chain. An invalid certificate chain renders the actual server certificate invalid. In practice, this problem is sometimes difficult to diagnose because some browsers can reconstruct a complete chain, and some can’t. Testing with a tool that is designed to highlight configuration flaws is the only way to be sure. 2.2 Use only secure protocols There are five protocols in the SSL/TLS family: SSL v2, SSL v3, TLS v1.0, TLS v1.1, and TLS v1.2. Of these: SSL v2 is insecure and must not be used. SSL v3 and TLS v1.0 largely still hold up; we do not know of major security flaws when they are used for protocols other than HTTP. When used with HTTP, they can be made secure with careful configuration. TLS v1.1 and v1.2 are without known security issues. Unfortunately, many server and client platforms do not support these newer protocol versions. The best practice is to use TLS v1.0 as your main protocol (making sure the BEAST attack is mitigated in configuration, as explained in subsequent sections) and TLS v1.1 and v1.2 if they are supported by your server platform. That way, the clients that support newer protocols will select them, and those that don’t will fall back to TLS v1.0. You should always use the most recent versions of the protocol for security and the oldest (yet still secure) versions for interoperability with your customer base. 2.3 Use only secure cipher suites To communicate securely, you must first ascertain that you are communicating directly with the desired party (and not through someone else who will eavesdrop), as well as exchanging data securely. In SSL/ TLS, cipher sites are used to define how secure communication takes place. They are composed from varying building blocks with the idea of achieving security through diversity. If one of the building blocks is found to be weak or insecure, you can always rely on another building block that is supported. Your goal should be thus to use only suites that provide authentication and encryption of 128 bits or stronger. Everything else must be avoided: Anonymous Diffie-Hellman (ADH) suites do not provide authentication. NULL cipher suites provide no encryption. Export key exchange suites use authentication that can easily be broken. Suites with weak ciphers (typically of 40 and 56 bits) use encryption that can easily be broken. 2.4 Control cipher suite selection In SSL v3 and later versions, clients submit a list of cipher suites that they support, and servers choose one from the list to establish a secure communication channel. Not all servers do this well, however— some will select the first supported suite from the list. Having servers select the right cipher suite is critical for security (see Section 2.6). 2.5 Disable client-initiated renegotiation In SSL/TLS, renegotiation allows parties to stop exchanging data for a moment and to renegotiate how the communication is secured. There are some cases in which renegotiation needs to be initiated by the server, but there is no clear need for clients to do so. In addition, allowing clients to initiate renegotiation makes it easier for them to perform Denial of Service attacks. 2.6 Mitigate known problems Nothing is perfectly secure, and at any given time there may be issues with the security stack. It is good practice to keep an eye on what happens in the security world and to adapt to situations as necessary. At the very least, you should apply vendor patches as soon as they become available. At this time, two issues require your attention: Disable insecure renegotiation. In 2009, the renegotiation feature was found to be insecure. Most vendors have issued patches by now or, at the very least, provided workarounds for the problem. Prioritize RC4 to mitigate the BEAST attack. The 2011 BEAST attack is a practical attack based ona protocol problem that was discovered in 2004. Despite having been addressed in TLS v1.1 in 2006, the problem is still relevant because most clients and servers do not support newer protocol versions. Practical mitigation requires that your servers speak only RC4 when using TLS v1.0 or SSL v3.
- Section 3 – Performance: Security is our main focus in this guide, but we must also pay attention to performance: a secure service that does not satisfy performance criteria will no doubt be dropped. However, because SSL configuration does not usually have a significant overall performance impact, we are limiting the discussion in this section to the common configuration problems that result in serious performance degradation. 3.1 Do not use private keys that are longer than necessary The cryptographic handshake, which is used to establish secure connections, is an operation whose cost is highly influenced by private key size. Using a key that is too short is insecure, but using a key that is too long will result in too much security and result in slow operation. Currently, you can use 1024- and 2048-bit keys (with caveats, as explained in Section 1.1), but anything more than that is a waste of CPU power and will impair user experience. 3.2 Ensure that session resumption works Session resumption is a performance-optimization technique that makes it possible to save the results of costly cryptographic operations and to reuse them for a period of time. A disabled or nonfunctional session resumption mechanism may introduce a significant performance penalty. 3.3 Use persistent connections (HTTP) These days, most of the overhead of SSL comes not from the CPU-hungry cryptographic operations but from network latency. An SSL handshake is performed after the TCP handshake completes; it requires a further exchange of packets. To minimize the cost of latency, you enable HTTP persistence (keep-alives), allowing your users to submit many HTTP requests over a single TCP connection. 3.4 Enable caching of public resources (HTTP) When communicating over SSL, browsers assume that all traffic is sensitive. They will typically use the memory to cache certain resources, but once you close the browser, all the content may be lost. To get a performance boost and enable long-term caching of some resources, mark public resources (e.g., images) as public by attaching the Cache-Control: public response header to them.
- Always On SSLThe fact that encryption is optional is probably one of the biggest security problems today. We see the following problems: No SSL on sites that need it Sites that have SSL but that do not enforce it Sites that mix SSL and non-SSL content, sometimes even within the same page Sites with programming errors that subvert SSL Although many of these problems can be mitigated if you know exactly what you’re doing, at the end of the day the only way to reliably protect web site communication is to enforce encryption throughout— with no exceptions. Ensure that cookies are secured To be properly secure, a web site requires all its cookies to be marked as secure, too. Failure to secure cookies makes it possible for an active man-in-the-middle (MITM) attacker to tease some information out through clever tricks, even on web sites that are 100% encrypted. 4.3 Ensure that mixed content is not used Mixed-content pages are those that are transmitted over SSL but include resources (e.g., JavaScript files, images, CSS files) that are not transmitted over SSL. Such pages are not secure. An active MITM attacker can piggyback on a single unprotected JavaScript resource, for example, and hijack the entire user session. 4.4 Enable HTTP Strict Transport Security HTTP Strict Transport Security (HSTS) is an SSL safety net: technology designed to ensure that security remains intact even in the case of configuration problems and implementation errors. To activate HSTS protection, you set a single response header in your websites. After that, browsers that support HSTS (at this time, Chrome and Firefox) will respect your instructions. The goal of HSTS is simple: after activation, do not allow insecure communication with your website. It achieves this goal by automatically converting all plain-text links to secure ones. As a bonus, it will also disable click-through SSL certificate warnings. (SSL certificate warnings are an indicator of an activeMITM attack. Studies have shown that most users click through these warnings, so it is in your best interest to never allow them.) 4.5 Disable caching of sensitive content The goal of this recommendation is to ensure that sensitive content is communicated to only the intended parties and that it is treated as sensitive. Although proxies do not see encrypted traffic and cannot share content among users, the use of cloud-based application delivery platforms is increasing, which is why you need to be very careful when specifying what is public and what is not. 4.6 Ensure that there are no other vulnerabilities This item is a reminder that SSL does not equal security. SSL is designed to address only one aspect of security – confidentiality and integrity of the communication between you and your users—but there are many other threats that you need to deal with. In most cases, that means ensuring that your website does not have other weaknesses. 4.7 Understand and acknowledge third-party trust Web sites often use third-party services activated via JavaScript code downloaded from another server. A good example of such a service is Google Analytics, which is used on large parts of the Internet. Such inclusion of third-party code creates an implicit trust connection that effectively gives the other party full control over your web site. The third party may not be malicious, but large providers of such services are increasingly seen as targets. The reasoning is simple: if a large provider is compromised, the attacker is automatically given access to all the sites that depend on the service. If you follow the advice from Section 4.3, at least your third-party links will be encrypted. However, learn what services your sites use, and either remove them— and replace them with safer alternatives—or accept the risk of their continued use.
- Section 5 – Validation:With many configuration parameters available for tweaking, it is difficult to know in advance what impact certain changes will have. Further, changes are sometimes made accidentally; software upgrades can introduce changes silently. For that reason, we advise that you use a comprehensive SSL/TLS assessment tool initially to verify your configuration to ensure that you start out secure, and then periodically to ensure that you stay secure. For public web sites, the free online assessment tool on the SSL Labs web site (see the References section at the end of this guide) is hard to beat.
- Case Study Rose Versand GmbH – 2012 (One of the World’s largestSpeciality Bike shops ibased in Germany)20,000 parts for sale on-lineProcess 6,000 parcels per day45 – 60% GROWTH in Conversion Rates between browsers displaying green EV bar and those that do notFind a trusted CA!TOP Take-Away Tips:Move to Extended Validation CertificatesIncreases customer confidence and on-line click-throughIncreases conversion rates (Show German case study)Flick the ‘Always-On SSL’ switchProtects website visitors PIIStrengthens the brandMake use of value-added security servicesReduces costsIncreases visibilityUse the trustmark!Be visible about the level of security your site is protected withIncreases confidence
- Case Study Rose Versand GmbH – 2012 (One of the World’s largestSpeciality Bike shops ibased in Germany)20,000 parts for sale on-lineProcess 6,000 parcels per day45 – 60% GROWTH in Conversion Rates between browsers displaying green EV bar and those that do notFind a trusted CA!TOP Take-Away Tips:Move to Extended Validation CertificatesIncreases customer confidence and on-line click-throughIncreases conversion rates (Show German case study)Flick the ‘Always-On SSL’ switchProtects website visitors PIIStrengthens the brandMake use of value-added security servicesReduces costsIncreases visibilityUse the trustmark!Be visible about the level of security your site is protected withIncreases confidence
- Higher customer trustSeal, EV, and Always on SSL PRHigher Trust = more confident = more click-through= more conversionsUse German case study.CIC provides better visibility and control of cert infrastructure.Automation and centralisation reduces operational costs (which are typically 70% of the cost of owning a solution over it’s lifetime)Provides faster time to complaince (Or at least demonstrating complianceIncreased business continuity, less downtime etc.