Tag: websites

  • Defend Against Phishing Attacks with EV Certificates

    Defend Against Phishing Attacks with EV Certificates

    One of the most important elements of fishing is choosing the right lure or bait. The same is true when it comes to the malicious digital version—phishing. A phishing attack requires good bait to be effective. Organizations can defend against phishing attacks and help protect customers by using EV certificates to verify the authenticity of the website.

    Phishing Attack Targets

    Phishing attacks are designed to fool a victim into believing the phisher is a specific, trusted party for the purpose of stealing credentials, accessing sensitive data or propagating malware. The foundation of phishing depends on the ability to create a false identity that the target audience will believe is the real thing.

    The most common targets for phishing attacks are online businesses—specifically, online businesses where customers generally conduct financial transactions or share sensitive data. Businesses of all sizes from small “mom and pop” shops to large enterprises are viable targets for phishing. Businesses in pretty much every industry are potential targets for phishing attacks, but the most high-profile phishing attacks typically focus on banks, credit unions, investment websites, ecommerce retailers and other similar businesses.

    Creating a Credible Counterfeit

    Due to the way the web is designed and the nature of HTML code, it is trivially easy to counterfeit a website. A simple “screen scrape” is all that’s required most of the time. You can right-click and save most images, or just link to the original images and code from the site being spoofed.

    Voilà! The content inside the browser’s display window for a counterfeit phishing site can—and usually does—look identical to the content on the actual site. It actually helps maintain the façade of authenticity to leave legitimate links on the counterfeit site as well and only changing or redirecting a couple key elements.

    Avoiding Phishing with EV Certificates

    That’s where an EV certificate comes in handy. The attacker can scrape, download, stream or link to most—if not all—of the elements that are within the confines of the HTML window. However, there is no way for the attacker to re-create or spoof the green address bar of a website with an EV certificate. Because the EV certificate indicator is outside of the HTML window in the browser interface itself, it can’t be spoofed or counterfeited.

    Websites that have an EV certificate give users a clear and simple way to determine if the website is legitimate or a counterfeit. It’s a good idea for organizations to give customers the tools they need to recognize and avoid a phishing attack. In the absence of an EV certificate, people don’t have that same opportunity.

    Maximize the Value of the EV Certificate

    Aside from helping customers steer clear of spoofed sites and phishing attacks, a recent survey highlights the fact that people have more confidence and trust in websites that are validated with an EV certificate. To get the most value out of the investment in an EV certificate, though—and ensure that users benefit from it as well—you need to follow a few simple tips:

    • Use green address bars consistently on all customer-facing pages on the site.
    • For companies operating with multiple brand names, use the brand names on certificates that match the brands of those sites.
    • Proactively communicate to customers that your site has green address bars and what to look for (including images of what to expect in popular browsers)
      • Include this message on appropriate portions of the website.
      • Include this message in outbound communications such as newsletters and security bulletins.

    By communicating with customers what to expect when they visit your websites and what to look for to verify that the website is legitimate, and then universally using EV certificates that are consistent with the brand of the website for all public-facing sites, you can help customers recognize and avoid spoofed versions of your website(s).

    — Tony Bradley

  • Survey Finds EV Certificates Impact User Confidence, Revenue

    Survey Finds EV Certificates Impact User Confidence, Revenue

    Do consumers notice or care when a site is more secure? Is it worth the extra cost for a company to invest in the more strenuously verified Extended Validation (EV) certificate? devopsy.kinsta.cloud conducted a survey to explore these questions and determine what, if any, impact an EV certificate has on consumer behavior and spending. The results are significant.

    What is an EV certificate? The “Learning to Trust Your Browser” report explains, “The EV certificate was created to address the weaknesses in the traditional certificate process and provide greater confidence in the websites you connect to. EV stands for ‘extended validation’ and refers to the much more strenuous and exhaustive process used to comprehensively verify the identity of the company or individual requesting the certificate.”

    We showed side-by-side mockups of websites to survey participants. One with a standard SSL certificate, and a duplicate website with an EV certificate. One was a banking website in a desktop browser and the other was a retail website in a mobile browser. We asked a series of questions about how users feel about internet security in general, and which website they are more or less likely to perform various actions on.

    Here are some of the key findings we discovered from the survey results:

    • For every measured behavior, a website with an EV certificate shows an uplift in user trust.
    • Half of the respondents indicated that the green address bar of the EV certificate websites has a significant influence on their perception of the brand or company.
    • Almost 60 percent of survey participants are worried about being the victim of an online phishing scam.
    • Nearly two-thirds of those surveyed stated that they feel slightly or much safer doing business with a site that is verified with an EV certificate.
    • The presence of an EV certificate leads to a higher probability that a consumer will share sensitive information, or be willing to complete a transaction online.

    Consumers are worried about security and there are a variety of concerns that keep them up at night. Will their personal health information be stolen? Will their social media accounts get hacked? Will their banking and financial details be compromised? Will their identity or credit card information get pilfered?

    More than 8 out of 10 of the survey participants are worried about these issues, which is why 91 percent stated they want to business with companies that invest in best-of-breed security solutions, and 96.3 percent indicated that they want to do business with companies that protect their confidential information. Based on all of that feedback, it should come as no surprise that they also revealed a significant preference for websites with an EV certificate.

    “There are two axioms that drive businesses—perception is reality, and the customer is always right,” according to the survey. “The results of this survey illustrate that an investment in an EV certificate plays a significant role in influencing customer perception and fostering trust. The increased consumer confidence has a direct impact on revenue and improves the bottom line for companies that use an EV certificate.”

    Check out the full report to learn more about consumer perception and the value of an EV certificate. Click here to download Learning to Trust Your Browser.

    — Tony Bradley

  • From the Trenches: Zesty.io’s Google Cloud Migration

    From the Trenches: Zesty.io’s Google Cloud Migration

    Zesty.io recently migrated its sites to the Google Cloud Platform from Rackspace—a process the company believes will make it more agile while streamlining its operations. Zesty.io community manager Phil Ballew recently spoke with Chris Hiestand, Zesty.io’s DevOps leader, to discuss some of the reasons for the migration and get a feel for just what the new cloud system brings to the company.

    Ballew: So what exactly is Google Cloud, and how does that compare to Rackspace?

    Hiestand: Google Cloud Platform is similar to AWS, Rackspace or Azure; they manage infrastructure and services to host your applications and data on. With Zesty.io being SaaS, there are servers running the user’s website that we will manage, and these names are the companies that provide the infrastructure.

    Ballew: So what about Google Cloud made you choose that over Rackspace?

    Hiestand: The difference is that Rackspace has been around for a long time and has produced great business tools, but Google’s tools, which they have been using internally for a while and are now making publicly available, will fit the needs for Zesty.io as we scale out at a rapid pace. Some tech that Google created about 10 years ago is considered cutting-edge today.

    Ballew: What was the reason and initial appeal for moving from Rackspace to Google Cloud?

    Hiestand: Google’s infrastructure is a well-designed fit for containers using the Kubernetes project. Their architecture is designed to minimize operations work, saving labor. Using GCP, we can focus more on writing good software and less on the drudgery of making that software run. Google’s network is remarkable in every respect: good security, bandwidth within the data center, between data centers and out to the greater internet. And their compute nodes are set up in such a way that when they do maintenance, they can move our systems around and we don’t even know it. We stay running and focused while they maintain the hardware.

    Ballew: Kubernetes? What is that exactly?

    Hiestand: Kubernetes is a container orchestration tool based on Google technology that we use on GCP to help us automate and scale the deployment of our software and websites for the users. It helps us think about our applications first and operations a distant second. It also empowers Zesty.io engineers to own what’s running in ops.

    Ballew: What other technologies are you using?

    Hiestand: Kubernetes is built on container technology, so we also use Docker extensively in development.

    Ballew: What were some of the major obstacles that you ran into when migrating to Google Cloud?

    Hiestand: The technical parts are pretty straightforward. The hardest part is probably coordinating with customers. We are mitigating this by keeping Rackspace and Google Cloud in production at the same time, giving customers time to update their DNS records.

    DNS instructions can be found at: https://developer.zesty.io/docs/satellite-sites/launching-a-satellite-site

    Ballew: What are some of the benefits Zesty.io users will see from this switch?

    Hiestand: The most obvious benefit will be the faster page load speeds of Zesty.io-developed websites, including slightly faster application load times for Zesty.io developers. In the not-too-distant future, international load times will be very good, particularly for our enterprise customers. In addition, we are pushing a lot of new features to Zesty.io that will be on the Google Cloud version soon for people to try out. The rollout to GCP also improves our software engineer development velocity so we can get improvements delivered to our customers faster.

    Ballew: Even though Zesty.io users have not all been moved to Google Cloud, is there the option to move now if somebody wanted to, and if so, how can they do that?

    Hiestand: Sure! I would love to help out with that. They can send me an email at support@zesty.io. After we migrate their site, they can update their DNS to point to the new CNAME when they are ready, and customers won’t be able to update their Rackspace website anymore. They will also want to update their bookmarks because the administration URLs have changed, but for the time being, they will get automatically redirected to the new ones. We can help them with any questions they have. Eventually, we will be updating all websites for all users. If you do not update your CNAME, it will take a little extra time for your site to load because of additional network routing from Rackspace to GCP.

    About the Author / Phil Ballew

     

    philballewPhil Ballew is the Zesty.io community manager, working with developers and building the Zesty.io community through many unique outlets. Connect with him on LinkedIn.

     

  • DevOps Lessons from the Dyn Attack Fiasco

    DevOps Lessons from the Dyn Attack Fiasco

    Dyn’s DNS servers suffered a major DDoS attack last week, slowing a host of major websites. Does the drive for DevOps automation increase the risk of similar attacks? Maybe, but it doesn’t have to.

    As almost every geek knows by now, a DDoS attack on Oct. 21 overwhelmed Dyn’s DNS servers, and websites that depended on those servers slowed to a crawl. The attack was made possible because a large number of Internet of Things (IoT) devices were compromised using Mirai, a malware tool that breaks into devices using default access credentials.

    While it’s not yet clear exactly why so many IoT devices were configured with default login credentials, it’s likely that at least part of the reason included the following factors:

    • IoT devices are so numerous that securing them all is very difficult, especially when they are configured with weak security out of the box.
    • The need to give multiple users access to the devices encouraged installers and service providers to keep the default credentials in place. For example, if you have a smart thermostat that is installed by a contractor, managed by a utility company and owned by a homeowner, each of those parties could potentially need access to the device. Sticking with default login credentials is a lazy but effective means of providing it to all of them.

    In certain ways, the shift to DevOps makes challenges like these more common. Consider the following:

    • DevOps encourages the use of microservices. That means more services and logins to manage. It increases the risk that some services will not be secured properly because default login credentials will remain in place.
    • Under DevOps, the entire software delivery team is supposed to have access to all platforms and resources that are part of the delivery chain. That’s different from waterfall development, in which developers only had to be able to access developer tools; IT ops only needed to access management tools; and so on. The need for broader access could encourage teams to take the easy way out by using default logins—or even just sharing login information, which is risky even if the credentials are not the product defaults.

    A shorter way of saying this is that to increase agility, DevOps increases complexity. Greater complexity translates to more potential security risks.

    Conclusion

    The Dyn attack was not a DevOps problem, and none of the above means that securing a DevOps environment is not possible. It is, but it takes more work.

    Still, the Dyn outage is a reminder of just how badly things can go if developers and admins make mistakes such as relying on default login credentials. This challenge will become more difficult, not easier, as DevOps continues to reshape the way software is written and deployed.

    — Chris Tozzi