DrupalCon 2017: Security for Emerging Threats

Editor's Notes

• #2: My name is Tony Perez. I go by perezbox online. I am the VP of Product Management in GoDaddy’s Security Business unit, and one of the Co-Founders of Sucuri.
• #3: Sucuri is a website security platform. It offers organizations a suite of security tools designed to help you focus on your business, while simultaneously addressing tomorrow’s security threats. The platform specifically provides: Post-hack incident response Proactive security monitoring Cloud-based mitigation of external attacks We’ve been working directly with organizations in their time of need - post-compromise - for over 7 years. I’ll be using that knowledge in today’s talk.
• #4: There are a lot of presentations, articles, books on the idea of securing our applications. It often revolves around the idea of employing a tool, a solution of some kind. Something very similar to what I just shared in regards to Sucuri. The problem with this is, is that as much as I would love my platform to be for everyone, it probably isn’t. Not because it’s not effective, but because most organizations are thinking of security the wrong way.
• #5: we have put so much faith in our technological abilities and have generally looked at the cybersecurity challenge as a technical problem to be solved (it’s not). We as a community have been traditionally very tool, configuration and solution based orientated. These tools have all been designed to look at the world from a very specific lens for the specific threat they are designed to stop.
• #6: As website administrators and as a community however we do ourselves a disservice both in the way we educate and share security knowledge. Security is a continuous process, and yet we treat it as a static state.
• #7: We fail to prioritize, and when you think about it, it’s something that I can understand. Website security is not a revenue generating function when compared to the likes of Marketing, Sales or Product functions. It does though have a direct impact and correlation to your brand reputation and revenue potential.
• #8: This is all compounded by the predicament we find ourselves in which the technology and its associate threats are growing at an exponentially faster rate than we’re able to keep up with.
• #9: We have cyber criminals that are both highly motivated, technology that exponentially improves their success rate and worse yet, we have a defined criminal supply chain where information can be shared, exchanged and sold amongst themselves. It’s the perfect trifecta of time, motivation and resources.
• #10: We must look at not introducing a new security approach, but rather improving our approach. The problem we face is not that no one has never experienced what we’re experiencing, but that we lack the skilled resources, knowledge and expertise to adequately communicate amongst ourselves what “security” really entails.
• #11: For instance, Security has never been about only “technology.” Yet, we see it as a solely technical problem. Instead it’s about People, Process and Technology. Without the people and processes, technology itself is dumb. If you buy the latest firewall, but don’t configure it, what good is the firewall? Some might laugh or scoff at the idea, but within our own platform about 40% of our own customers purchase and don’t configure the technology. They later suffer a compromise and their response is - “but I bought the technology”.
• #12: We have to work together as developers, integrators, administrators and a community to bridge that technical divide between what is required to have a site online and what our website owners have. This divide unfortunately can be vast depending on whom we’re working with.
• #13: In security, we have had this old metaphor where we relate security to an onion.. It’s designed to correlate the idea that there is no single solution approach, but instead the deployment of multiple complementary controls that make up a good security posture..
• #14: It’s better known as Defense in Depth and for most this concept should not be foreign and yet it’s rarely something we employ. To put it into context, one of the biggest mistakes I see with organizations is that they say Oh the tools I use employ Defense in Depth, or a vendor might say that as well.. But that’s a fundamental misunderstanding of the concept.. Organizations can employ a defense in depth approach in the development and management of their organizations, but defense in depth is an approach you have to employ. So for those that use Sucuri, we don’t give you defense in depth, we complement your defense in depth posture.
• #15: The roots of of defense in depth can be traced to the military as far back as 1295. Via this design, you can see how the architects of the castle employed multiple defensive “controls” throughout their design to help mitigate external attacks. From the moat to create separation from the exterior walls, to the additional interior walls, to the multiple watch towers (all with overlapping fields of view), while also restricting access to one point of entry.
• #16: When we take this same concept and apply to our world of web applications we extend it not only to look at the depth of the controls we employ, but include the breadth of our attack surface and various security domains. Too often though we stop short by focusing one very small part of the attack surface.. Or perhaps we only employ one very specific domain.. (e.g., Monitoring Only, Protection Only).
• #17: To help illustrate my point around people.. Let’s spend some time to understand the top 5 threats we’re faced with. A majority of the compromises we deal with stem from one of the following: An attacker exploits weak credentials abusing the access control mechanism; An attacker exploits a weakness in the code, a software vulnerability; An attacker exploits a poorly configured environment, lateral movement; An attacker exploits a third-party integration, malvertising; An attacker exploits the availability of your site; If we dive deeper into each of these, I think we’ll find some common denominators…
• #18: Now let’s pay special emphasis on the human factor..
• #20: Often when we speak to security we focus on all the other layers of the stack, while implicilty forgetting the most important – Layer 8 – the People Layer. Today I find it to be the most damaging vulnerability, one we rarely spend time talking about and one we have few solutions for. Let’s look at it in the context of the five threats we just spoke of.
• #21: Attackers exploit weak credentials, abuse your access control.. People are creatures of habit. People use the same credentials across all systems. People don’t update their passwords. People never think it’ll happen to them. People think of themselves as being unique.
• #22: An attacker exploits a weakness in code, a software vulnerability: People do not update. People are not capable of keeping up with all the attack vectors. People do not maintain or administer their web environments. People resources are limited.
• #23: An attacker exploits a poorly configured environment, lateral movement; People manage soup kitchen servers. People do not employ functional isolation. People do not leverage least privilege principles. People employ configurations that are most convenient for themselves.
• #24: An attacker exploits a third-party integration, malvertising; People rarely know what third-party integrations they are supporting. People are unclear if the integrations they have are authoritative.
• #25: An attacker exploits the availability of your site; People do not invest in redundancy and failover. People never believe it’ll happen to them.
• #26: Now let’s pay special emphasis on the human factor..
• #27: In addition to the People challenge, we must have a deeper appreciation for the three core domains of any security posture: Protection Detection Response In the web ecosystem specifically we have a tendency to place over emphasis on “Protection” at the cost of any other solutions. This approach however is short sighted.
• #29: As Defenders we must win every time, while attackers need only win once.
• #30: By design, the idea that we’ll always be right is highly impractical and irrational. Instead we must come to realization that it’s not a matter of “if” you’ll be compromised, but rather “when” you’ll be compromised. And the odds are that some of you in this room are already compromised.
• #31: Which brings up the question, if some of you are compromised. Why don’t you know? The fact is that while most spend an infinite amount of time investing on hardening and protective solutions, very few spend any time on solutions around Detection or Response solutions.
• #32: The traditional IT / Network Security is already making this realization… Gartner specifically reports the shift in larger enterprises that around Detection and Response and expect it to be over 60%.. ISACA provides a really nice illustration that shows what the shift looks like in big enterprise, and it’s something we should expect and plan for over time..
• #33: So what do we do with this information? So far, I’ve discussed three things that I believe to be adversely affecting us and making it difficult to properly secure ourselves: Knowledge Failure to employ basic security principles designed to help us People Failure to account for the biggest vulnerability - our people Investments Improper balance in our investments the security controls we do employ.
• #34: To help balance things, we must begin to employ a Secure by Default mindset. Instead of focusing on all the possible scenarios, working with an impossible environment. We need to focus on two things: Defining Our Scope Reducing Our Scope
• #35: A perfect illustration of how something like this works is to look at our Access Control.. We like to use a Blacklist approach because we believe it to be more convenient. We employ tools to help us throttle the incoming requests, in the worst case scenarios we actually spend time adding Deny rules to our application for the latest batch of bad IP’s. It’s like staying dry while standing in front of a broken fire hose. It’s practically impossible, you’re always behind. You’re playing catch up. Alternatively, we employ a whitelist approach. Instead of focusing on all the bad, we focus on the good. We restrict access to environments that we’ve identified to be good. We can do this via VPN’s, Proxy configurations, or dynamic with whitelist links that allow you to pass your latest IP to the application.
• #36: A perfect illustration of how something like this works is to look at our Access Control.. We like to use a Blacklist approach because we believe it to be more convenient. We employ tools to help us throttle the incoming requests, in the worst case scenarios we actually spend time adding Deny rules to our application for the latest batch of bad IP’s. It’s like staying dry while standing in front of a broken fire hose. It’s practically impossible, you’re always behind. You’re playing catch up. Alternatively, we employ a whitelist approach. Instead of focusing on all the bad, we focus on the good. We restrict access to environments that we’ve identified to be good. We can do this via VPN’s, Proxy configurations, or dynamic with whitelist links that allow you to pass your latest IP to the application.
• #37: Another example comes in the way we think about software vulnerabilities. We’re infamous for telling website administrators to update. This though is probably the most disingenuous recommendation Technically, relatively speaking, the idea of updating is simple, but the ability to update is very different. Ability to update my be hindered by your organization's change control process, lack of awareness around identified vulnerability disclosures, or their insecurities around the impacts of an update (like the application having a conflict and breaking). Instead, while updates are definitely a critical piece of the equation, they address only the known knowns. Drupalgeddon in 2014 is a perfect example, where it was assumed that if not patched within 8 hours the guidance was to assume you were already infected. To help address this and account for known knowns, as well as unknown unknowns, organizations will be looking for solutions that provide their organizations cloud-based approaches to virtually patching and hardening of their applications.
• #38: In each scenario I’ve helped tackle the three core issues we discussed, while improving our security posture and simultaneously positioning ourselves to better combat tomorrow’s threats. Knowledge Employing a secure by default approach depends on various principles. People The solutions we’ve implemented start to remove the people weakness out of the equation. Investments Starts to rebalance the focus and investments that move beyond today’s threats, and into tomorrow’s.
• #39: Security is complex, which is why you should never use checklist like approach. It’s not about doing x, y, and z.
• #42: Instead, approach it practically. If everything is important, than nothing is. As with most things, it comes down to the basics.
• #43: First, security is about risk management. Specifically, it’s about risk reduction, not risk elimination.
• #44: Risk management is an ongoing process of identifying, assessing and responding to risk. To achieve this, an organization must understand the likelihood of an event occurring and the impacts if it does.
• #45: There are three things to remember about Risk: We must clearly define scope Risk will never be zero Security is a continuous process
• #51: Once we’ve understood our risk and possible exposure, we move into our goals. We need to understand what we’re trying to achieve. Maybe after assessing our risk we realize we have three very distinct goals: We don’t want attackers to be able to intercept our customers sensitive information in transit We don’t want an attacker to exploit our vulnerabilities We don’t want our brands reputation to be affected by a blacklist We don’t want to have any down time If an attacker is successful they must not have the ability to view our customers data
• #52: This approach is a practical approach to security. Instead of focusing on every possible scenario, we focus on the ones that are most important to us as an organization. It’s not to say the others aren’t important, it’s that we can only focus on so many things. Once we have a good system in place to account for our initial goals (being that security is continuous) we revisit our approach and expand upon it.
• #53: Lastly, I believe that what we lack is an effective approach to managing our security. To account for this, I want to leverage a simplified version of the NIST security framework, adapted for our web environments
• #54: When you put it together, this is what the framework looks like and using the structure we just defined we can start filling in the table. 
• #58: To edit: Develop AN incident response report
• #59: To edit: add period after “findings”.
• #60: To edit: Develop AN incident response report The font sizes for subcategories vary.
• #61: Again – font size variations I’d make the Protect and Detect ones bigger than the others