 Well, good morning. My name is Tony Perez. You can find me online under the handle of Perez box. I have a blog in which I write about business and security. I'm also one of the co-founders and CEO of security. We are a web-type security company and we specialize in providing post-compromise incident response services and prevention of hacks via cloud-based firewall solutions and intrusion prevention systems. In other words, we clean and protect websites. For some reason, this slide doesn't like that. I'll just jump. That last image, I actually wanted to talk about that because while it's not security related, we are actually a global company and one of our employees is out of Bosnia and that bridge represents the connection between East and West and his city. And so one of the things we always try to do when we're talking or even on our site is always try to bring different pieces of the culture of our company who we are because it's in our model. We're real people, real security. And he's just one of our people. So anyways, that's a different story but for some reason the mic and that slide don't like each other although there's no audio on that slide. It's just really weird. But that's okay. We're going to move on. This talk is really for all organizations. I don't plan to dive into the details of anything in terms of technical, any kind of configuration changes you should make at the application level, any kind of tool you should apply. But it's really kind of meant to provide you a foundation from which you can build on and go back and start asking yourself kind of questions like how am I accounting for security? What are the things that I'm looking for? What should I be looking for? What does today's landscape look like and what should I be accounting for? And maybe start having better conversations as an organization on how to approach security. So if you're a developer looking to figure out how to sanitize your inputs or sanitize your outputs, things like that, I won't get into that kind of detail or validate your inputs, but hopefully you'll find it interesting and insightful. In all my conversations, I kind of like to start by providing some statistics and I think I have found in a lot of the conversations that I have, statistics help us work from the same ground so we understand what we're working with. So as of last week we were dealing with about 1.1 billion websites on the web right now. 33% of them were being powered by some form of a CMS. 73% of that 33% were powered by these four CMSs, right? So Magento, Joomla, Drupal and WordPress. And let me preface that by saying I did not put that in any specific order. It was just icon. And the reason I bring that is it's already been brought to my attention. I know this is a Drupal event. It's just high-level conversation. Of that, Drupal specifically powers about 2.2 of our websites and about 4.9 of the CMS share. Now again, this is based on one source with W3Tech. I know there's a lot of other sources that I can mean using. That's just a source that I decided to use for this presentation. What's interesting about this is that this should hopefully provide us context in the fact that there are millions and millions of websites that were responsible for even in the Drupal ecosystem, right? And those have a larger impact on the internet as a whole. And I can't have a conversation about that without placing emphasis on the importance of migrating to Drupal 8 and the benefits of Drupal 8 specifically. I specifically lied Drupal 8 because it, for me, applies an ethos of security by default and a lot of the configuration changes that they've introduced in the latest version. Peter Wollin actually wrote a really great piece in which he highlighted a lot of the different elements you can expect in Drupal 8. So I would encourage everyone to either go to that link and read his article or kind of navigate through some of these changes to understand what the benefits of that platform will be for you. With that in mind, however, and I'll be releasing these two so if you didn't get a snapshot, that's completely okay. The challenge I find, however, as a security professional is that when I look at Drupal statistics around Drupal usage, only about 8% of the Drupal platforms out there have actually migrated to Drupal 8. And I think that that talks to a problem that we have in the security community in which we always try to tell folks, hey, update. Hey, why aren't you updating? Just update. How hard is it to update? The reality is it's really frickin' hard to update, right? If it was easy, we'd be doing it. And the fact is that there's so many elements that we have to account for in our update process. It's not just about updating Drupal. It's about updating all the API configuration or any systems we're integrating or the infrastructure itself, right? There's so many different things and downtime and affecting our availability just isn't one of those options, unfortunately, which is what talks to this. I mean, Drupal's been out for what? Drupal 8 for about a year with a lot of these changes and yet only 8% of the community's actually upgraded to the latest platform. That's a challenge. And it actually compliments a lot of the research that we've done. If you recall, we are a company that we do a lot of incident response services. In other words, we clean a lot of messed up websites, a lot of them being Drupal as well, right? 84% of the ones we clean are usually out of date running vulnerable versions of Drupal. That also lends itself to some of the challenges we've seen in the past. Yes. Out of date and running a vulnerable version. Does that answer your question? So the unfortunate thing of that is it puts us in very precarious situations, right? Most people here should be familiar with Panama Papers, right? In which there was a huge compromise of a lot of legal information, etc. It disclosed a lot of information about a lot of important people. The unfortunate thing about this compromise, while I personally feel that it was an internal attack, a lot of the news picked up on this idea that, oh, the external websites, which happened to be built on WordPress and on Drupal, were the point of entry, right? The attack vector that was abused by the attackers. While I'm not 100% on board with that, it forces us to look at the reality of what they were looking at and what they're reporting and that there is a possibility, right? The Drupal instance that was being run had itself 25 different vulnerabilities within the application. One of them itself being the Drupal get-in that we're all familiar with from 2014, the major SQL injection issue. So, of course, it's the easiest one for everyone to attack. WordPress had three vulnerabilities that they identified. So they said, hey, the probability that one of these were used as an attack vector into the, to perform lateral movement within the infrastructure was really high. Okay, there's a lot of other pieces to that, but it forces us as a community to look at this and say, okay, well, how do we account for this? And what it brings to my attention is that the idea of patch and vulnerability management is really, really hard. And for those that are unfamiliar with the terminology, patch and vulnerability management, I'm simply talking to the ability to update, right? It's more official terminology that we use in a security space. And ironically, exploitation of software vulnerabilities is actually one of the leading causes of today's compromises, regardless of what CMS you're running. I started doing a little bit more research and I found an interesting article by the North Bridge folks in which they started to analyze enterprise organizations and how they handle open source, because I said, there's got to be some correlation, although we work in the web ecosystem, there's got to be some correlation in how organizations manage open source as a whole, right? Not just open source CMS applications. And they found that about 33% of those companies were unable to identify, track, or remediate any of their open source technologies, right? 47% of them were unable to track the open source code that they're deploying within their infrastructure. 50% of them had no one accountable for identifying or remediating those vulnerabilities. Now, I would challenge everyone here to think how that applies to your organization. Whether you're a large organization or a small organization, I work with a lot of organizations myself, right? A lot of professional services, things like that, and it's the same question. Same issue I deal with a lot of security operations groups. I'm being forced to support some open source CMS that I never had to account for. My plate is already full. I have no more resources. I can't add anybody else to the team. How am I supposed to stay ahead of this technology? How am I supposed to apply patches to that when I can't even apply patches to my own infrastructure because of my change configuration process or the process to getting to that, right? It's something we need to think about. Perhaps one of the biggest reasons I can find out why these problems exist is I think there's just a fundamental lack of understanding of what security is. Those are some of the things I'm going to be talking about. In many conversations that I have, there's always this conversation around what is the real problem, right? How am I going to fix this problem as if all of a sudden security became an issue? Before today there was never an issue, right? It hasn't been around for 20, 30 years. What is this human element to it? And it's just, what can I buy right now and apply it and check that box without a true understanding of what that box is and what you're trying to accomplish with that box. What we have to remember is that security is a continuous process, right? It's actually always been made up of this since its inception around people, process and technology, right? I can't tell you the number of conversations I've had where it's, hey, I've deployed a firewall. Awesome. Who configured it? No, whoa. What do you mean I configured the firewall? I bought the firewall. I'm secure. You're like, no, no, no. There's a process to this, right? Yeah, you spend $100,000 on a firewall, but guess what? Now you need a people in place to configure that firewall. And when that firewall is configured, now you need people in place to continuously update that because guess what? Security is not static. It's continuously evolving and the attack is continually evolving, the threat landscape is continually evolving and so your technology has to continue to evolve. The technology itself isn't making you more secure. These three pieces put together that improve your overall security posture. We have to remember that we're deploying our applications regardless of what that application is, whether it's a basic brochure site or a complex site into a complex ecosystem. And this is really what the attack surface looks like. It's not just about the Drupal application or any of its neighboring applications. It's the environment in which it sits. It's in the environment in which your administrators are functioning and working with and accessing that environment. It's the servers themselves. It's the applications configured on that server. And then of course it's the infrastructure itself. Some of these things are not things that you yourself have to be concerned with. You might outsource some of these elements, but you have to be having that conversation. Okay, who's handling my infrastructure? Who's handling my servers? What are their processes in the event of a compromise? What are they doing for me for security and where does my responsibility start as a website owner? Because many organizations that I've talked about, well, the host was taking care of this. But in many instances they find usually after a compromise the host comes back and says that was never my responsibility. That was always your responsibility. I provided you the perimeter defense. The minute you applied that application and you made available to the world, you're responsible for how that application gets attacked. Those conversations traditionally don't happen with agencies and their customers or with their customers in general. The combination of these is what we call the security space, the security chain. And the concept of the security chain is that any element or any piece, any link within this chain is potential vulnerability. And so we're only as strong as our weakest link. We have to take that into consideration across the entire stack. The thing to understand as well is that within every aspect of the stack the chain goes deeper. So we can do a chain specifically just for the Drupal application. We could do a chain specifically just for the server environment and the applications within the server. This is just at a very high level. One of the things that I like to spend a lot of time and I'll spend a lot more time talking to is the TTPs or the tactics, techniques and procedures that an attacker takes. I find these personally very insightful because it helps us understand what we're dealing with and how attacks are evolving and the things that they're doing. To do this I'm specifically going to leverage a model that was developed by the Lockheed Martin. It's very similar to what you might have seen with Mandiant, the exploitation life cycle model. The fundamental difference with Lockheed Martin's model and Mandiant's model is that Lockheed Martin looks to illustrate the entire evolution of the intrusion and it's designed to help you align every phase of an attack with specific controls that we can implement as defenders or as website administrators. So when we look at it there's seven specific stages in which an attacker operates when they're attacking your website. And what I've done here is I've identified the exact definition that's defined by the Kyoche model and then I've said, okay, what's the application? Or I've tried to draw the correlation to us as website administrators or those working in the website ecosystem. So on the reconnaissance side, the study of public information about the target, the target's environment, software makes practices, software load up. They're scanning your site. Pretty basic. I go to your site, I scan it, I try to see, is he running Drupal, WordPress, Joomla? What's it running? Maybe I scan your IP. What's on this IP? What other applications exist on this? Maybe I scan the ports on your server. What ports exist? What's open? What can I potentially use an exploit to get into that environment? Very, very, in a lot of instances, passive scanning. So they're not designed to trigger any events. But it's the initial phase that we take as an attacker. The weaponization. Once I've identified how I want to get into that environment with vulnerabilities look like, which one do I want to exploit? And how do I weaponize that? Am I going to use metasploit to use some module against some vulnerability that I identified? Drupal Gettin has a metasploit module out there. We can use that to weaponize it and deliver it and attack your website. Which brings it into delivery. Once I've weaponized and I've understood how I'm going to penetrate your environment, I actually deliver it. And I actually try to penetrate. I then do the exploitation. I've delivered it. I then exploit the environment and I try what I'm going to do next. That gets into the installation phase. I go though and I configure whatever I want to do. In a lot of instances, what websites don't take into consideration even during a compromise is that as an attacker, not only do I want to abuse your resources, but I want to ensure that I maintain constant access to that environment. So you'll see things like configurations to access control. So maybe the addition of another user. Maybe the addition of a backdoor into the web server so that I can bypass any application. And the last piece will be the actions on objectives. What am I going to do to this website? Am I going to distribute malware? Am I going to add it to my botnet? Am I going to do some other nefarious app? So these are the different phases. What the Q chain describes is that this traditionally happens in a linear function, in a linear flow. So it goes from reconnaissance to weaponization, delivery, exploitation, installation, C2 and actions on objectives. There's a little truth to this, perhaps in the enterprise world. But when we work in the world of websites, I believe as well as my partner, that it's not as linear and that any phase can be attacked. But what we can do is every phase introduces a potential mitigation point. So by looking at every phase we can identify ways that we can implement controls to mitigate that specific phase. And the one thing to note here is for instance, look at Drupal Get It. Drupal Get It would be one of those kind of attacks where I wouldn't necessarily go through the reconnaissance and weaponization phase. I would jump right into phase three and four. I already know what the vulnerability is. I already have the ability to attack. And in many instances what we saw in our environment were attacks against our websites without any care at all what they were running. They were attacking Juma sites with Drupal Get It payload. They were tracking WordPress sites with the same Drupal with the same payload. And they didn't care if you had it or not they were just looking to see if it was successful. So when it comes to websites it presents an opportunity to skip around through these different phases. And so what you want to do is when you're looking at implementing controls with a better understanding of their TTPs you want to be able to see what controls can I implement. How do I know that someone's scanning? How do I know what vulnerabilities exist? It might do any kind of vulnerability scans. It might be aware of the vulnerabilities that are being disclosed. So we talk a lot about updates. But what does updates provide us? It provides us a way to patch known vulnerabilities. Awesome. How about the unknown vulnerabilities? Right? So a little something to think about. This actually takes me to another aspect that I like to talk about which is kind of the types of attacks that we're experiencing. If we're a large organization we can expect to see a lot of targeted attacks. I'm Sony. Panama Papers. It's in my interest to attack them and invest the energy to find information because it's going to be worthwhile. A lot of the websites that you're probably managing and running are not that worthwhile. I don't mean to be the bearer of bad news. They're just one of many. They're low-hanging fruit. And that goes into what I would consider the attacks of opportunity. In a lot of instances we see a lot of automation and of attacks of opportunity. It's just scanning. What exists on the web? What can I exploit? What can I abuse? They really don't care what it is. You can be distributing content on how to use the best cupcakes in the world. They don't care. They don't care about the content. It's just another delivery mechanism. And when you tie all these different delivery mechanisms together, they create a very, very large impact on the web. When we're talking specifically about what the attackers do in terms of what they can abuse, I divide that into three distinct domains. I look at external attacks, internal attacks, and what I would categorize to be reflective attacks. Now, reflective isn't necessarily the right term for that. It's a term that we just came up with because we didn't have the right term for it. And if you guys have a better one, please let me know. But when I look at external attacks, I'm looking at what are they looking to abuse? So they're looking to abuse your access control. How do I log in, brute force attacks, things like that? Of course, exploitation of software vulnerabilities. What vulnerabilities exist and what can I exploit? The number one issue and you see it on the OWASP top 10 as well is security misconfigurations. Many instances things get deployed. Things aren't configured correctly. A lot of dev configurations are pushed into production. There isn't a process for security and an attacker can abuse that. And then of course, the next big thing we're seeing right now and growing, and a lot of you have probably heard of it, maybe not, is the continuous attack against the availability of our site through things like distributed denial of service attacks, which are growing exponentially every single day. Internal attacks. This is perhaps the one area that isn't given a lot of thought and probably second only to reflective attacks. When I talk about internal attacks, what I'm talking about is the environment in which it sits is a house. And at any point within the house, it can be infected. So if you focus only on one door and you leave all the other doors open, it's a potential problem. And so we see a lot of instances where an agency will host an application for their customer, but use that same server for their development environment. Or they'll be responsible for deploying into the customer's environment, but have no visibility into that customer's web server. And so that web server will have another 10, 15 different sites. And so we'll see a compromise, and that compromise will be facilitated through a concept of cross-site contamination. In other words, lateral movement within that environment once the attacker is able to penetrate. When I talk about reflective attacks, this is another thing that we've been seeing grow over the years. Things like attacking the site, but attacking the site indirectly. So think about my ability to compromise your site without actually penetrating your defenses. What would be a simple way of doing that? Think about websites that leverage ads and embed ads within their sites. So things like malvertising. My ability to attack the ad network and embed my payload within the header of an image for an ad would allow me to attack your website without ever actually penetrating your defenses. Other third-party integrations. We've seen instances where you integrate the wrong module, and that's hijacked by another user and all of a sudden they're pushing something or attacking and hijacking your DNS. Something that a lot of website owners don't even think to monitor and look at. So that's another attack vector we're seeing. Actions on objectives. So we've gone through a number of different things, what they do, how they do it and then finally what do they want to do with our sites. I've had a couple conversations with individuals here at the event where it's like, well I have a little brochure site, doesn't really mean anything. They're not going to do anything with it. Well, it actually means a lot, right? And they can actually do a lot depending on the type of organization you are. So of course if we're an e-commerce site, we're looking at things like, okay data exfiltration. They want to take my credit card information. But maybe on my health site, maybe they want to take the PII information associated with my customers. But maybe it's none of that. Maybe I simply just want to distribute malware. The web is still the number one distribution mechanism for the desktop malware that we get on our devices. So when I talk to my mom, please don't click on links. My machine isn't working anymore. Ransomware is distributed through malware. And a lot of this is we've seen it get into networks because of that, which is a big issue for enterprises. How do we filter this kind of traffic? Then we've also seen, well, I don't want to abuse the site itself. Maybe I want to abuse the server resources. Maybe I want to add it to my botnet and use that to attack other sites and use that to obfuscate my location as an attacker. So with this all this information, my goal is that you hopefully have a better understanding of the threat landscape that we're all working with today. And from this, we can start looking, okay, how do we go about building a framework that is repeatable for either our individual sites or as an organization. And you can choose to scale that however you want. To do this, I'm going to leverage the framework for improving critical infrastructure for cyber security developed by NIST. It's a non-regulatory agency for the U.S. Department of Commerce. The reason I want to leverage this is because this was released in 2014 and I think it does a really, really good job of providing us a foundation to build on and it's on us to take that and evolve it to our respective domains. And it's very simple. It provides very simple common language that we can talk not only to the developers and integrators, but also to our customers and also an opportunity to talk to our superiors as well. Before I do that, when we talk about it, it's all built on the concept of risk, which is a critical piece of security. And so when it comes to risk, the basis of it is it's an ongoing process of identifying, assessing, and responding to risk, right? But it's an ongoing process. You don't just identify one risk and say I'm set. No. You continuously come back and revisit that risk and you continuously add to that as you address each one. I'll give you a little simple thought exercise. Let's assume I've built a complex client portal using open source technology Drupal. I have a stringent control process for pushing and updating things in production, including security updates. I have to go through some steps to get this done, okay? When I think of the potential risks, it might be that our vulnerability is being released and if that vulnerability is released, how am I going to get that into production in a timely manner? Take into consideration Drupal get-in. They said what? Seven, eight hours and I had an update to consider yourself compromised. A bit dire, but that was the reality you're working with. Many organizations would not be able to make a patch in that kind of time frame. So that's a very, very serious risk. And what were the impacts? Well, we just developed a client portal. The impacts would be that somebody would be able to get in and steal all my client's information. Would that be an acceptable risk as this organization? And I would encourage you to go through this exercise with every application you built and start introducing security earlier in the conversation. Too often, agencies will introduce security at the completion of the project versus at the commencement of the project. My whole thing is about expectation management. So hey, we're going to develop this awesome solution for you. It's going to be a great system. You're going to be able to do X, Y and Z. You'll be able to fly to Mars and then we're going to talk about security. What? Security. And they're like, okay, okay. You start kind of getting into their thought process. What I want you to take into consideration when talking about risk, however, it's about defining your scope, clearly defining your scope. You also have to recognize that risk will never be zero and it is a continuous process. You cannot address every risk. It's like I tell my guys, you can't eat a sandwich without chewing. So you have to take small bites, process it, and then move on to the next one. If you try to do everything at the same time, you will accomplish absolutely nothing. I can promise you that. You'll never get to a point where you secured everything. I want to also talk about goals and this is a really important thing. Goals help us define what it is we're trying to achieve and what you're trying to achieve is that oh, I'm going to deploy a cloud-based firewall. That is not your goal. That is an action you're taking to address a goal. So a goal might be I want to prevent anyone from stealing my customer data or I want to prevent people from using my website maliciously or I want to prevent my customers from being abused when they come to my website. These goals, well, you can drill into these and help define what you want to do to address each of these and then you move on. Okay, once I've accomplished these three goals and I feel comfortable with that and I've addressed the risks associated with them, move on to the next piece. With this, we can get into the core elements of the framework itself. It's divided into four core elements. Functions, which is the high level of things that we can easily communicate. These are the things you can go upward or you can talk to your customers, etc. Categories and subcategories divide into the specifics we do for the functions and the specifics we do for the categories and that will hopefully make sense a little bit here in a second. The references are simply how do you align each of your actions. For instance, maybe one of my... One of the subcategories I have is become compliant with whatever policy. Here's the link for PCI. Here's the link for FISMA. Here's the link for whatever EU regulations we have to comply with. Within those the five key functions that we want to focus on are the identification of problems, the protection of them, detection, response, and recover. These are the five main elements that we're going to work with when we're building this framework and that I encourage you to do it. And these are very, very high level but each of these help guide you what you need to do for each one. Identification. What do I have? The key to security is you have to understand what you're looking to secure and too often we don't know what we're looking to secure. We have no idea what assets we have. What configuration changes am I making? What technologies am I deploying? Detection. How am I going to understand if something does happen? Because we cannot be naive enough to think that whatever we implement will solve all problems. We've already addressed that. We know that security is very complex. So we want to know, okay, I've done everything I possibly can but if something goes to shit I'm going to know that it went to shit. Response. And if it does go to shit what am I going to do about it? Do I have a plan in place and what does that plan look like? Recovery. What after actions can we take from this? What are we going to learn from this process and then start the whole process again? When you build it this is kind of what it looks like. At a very high level, a nice little table and you can put in a nice little table and this can be big and in fact I was hoping to have a white paper that I can share with you in which I provide you a very rudimentary framework that you can take with you and just kind of take it out. I didn't get it done on time unfortunately but I will have that done here within the next couple weeks but in a very high level this is what it looks like. Let's dive into each one just to give you a little bit more context. When we go into the identification phase a category might be within that is asset inventory and management. What web properties do I have? I can't tell you the number of times I've worked with an organization and the first question I say is I would love to work with you. How many websites are we working with? Oh I have no idea. What does that mean? I just took over this responsibility I was just giving these websites or we're adding it to a spreadsheet as we get them. I said okay we'll do that. If you don't even have a basic understanding of the web properties you're responsible for how are you going to begin to secure that? How do you even expect to understand things like updates? How could I even sit here and tell you you should update when you don't even know what website you have? That's a big challenge. Where do you host an infrastructure? Where do you host everything? Oh I don't know. The customer has it all in different places. I don't know that's somebody else in the group. I don't really know what that belongs to me. Okay so you don't know what properties you have? You don't know what hosts you have? How can I begin having the conversation of modules and extensions? We can't even get to that point. Third party integrations and services. Access points. What keys do you have? How do you get to a spreadsheet? I'll be happy with that. You can't begin to secure your environment. The reason it's so critical is once you've identified the things that you need and you have you can start thinking through how am I going to protect these? How am I going to address the things that I've identified? And maybe one of the responses is I can't. I have no way to address this issue. But at least you know it's there how do you know if you were successful? How do you know it's not being abused? Are you being notified? Are you watching it? Are you looking for changes? Is somebody looking? And let me caveat that by saying you might have a monitoring component in place but if you have nobody being notified or nobody watching that then it's like having nothing in place. Let's think about that for a second. And I bring that up because I've had lots of conversations about monitoring this, this, this, this. Great, who looks at it? Well, about that. Let's focus on that piece now. This is just a simple way. Continuous monitoring, maybe some server level monitoring monitoring your access points. There should be nobody that knows your application better than yourself. In other words, what I mean by that if I'm sleeping at 2am in California but somebody in China is logging into my application that should be an alert of some kind. We should be able to build those rules and maybe that should not be allowed because I have nobody working in Shanghai. Okay? Integrity monitoring. A very, very simple thing to look at. Did the integrity of the baseline change? Did somebody modify one of my PHP files? Did somebody modify one of my articles? Those are strong, strong indicators that is a potential compromise requiring some form of action that would initiate our response protocol. But if we don't know what we do in those instances then we have no response protocol. Right? How many people have thought about what am I going to do if there's a compromise? In a lot of instances, the conversations I have is oh, I don't need to worry about that. The host will take care of it. Then they get compromised and talk to the host like whoa, we don't take care of that. That's on you. So nobody's had that conversation and we need to have that conversation. How many agencies have talked to their customers that this is what we're prepared to provide for you? I can tell you one thing. Your customers are expecting you to provide that service if you have a sustainment contract, whether you've agreed to it or not. And that will bring up another issue. So developing some form of incident response protocol or some process for what you're going to do. Okay, in the event of an incident, and an incident can be I get blacklisted by Google or I get blacklisted by one of these intelligence feeds out there that some obscure system is integrating. So you can respond to that. How are you going to provide a service to your organization or to your customers? And the last piece is the recovery. So once you've done this and you fix whatever needed to be fixed, what changes are you going to make? What discussions are going to be had internally to ensure that this doesn't get addressed, that this gets addressed in the future? When it's all said and done, this is what it looks like. A very, very basic breakdown of each of the groups. In the identification phase, you can have multiple categories. And so you start having a one-to-many relationship between identification and categories, and a many, many relationship between categories and subcategories. And the subcategories are designed to be specific actions you take to address the high-level categories. And each of these flow up into the functions. And so you can break this down and have conversations with whoever the audience is. Hey, this is how I address security. I do these different five phases. This is how I address each one. When you talk to your integrators and your developers, these are the things we're going to do moving forward, knowing that they all roll up into an overarching framework. The biggest issue I see is that a lot of organizations will place all their emphasis on two functions. Protection and detection. Yet they don't know what they're protecting. They have the most recent site that went up in life, but they don't have a list, they don't have identification of what's happening. And so I challenge everybody, think beyond the limitations of protection and detection, and look at a more comprehensive approach to addressing your security. And we have to remember that security is an all-encompassing process. It's a continuous system, right? You don't just start identification and stop. You should have a system in place, hey, on a quarterly basis, let's go through and identify our list. Do we still have these domains in our environment? Are we still managing these applications? Do they still do these things? Are the controls in place efficient or effective for the things that we're doing now, as an organization? Because just because you created a list two years ago doesn't mean that it's still applicable. Okay? If you're wondering why this all even matters, these are a couple of reasons, right? From a business standpoint, there's the impacts to your brand. If you're an agency and you're delivering services and you get compromised, regardless of what the reason was, you'll still get blamed for it. Oh, it's their development. They suck. They're not going to understand, oh, no, what you see what happened was it was this one module and there was this vulnerability and your change configuration process didn't allow us to update it in time, and what it really was was SQL injection and what happened is it got into the database and then when the database went to the server, their eyes are already rolling their back to their heads. They're like, I don't know what the hell this guy's talking about, right? There's the economic impacts, if you're the organization itself. Assume you're working on e-commerce site or assume you're working on an organization that requires their online presence to generate some form of revenue. When we have seen websites get blacklisted, they'll lose their revenue 90, 95% in the first 48 to 72 hours. Now, imagine the impacts of that going into a week. Two weeks, three weeks, right? It could be really, really impactful. And we cannot undervalue the impacts of this stress. I can't tell you the number of customers I've talked to where their livelihoods depend on their web properties and now they don't understand themselves what happened or how it happened and they're emotionally distraught about this. There's this, like, virtual vulnerability. Who would have done this to me? Why would they have done this to me? And then, of course, there's the new liability, right? More and more, we're seeing more new legislation talking to what the actions are by the various governments and local municipalities that do the businesses if they allow themselves to be used maliciously and attack their website owners. That's just on the business side, right? There's a technical element to it, right? There's the actual work of fixing the compromise or there's the actual work of identifying what the attacker did and the distress that you get from, is this all they did? There's always that, are they still watching me? Unless you're like us and we just assume we're always hacked, right? A lot of people don't operate that way. But there's a certain level of vulnerability that you go through where it'll take you a long time to recover from that. Well, did I get all the backdoors? Are they still in my sight? Do I know that they're really not watching me? Am I going to get hacked again in three months? Am I going to have to go through this whole process again? And then trying to figure that out on the level of effort. Of course, the impacts of Web site black, SCO impacts, things like that. But it's just things to consider. And then lastly, I can't have a talk without presenting you a number of tools available in the Drupal repository that you can configure and deploy and do a number of things that I was talking to. So here are some of the top modules that I've seen a lot of people talking about, a lot of people deploying, leveraging. Each of them are designed to function different aspects of stuff that we talked about and I would encourage you to check them out. Again, though, before you even get to this phase I would encourage you to go back and think about your goals from a security standpoint. Think about your risk and then get into the types of tools that you can deploy. The other thing I would encourage folks to look at are things like cloud-based solutions, right? Security is becoming more and more complex. It's evolving every single day and it's hard enough for organizations to keep up with their own development tasks, let alone the security responsibilities that they're being asked to account for. So there's a lot of cloud-based solutions out there available to help you and I would encourage you to leverage them. So with that I would open up to any questions and answers or questions and I'll try to provide answers. Please, please guys. One at a time. One at a time. I've got no answers, man. Oh, about Sakuri. So the question is I spoke about listing modules and things like that and inventory management. He was asking specifically what we do as an organization. I'm not really sure if we're allowed to get into that. I know they're very anti-pitching and stuff like that. So do you folks want to hear what we do and how we do it? Okay. So we are a cloud-based solution and we actually offer three distinct things. I oversimplify it when I talk about cleaning and protecting. One of those is we provide some form of inventory management where an organization is able to take all their web assets and load it into our environment and we will provide continuous scanning. We don't do vulnerability scanning. What we do is scanning and looking for indicators of what we consider indicators of compromise. Indicators of compromise is very similar to what we were discussing. Sometimes an attacker will penetrate your environment and they won't necessarily do anything malicious but they'll make a slight little change and that change would be an indicator of a compromise or maybe somebody flagged it as a potential issue. We would identify that as an indicator of compromise. So we're looking and then we're looking at changes, things like DNS, SSL any of those kind of externally facing indicators are things we're going to flag for. We look at, of course, our distribution we look at payloads on the server that's where our inventory comes into place. We won't drill into things like the modules you're leveraging things like that but it's more at a high level. What are all the domains you have? Because that's usually the first question we need to ask and by monitoring that we can get a good understanding of what's happening with the environment. Correct, that's another level we're going to layer down and we won't get into that. The second piece of that is of course the incident response so if someone's been compromised as a service we go in and we'll clean that up for you we'll identify the payloads etc and then the third piece is the actual protection we have a cloud-based WAF and IPS where we're looking to mitigate all external attacks at the edge so all via DNS we take your information we route it through our network and we strip out all malicious requests for firewall injections things like that would all get stopped at the edge denial of service attacks that sort of stuff so very high level but any other questions pertaining to this and yeah where I work everyone is getting crazy about local admin rights etc so this has been stripped and having less and less rights on a local machine it's sort of a secure which I personally find deadly because you don't really need any special rights but it starts encrypting your disk and documents and then the CEO actually have information which is going to be as a security company do you see more of these coming these days is it something that we have to really be careful about so the question is do I see a rise in ransomware right desktops or websites so there's two aspects to this we started to see a trend where attackers are trying to leverage ransomware on websites which is not as effective as its counterpart on desktops because you just apply a backup if you have one right if it's part of your framework and you have a plan for backups which sometimes doesn't happen but there is a rise in the distribution of desktop ransomware via the web so and that's been the last 12 months we've seen that continuously increase right there's a lot of organizations like mowerbytes is continuously writing a lot of research on the exploit kits being expanded upon by distributing ransomware to the endpoints and we are seeing that through the web we are seeing an interesting increase on ransomware specifically affecting websites but they're just not as effective does that answer your question okay so their concerns are not that far-fetched any other questions we are actually seeing an increase as well in denial of service attacks which is really interesting about the denial of service attacks is that unlike other attacks where the attacker is trying to abuse your resources or abuse your audience they're actually attacking the website owners themselves and they're saying you know what I could attack your audience but I could probably make a lot of money on you and so we've seen this rise of hey if you don't pay me these many bitcoins I'm going to denial service you and I'm going to take you offline or we've seen a lot of retaliation a classic example of this was last week with Brian Krebs I don't know who's familiar with Brian Krebs he was taken completely offline with a 615 gigabit per second denial service one of the biggest ones until OVH just came out with a release at 1.1 tetravites it's just getting bigger and bigger and the problem is getting interesting and I wrote an article on the impacts to website availability and I think it's something that a lot of organizations just aren't prepared for and there's different forms of denial service a lot of organizations are traditionally familiar with layers 3 and layer 4 which is really a matter of pipe whoever has the biggest pipe wins but when we start talking about layer 7 hey I see you laughing back there not how I intended it when we talk about layer 7 specifically the game changes because layer 7 we're talking about requests per second versus bits per second or packets per second we're talking about number of requests so 100 requests in a second in a lot of instances can take down a server and what they're doing there is instead of trying to abuse your infrastructure resources or trying to attack your infrastructure link they're attacking your application resources so 100 requests is 100 requests your server has to spin up a lot of organizations just aren't prepared for that and so that starts attacking the resources and the interesting thing is to do a layer 7 attack is a lot simpler than to do a layer 3 or layer 4 attack I don't need as many systems and a lot of resources I can get 100 servers or 100 boxes 100 websites, use them as a part of my botnet and each one sends out a request or sends out 10 requests immediately I'm overloading web servers I don't know why I said that but nobody was asking a question so I'm just imparting knowledge any other questions? was it useful guys? awesome I already stopped taking questions sorry go ahead I don't because that's actually not a service we offer I'm simply up here just sharing this things that I've seen things that are effective I do a lot of research I look at how other organizations have done that we haven't offered that as a professional service at all we're a product company but when I give up and give talks I try to give higher talks that I've seen that come from our experiences working with organizations when we're doing the incident response process and we're going through hey I want to see this documentation or hey help me understand what I'm working with they're missing all these pieces and so I've gone out and identified it in a way that hopefully people can adopt and so that's why I'm presenting it hopefully that one of you can apply it and then next year you tell me how amazing it was and how you applied it and it worked and I can use it as a use case so if you have questions, ping me I'd love to work through it with you but I don't have any examples unfortunately yes absolutely and for anybody anybody listening the last question there was have I seen anybody that's effectively applied a model like this and my response was no because I'm actually this first time I'm introducing the model to you guys I built it just for this yeah so the question was do we have any influence with any of the internet providers or the tier one providers essentially to more aggressively mitigate or respond to large attacks is that right perfect that's a really weird thing to claim right no tier one is going to allow you to say hey you know what you're a great guy you're a great company I'm going to let you log into my environment and manipulate my routers I've never seen that so whatever competitor you're looking at it says that amazing you should probably go with them usually what the way it works however is there are a number of exchanges that make up the backbone of the internet right and so as organizations we have an opportunity to embed with those exchanges you come to an agreement and through those exchanges it kind of reduces how hops work things like that it's a little bit more complicated than that I'm oversimplifying it no I cannot log into a tier one provider's environment and manipulate their switches or their routers in the event of a large scale attack I've never seen anybody do that what I have seen is as an organization we have the ability to work with them to mitigate an attack what can we do together can we make these configuration changes etc so yeah I don't know I think that answers your question we don't whoever can do that is amazing any other questions alright guys well thank you very much for having me