 Thank you. Part of my job is to help webmasters create fast and secure websites. And actually, it's my very first work camp. And I'm really excited to be here. So, yeah, let's jump in. Today, we are going to look at two things. First, I'm going to talk about why website security is important and what common misconceptions exist about how and why websites are being attacked. And second, I will introduce six best practices that we think would help site owners to improve website security. And I hope we will still have time for Q&A. If there's one thing I would like to take away from this session, then it is this. Make website security priority by adopting the best practices. Let's start with an easy question. Why is making your site important? In order to answer it, let's look at some of the common misconceptions about how and why websites are being attacked. The first one is this. Security is not a developer's job. And you might think, as a developer, I'm interested in delighting users by creating a fast and reliable web experience. But what about applications or sites which are not secure and get compromised? Well, essentially, it will hurt your users and their trust. Therefore, as a developer, you should probably be thinking about security as well. The second misconception that we often encounter is how sites are actually being attacked. Site owners believe that their sites are being singled out and actively targeted by hackers, for example, sitting in a basement and guessing passwords. In reality, hackers try to exploit systemic vulnerabilities of CMS platforms, plugins, and third party applications. For example, outdated or unpatched versions. Important here is that it's not necessarily your business or even your site that becomes the target, but just a piece of software that runs on your site. The third one is related to the why sites are being attacked. Business owners think that, hey, if I don't store or process any personal data on my site, then it's very unlikely that my site gets targeted. Now, think of a site that belongs, for example, to an ice cream store, and it contains only basic information about ingredients or opening times or directions. However, it ranks really well on search, because it happens to be the most popular place in town. An attacker might be interested in exploiting this reputation of the site by monetizing the traffic to the site. So what can we conclude? Security should be an essential part of a great web experience. Second, a site is not necessarily the main target of an attack, and it's the technical signals rather than the business that matter. Think of it this way, a burglar works up and down the street and knocks on every door. And when the door opens, they try to understand what's inside the house. Before they enter the house, they don't even know if stuff that's in the house is valuable or not. In today's world, this work is done by computer programs, and your house might be the site. And if you don't lock it, you can see what happens if you don't lock it. In this example, I guess some of you heard of this case. It's a US-based company which manages personal data like tax IDs, emails, and other personal information for millions of US citizens. And ironically, it was hacked. And data of roughly 133 million users was exposed. Why do I show you this example? Well, it's even the best make mistakes. But now you might think, well, of course they get hacked, they manage valuable data. Here's the example that we see every day. The Japanese keyword hack targets sites with good reputation on search. The way it works is that new pages are being created with auto-generated Japanese text in randomly generated directories. And these pages are being monetized using updated links to sell fake merchandise and other products in search. And with this type of hack, what you would notice as a side owner is that somebody would try to add himself as a property owner in Search Console. And if you see a notification in Search Console, then the probability is very high that you have been hacked. You might wonder how do I get hacked, how do I actually get access to Search Console out of the online accounts? For example, for phishing, if you're not familiar with phishing, what is it? Phishing is a form of social engineering that tries to trick users to use it. Let's look at an example. Do you notice something odd? I'm not sure if everyone in the room can actually see this slide very well. Sorry? The rest of the question is in the manual. Checkport, yes, that's it. One of the things that can help you to identify a phishing page is actually by checking out the URL. And if it matches the actual page, you can see the section by checking out the URL. And if it matches what you're usually used to. But there are more things that you can actually take into account as a user to understand if a site is a phishing site or not. Sometimes you would also have low quality images of the logos or the brand inside a phishing page. Or you can check out the target URLs if you hover over links on this page, if they actually bring you to another Google site or not. So in a nutshell, a phishing page will pretend to be legitimate and ask you for personal information. In general, all sites with a login page can be used as a phishing page or can be affected by phishing. Now you might think, who would actually fall for that nowadays? These are the numbers. So the most believable phishing site trick almost half of the users. And actually, when hackers strike, they move very fast. Accounts are accessed within 30 minutes after being phished. So it's really difficult to actually make up for the vulnerability after you have been actually hacked. So after all, what can you do? What can you do to protect your website better? We talked about how and why websites are being hacked. Now let's look at some of the best practices that we think might help you to build safer websites. We identified six. It's safer-looking, keep systems up-to-date, HTTPS, site verification, search console, backups, and training. Now important to note here is that website security should not be treated as a checklist, meaning that you just have a list of five to 10 points that you just check off and assume that your site is secure. But rather like building blocks that change or evolve or even disappear over time. Now why this is the case? Well, because the technology changes and evolves over time. Passwords are a good example. We will look into that in a minute. And by the way, so the backbone analogy is not intended, but it looks really cool. Yeah, let's start with the safer login. Strong passwords are essential to protect online accounts. What you see here is actually the opposite of strong passwords. These are among the top 20 most used passwords. And can you guess from which year? 2017. And does anyone recognize his or her own passwords? I hope not. My favorite one is this one. So for developers and site owners, you can find good advice on how to set up and make your authentication process more robust from NIST. NIST stands for the National Institute of Standards and Technology, and is the leading organization that sets industry-wide standards on security and authentication. Here I would like to highlight two distinct recommendations from this. It's password limitations and password resets. You should think about three things when you create a login page or user accounts. The first one is you should forbid commonly used passwords, for example, that rely on dictionary words or sequential characters like we've seen in the previous slide. You should also avoid context-specific words. So if you're managing a WordPress site as an admin, you should avoid having WordPress in your password. You should also disallow password hints. And usually, password hints are based on some personal information. But in today's world with social media, you can guess or research many things that people actually use in knowledge-based questions, for example, what's your favorite car, or what's the name of your dog, or your birthplace, and so on and so on. And the last point is, yeah, you should limit the number of password attempts to prevent bots from actually running scripts and breaking, doing a brute force attack. The second recommendation is that password resets are not a must. The industry has discovered that every time you would, for example, force users to reset a password, the password strength would decrease. Why? Because with the increasing number of online accounts, it's really difficult to actually create and use unique passwords for each individual account. So users wouldn't necessarily tend to use shorter or simpler passwords to just be able to memorize them all. But even the best and strongest passwords are useless when they get phished. However, having strong passwords and following the most recent guidelines is actually not a bad thing. It's better than having a weak password or ignoring the most up-to-date advice. And this is where two-serverification comes in. Two-SV or two-serverification protects your account with something that you know, a password, and something that you have, a phone, a security. Has anyone heard or is using two-serverification already? Awesome, cool. If not, this is kind of a short description of it. So what two-SV does is it adds a second layer of authentication in addition to the password. And when it's enabled, the user starts the authentication process with the password, but it's then being asked to perform a second step. Now, how this second step could look like really depends on the preferences of the user. You can use SMS, you can use calls. There's an authenticator app provided by us, physical security keys, a second device, backup codes that probably most of you know from online banking in printed form, or verify devices. Let's look at the security key, for example. It offers the highest level of protection against phishing. The downsides are the cost. But you should think about potential cost or the impact of being hacked and cleaning up the hack, versus the price of those little things. If you don't want a physical device, oh yeah, by the way, so there's no wife I needed to use security keys. They technically work like a USB stick. And you can't combine it with mobile devices. And if you don't want a physical device, you can also use an application instead. The Google Authenticator app generates a random six digit number, and it works without an internet connection. It's easy to set up, and you can combine it with a lot of product and services that are not related to Google at all. It can be downloaded for free in the Play Store. So to summarize two certifications, it's an additional layer of verification and makes the authentication process more secure. It is effective against phishing. The best practice is enable it everywhere. So don't use it only for your Gmail account or, I don't know, for Amazon or Facebook account. If the platform you're using is offering it, just enable it. The second building block is updating your systems. Technically, it seems to be a trivial task, but in practice it's really hard to do. And I guess side owners, business owners, know exactly what I mean by developers, I think, as well. So what do we mean by systems? It's actually not limited to a CMS, but again, it's any type of software, plugins that target applications. Why is it so important to keep your systems up to date? Well, outdated software is like an off the shoelace. You might be able to walk, but it's just a matter of time until you trip and fall. The second thing is that we will usually tie or shoot before leaving the house. What I mean by that is that as a developer or a side owner, you should think early on about updates in the development process, meaning even before starting to design or develop an application or a site, you should already have the factor or the variable updates in mind. If you take a shortcut here, you can regret it in the future. This is an interesting graphing from Sukuri. I guess most of you will be familiar with Sukuri. You can see that at the point of attack or infection, most of the CMS systems were out of date, and Sukuri defines out of date by saying that the CMS platform was not on the latest security version or did not patch the CMS with available security updates when security was actually asked to engage and do the cleanup. It's worth noting, though, that WordPress did a tremendous job in decreasing this number from 2016. So in 2016, it was around 61%, and it dropped to 39%. What can you do as a developer or a side owner? Well, a lot, but focus on prevention. Cleaning up a hack is more time-consuming and painful than actually making a system secure in the first place. You can start by focusing on three things. Monitor website status, check server configuration, and pay attention to guidelines. Guidelines, like the one we offer under those URLs, you will find a lot of helpful resources under developers at Google.com slash web fundamental security, or support at Google.com webmasters. This is on the right. You can see an example from the recently published hack guides. Check it out under URLs. As we discussed earlier, a hacker would look for systemic vulnerabilities. If updates or patches are available, but you don't install them, they're kind of pointless. So the best way to keep up with the most recent updates is to enable automatic, to make them automatic. And a tip on the side, avoid applications that do not offer security options. When automatic updates are not available or broken, do it manually. This is an example where WordPress release 4.9.3 actually had an issue with other updates where the process actually didn't work. And if you are on 4.9.3 today, please upgrade to the most recent one. We just sent out a batch of notifications to WordPress webmasters through Search Console informing them about this. In summary, all systems should be patched and updated regularly. The best practices keep your code clean, if you do it already, fantastic. One of the things that I would like to highlight here is that if you stop using parts of the CMS or plugins or any other type of application, then remove them completely. Don't leave them on your server. The next building block is HTTPS. HTTPS is a mechanism that a lot of browsers have to securely connect to a website. HTTPS is the secure or encrypted version of HTTP. If you haven't implemented HTTPS or you need more talking points or convince your clients, think about HTTP versus HTTPS this way. HTTP would be like sending a postcard written in pencil. And information that you share on this postcard could be stolen, modified, and of course, read. Whereas HTTPS is like a sealed letter. It's hard to access and manipulate information. And if it gets compromised, then it's really hard to say a notice or to be a notice. From the user's perspective, things are going to change as well. From July 2018, Chrome will mark non-HTPS site as non-secure. And from September 2018, HTTPS will be treated as a default option. So there will be no label whatsoever for HTTPS sites. Why should you use HTTPS? Well, encryption, data integrity, and authentication. Data that is being shared online is encrypted, and it kept secure from these droppers. Data cannot be modified, as I mentioned earlier, or be injected with malicious software through the network without being detected. And it actually proves that your users communicate with the internet side. When you think about implementation, think about those four things. So first of all, ensure robo-security certificates. If you are running on a 1024-bit certificate right now, switch to the Stronger 1 2048 bit key. Use permanent redirects, like the 301 redirect, then help us, help Google to find your HTTPS pages. So don't block them in the robo-60 file. And please do not include a no-in-ext tax. If you're using a server that allows HTTPS, HTS, which stands for strict transport security, which means that if, for example, user types in the HTTP URL into a browser, this site will still come up in the HTTPS version. Or if you would look on Google Search for the HTTP version, we would still serve the HTTPS one. So enable it on your server. If your server doesn't offer this, then maybe look for a new one. HTTPS also enables new technologies, like geolocation. It's also improved performance, and you might actually see improvement in the search ranking. In summary, enable HTTPS on all sites. To best practice, well, there is just none. Just go for it. To do it, the next building block is site verification in Search Console. I assume most of you are familiar with Search Console? Yes. Who is not familiar with it? Awesome, cool. Search Console is a free and open tool that informs site owners about the status of the website. And it comes really handy when it comes to security, because it notifies you and informs you about the health of your site. On the left, you can see the navigation menu of the old Search Console, and on the right, you can see a snapshot of the new UI of the new Search Console. Before we get into why Search Console is so important, maybe some numbers. So in 2016, we discovered 32% of more hacked sites. And there are no indicators that this trend is actually going to change. 61% of all those webmasters who actually have the hack couldn't not be reached. But we know that once we actually notify webmaster of a security issue, then 84% of those are successfully cleaned up the hack. Meaning that communicating with a website awareness is really important in actually having an effective method of making the web more secure. And this is what exactly Search Console can offer. Under messages, manual actions, and security issues, webmaster will receive notifications and find relevant information about the site status. What we often see is that site owners that don't have a Search Console account, when they see this message in Search, they are simply overwhelmed and they don't know what to do or where to go. Site owners with a Search Console account would see this on the other side. So if a message appears in Search, that the site was hacked, this is what they see under the security issues section. We provide information about the type of issue or attack. We provide example URLs. And you also have a detailed description of the problem and how to clean it up, how to fix it. In summary, Search Console is a free and open tool that provides relevant information about the status of your site. And if you have multiple sites, then you can or should even verify all of those. That's the short one, have a backup. It's an important part of restoring your site and cleaning up the hack after it has been compromised. It helps to bring you up to the original content and the original state and the content of the site. It's kind of an insurance that helps you to not to lose users or users' trust. Again, it's a short one, very straightforward. It helps to restore and recover the content. And you should also think about an automated backup instead of a manual one. It saves time. And please be aware that once you use a backup, there might be still the vulnerability that was actually the reason for why your site was being compromised. So remove it as well or think about it. The elephant in the room, in a way, trainer employees, I know that probably as a developer, this point might not be that relevant. But if you work with clients, SMBs, that have a certain number of employees, then it's particularly important to actually be aware what can happen, what can go wrong if employees are not trained or are not aware of website security. Forced surveillance, offer regular and comprehensive trainings and resources, define clear rules and responsibilities for individual employees. And for example, how to install and use third party software, develop escalation processes. So if an incident occurs, then help your employees to report it and identify it. One of the things that we believe is also very effective, tool is actually educating your employees about browser warnings, like these ones. So while browsing the web, employees or in general users would see those, they should not be alarmed and trust them, instead of actually continuing the journey. The other thing is improve skills by following simple rules and principles. For example, as I mentioned, how to report suspicious behavior, how to do a backup, how to use social media, what to share or not to share, and how to handle sensitive data. In summary, you should encourage your employees to be part of the discussion about website security. What you should avoid is actually scaring them or blowing up risks or threats out of proportion. So we started with this question. Let's recap. What can you do to better protect your website? The first thing is, use two certifications to make your login safer. The second thing is, keep your systems up to date, no matter if it's a CMS, plugins, or any third party applications. Implement HTTPS everywhere, not only the login page but literally across the entire site. Verify the site and touch console in order to be able to receive notifications and instructions, explanations of when an attacker cures and how they can fix it. Have a backup in place just in case things go south and you will encounter an attack and need to fix it quickly. And the last one, train employees. Don't scare them. Help them to be part of the conversation. They're an essential part of your website security. If you want to learn more about it, again, these are three URLs that I would recommend. The first one is particularly interesting for developers. Second one contains all information that we provide to webmasters. And the third one is a platform that is being developed right now that helps you to learn and understand common attacks, like cross-site scripting, scale injection, and so on. Thank you very much.