Building a Security Framework for Websites
•Download as PPTX, PDF•
2 likes•288 views
We live in an age where the threats against our website are real, and their impacts have the potential to be devastating. As open-source CMS applications continue to become a staple in our infrastructure stack, organizations are faced with the challenges of accounting for this new attack vector. With limited resources and knowledge, organization need a streamlined approach to managing their web assets. This talk will provide a holistic security framework that organizations can adapt and deploy internally to better improve their security posture.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (9)
More from Sucuri
More from Sucuri (20)
Recently uploaded
Recently uploaded (12)
Building a Security Framework for Websites
- 1. Building a Security Framework for Your Websites #AskSucuri #DrupalCon
- 9. Drupal 8 brought about amazing changes in terms of security!! “Security by Default” Released November 19th, 2015 Source: Drupal.org
- 11. Drupal Websites Upgraded to Version 8.0 8% Source: Drupal.org
- 19. Security is also a continuous process, not a static state.
Editor's Notes
- Good morning, my name is Tony Perez, I go by perezbox online, and I am the Co-Founder / CEO of Sucuri. For those not familiar with Sucuri, we’re a website security company specializing in providing organization professional incident response services and hack prevention in the form of a cloud-based Website Application Firewall / Intrusion Prevention System..
- The cliff note version of that is that we clean and protect websites.. On a side note, we’re a globally distributed company in about 26 countries.. And this image here is of Mostar, a bridge united east and west in the home city of one of our employees – josko - who is also in this room.. This room was destroyed multiple times across multiple years, last being rebuilt after WWII. I share this simply to show you a side of our company that is at the core of what we do. Real People Real Security.
- Have no worries though, that’s not what this talk is about.. Its for organizations of all sizes though looking to better understand the security landscape. It one focus on any one granular aspect of security – like auto updates or updating and backups – instead it should provide a hollistic understanding of what security is and how to think about it. In the end, my goal is that you’ll have a strong enough understanding how to approach building your own internal security framework.
- I always like to sharing with my audience different statistics to help provide better context on why we should be having this conversation and how it applies to us all... … I do this because its important to understand the scale we’re working with and where we, and our web properties fit... As of last week, we were right at about 1.1 Billion active websites
- Of the 1.1 Billion, about 33% are powered by some form of CMS - open or closed.
- Dividing that further, 73% of that 33% are powered by four platforms - Drupal, WordPress, Magento and Joomla!
- When we look at Drupal specifically, it is used on about 2.2% of the total websites, or 4.9% of the CMS market. That’s millions of websites currently using Drupal alone… This means that the impacts our websites have on the greater online ecosystem is huge... The kicker is that whether it’s Drupal, WordPress or any other platform, security, both how we think and deploy it, have similar characteristics at its core. So as I progress through this talk it'll be less application specific, and more general security as a hole focused
- With that in mind, I would be remiss if I didn’t touch on the fact that Drupal 8 has been released, and has been out since 2015… my general feel is that a number of the changes they’ve made coincide with a “security by default” like ethos that I'm personally very fond of...
- Peter Wolan put together a great piece highlighting a number of the upgrades, pertaining to security that I encourage everyone to spend some time digging through. In addition, there have been more changes in the way integrated services are leveraged as such putting other constraints on us for the future...
- One of the most common lines you’ll hear from a security professional when it comes to security, especially in the open-source CMS world is the importance of updating! There is obviously no denying it’s value, but in many instances I believe it’s a bit ingenious. The reality is that upgrading is a lot harder than most are willing to realize or admit and the funny, maybe not so funny, thing is that even as security professionals we realize how hard it is. Just looking at Drupal, and the stats that the .org offers we can see that only 8% of the Drupal powered sites they track have been successful in upgrading to Drupal 8. This is a real problem and coincides with some of our own research...
- In which after analyzing our customers we found that in 84% of the Drupal sites we worked on they were running out of date, vulnerable, instances of Drupal...
- Additionally, when we look at real-world examples, Panama Papers for instance (hack from 2015), their client portal (powered by Drupal) and their external web property (powered by WordPress) were weakly, in my opinion, attributed to the organizations compromise. In the initial assessment, researchers found that the deployed WordPress instance had three potentially exploitable vulnerabilities, while Drupal had 25 (the worst being the core SQLi - Drupalgeddon, from 2014).
- This only confirms my thoughts on patch and vulnerability management through things like upgrades and updates are generally ineffective. But this frankly should not be news to most of us. Not because they don't work, but because they never get done. So the question for me becomes why, why is this the case.. What are the challenges contributing to this challenge… This led me to an interesting study by Northbridge in which they analyzed all of enterprise organizations and how they work with open-source technologies...
- They noticed that approximately 33% of companies had no process identifying, tracking or remediating known vulnerabilities..
- 47% of those same companies didn’t even know what open-source technologies they were responsible for tracking.
- And 50% of the companies had no one responsible for the open-source vulnerabilities. Think about that for a moment and try a line between that study and your own organizations. How many of you in this room, whether agency or consumer, really know or have a grasp on the technologies you’re deploying? How many of you have some that you can hold accountable for when it comes to security?
- Perhaps the biggest reason I can find as to why these problems exist is because of a fundamental lack of understanding of security. In most security conversations we try to hone in on the "real" problem as if it's new, and constantly look for the "quick fix" to the problem. There is this overemphasis on finding the latest tool to satisfy a check box, and less time trying to understand what the tool is meant to solve or more importantly how that aligns with your specific security objective (more on this later). Security is much more than a tool or configuration. It’s a mindset. It’s a process.
- Security is built on three core pillars - People Process Technology. Neither are meant to exist on their own, but they all work in unison. Deploying only the technology without have a process in place or the people to manage it is setting you up for failure.
- The applications we’re building and deploying are part of a complex ecosystem, complex environment As such, we have to remember that complex things break in complex ways…
- Take into consideration the deployment of a website (regardless of technology). This is an example of what that ecosystem might look like: Environment Application Server Infrastructure
- Each of these domains create what we call in the security world as the security chain. Meaning we’re only as strong as our weakest link. So when we’re thinking about security we have to think beyond just the application, and be sure to ask appropriate questions throughout the stack.
- One of the things I like to spend a lot of time on as a security professional are the TTPs employed by attackers.. This is helpful to me in a number of ways… For one it provides context, allowing us to detect “how” they operate rather than “what” they do.. Although, the “what” they do is very important as well..
- To do this - I want to leverage the Kill Chain model proposed by Lockheed Martin. Using this kill chain model we’re able to illustrate the phases of an intrusion, and map a relationship between how the attackers operate to the security controls we might work to implement. There is also a comparable model built and released by Mandiant, the exploitation life cycle, but it falls short in aligning the various phases with defenses controls and is based on post-compromise actions by defenders. The Kill chain model proposes that instead of waiting for the post-compromise, attention is applied earlier in the process so avoid a compromise.
- The kill chain is divided into 7 unique stages. Again, each designed to illustrate a different phase of the attack. Go over the definitions Go over the correlation with the websites
- This is the illustration of how the kill chain model works. Their are some flaws in the design of the model however. In the proposed model, the Kill Chain assumes, and expects, an attacker to progress through the chain in a linear fashion (successfully) to achieve their objective. Based on this, being able to identify and mitigate an attack earlier in the the attack sequence would mean successfully disrupting an attacker. This though is false, at least when we're talking to websites. The Kill Chain model is in fact an effective illustration tool, but the idea that an attacker always functions in an linear manner is unrealistic and not in line with today's reality. I would challenge everyone here to to digest this model and think to themselves how they account for every phase of the sequence. This simple thought exercise can help identify potential shortfalls, and balanced with your risk assessment, help you prepare for the future. Sample questions you can ask yourself today: What can an attacker see externally? Can they see what modules I’m running? Do I myself know what i’m running? Are there known vulnerabilities in any of them? Do I know who is logged in? Are they authorized to be logged in? As the integrity of any of pages or server files changed? Do I know why? Or by who?
- The idea however is solid, in that by understanding the phases, we can implement controls in an effort to mitigate an attack. The exact sequence they take varies.. Drupageddon is a perfect example.. In that instance, most attackers moved right into Phase 3 .. It wasn’t about knowing whether a site had the vulenrability as much as throwing everything at the wall to see what would stick.. Panama Papers however is an example of something that would have likely traversed through each phase… Which brings me to the point of the types of attacks...
- Additionally, when we’re talking about attacks against websites a very high percentage are automated and what we would consider to be attacks of opportunity. Relatively speaking, while targeted attacks do exist, they are rare. When it comes to today’s attacks, we’re predominantly dealing with attacks of opportunity in which attackers target low hanging fruit.. Scan all sites for Drupal 7 intsalls.. Once you find them, check if they’re exploitable via Drupalgeddon or some other known vulnerability…
- When I look at the vectors an attacker might abuse, I divide them into three distinct groups: External Attacks Internal Attacks Reflective Attacks External attacks are those we’re probably most familiar with. An attacker exploits a vulnerability remotely, think a SQLi / RCE type vulnerability. While an internal attack might refer to the concept of cross-site contamination in which an attacker is able to move laterally within your environment. Reflective attacks is not exactly the most appropriate name, but is mean to describe attacks that are able to abuse your website resources without compromising it. Think malvertising or abusing a third party integration like JQuery.
- Actions on objective refer to the things an attacker might want to do with your web property. The impacts of each will vary greatly on your organization and audience. The most common in people’s mind is the distribution of malware, using your website as a distribution mechanism. But attackers are smart and have found a number of uses for your websites, uses that are sometimes difficult to detect and many instances have greater impacts. They range from leveraging your infrastructure resources malicious to attack other properties (think DDoS) to using it in Spear Phishing campaigns against organizations around the world.
- All this background hopefully helps you conceptualize the threat landscape we're working with today. Now let's talk about building a framework for repeatable security process for our websites. Note: This framework is meant to be a conceptual guide from which we can all build on, and not meant to be the most comprehensive solution.
- The foundation of the framework comes from the “Framework for Improving Critical Infrastructure CyberSecurity” prepared by NIST, a nonregulatory agency of the US Department of Commerce.
- The basis of the framework, along with many aspects of security is Risk.. Specifically Risk Management.. 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.
- For example: Assume I have built a complex client portal using open-source technology like Drupal. I have a stringent change control process for pushing and updating things in production (including security updates). A potential risk might be the release of a vulnerability that I’m unable to patch in a timely manner. The likelihood of this event coming to fruition is high based on the state of today’s online threats and the impacts could be devastating if a bad actor was able to gain access to sensitive customer data. A classic example of this use case can be seen with Drupalgeddon in 2014 Every organization is responsible for identifying and aligning the risk with criticality within their own organization business objectives. In short, it’s on each organization to build and identify their own risk tolerance. This can be as high or as low as you want to make it and there are a number of documents available to help you in the process.
- The thing with risk however is it can get out of control very fast. We have to be sure to: Clearly defining scope Recognize that risk will never be zero and Understand that it is a continuous process Understand that clearly identifying your risk tolerance will help you prioritize your security activities. You can’t do everything, and in many cases it’s unattainable and / or unsustainable.
- Additionally we have to spend a few minutes talking about Goals… As an organization what are you looking to achieve? Your goals will help dictate the paths you take and also help prioritize... What are your goals with security? What are we looking to do?
- Here are some sample goals you might have as an organization
- Maybe you’re a commerce site and one of your main goals is to make sure your customer data isn’t stolen.
- Maybe we’re a media company and millions of users come to our site and we can’t break the trust with these users by distributing malicious content. So an overarching goal is that our website isn’t used to malicious distribute content.
- Maybe our main goal is to make sure that our audience is never malicious abused in any way.
- Whatever they are, they too are a continuous process and must be expanded upon. As you move down the list, you don’t forget about them, but instead they become part of your sustainment process while you expand the list with new goals to address. By breaking the process into small manageable pieces you’re able to make better progress to improve your overall security posture.
- The framework NIST proposes, and the one I think we can leverage is divided into five functions, categories, subcategories and informative references. The benefits of the framework are that it offers: A way to describe your existing security posture; Identify and priority opportunities for improvement; Provides a common taxonomy for all organizations; Provides a communication medium to talk about security risks;
- The Framework core is comprised of five concurrent and continuous functions: Identify Protect Detect Respond Recover These functions are then divided into key Categories, subcategories and references as appropriate. The framework is not designed to facilitate a checklist mindset, but is built to help priorities security activities.
- 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.
- If thinking that this doesn’t apply to you, or that you’re too small to think about this I’d highly encourage you to reconsider. Compromises happen to organizations of all sizes and the impacts are real. I categorize these into two distinct groups: Business Brand Economic Emotional Liability Technical Blacklisting SEO Impacts Visitor Compromise Network Tunneling
- Ofcourse, being this is a Drupal event I can’t leave without providing you some recommendations on modules available to help you work towards a number of the things we discussed in this presentation.
- I would ofcourse encourage everyone to start thinking beyond application level security controls and start spending some energy looking at cloud-based technologies to complement their security.
- With that, I’ll open it up for questions from the audience if there are any.