Tony Perez On Security, Business, And Life
Security is in a constant evolving state and keeping up with the various changes can be heard. As my journey continues in the security industry, I will share thoughts and opinions based on personal experiences. Thoughts are mostly around website security, sprinkled with general security concepts as well, but all tailored to the everyday enduser.
The last few posts have been about deploying and configuring OSSEC as an important tool in your security suite. In this article I will provide you a script I wrote to help you quickly deploy OSSEC.
This script assumes you are deploying on a Linux distribution (e.g., Fedora, Ubuntu, CentOS, or Debian). It will force you to choose a distribution OS before it runs, this ensures it installs the appropriate dependencies based on the distribution type.
The previous OSSEC articles went through through the process of installing OSSEC and deploying a distributed architecture. This article will focus on configuring OSSEC to make better sense of WordPress activity.
WordPress is a powerful open-source Content Management System (CMS). Its biggest security weakness has always been its biggest blessing – its extensibility (e.g., plugin, themes, etc…). The years at Sucuri have taught me that post-compromise there is nothing more important than have good logs. They are the key to understanding what happened. They are also the key to identifying a bad actors intent before their actions materialize into something nefarious.
Fun fact: The premise of the Sucuri Security plugin was almost exclusively for this visibility. Over the years we added more features to accommodate a more robust application security toolset, but that was always a secondary objective. In fact, the premise of the Sucuri plugin was actually built based on the lessons Daniel learned with OSSEC.
This article assumes you already have OSSEC deployed. If you need a refresher, refer to the Part I of OSSEC for website security, written March 2013.
OSSEC is popular open-source Host Intrusion Detection System (HIDS). It was founded by Daniel Cid, and currently maintained by a very large community of security professionals. Please note that I don’t my installations off the official repo, instead I run directly off Daniel’s repo (instructions in the last post).
In the following series I’m going to share the foundational elements of my OSSEC deployments. We’ll start by placing emphasis on the importance of deploying a distributed architecture in this article, making use of the Agent / Manager options. In future articles you can expect insights into the best way to configure for CMS applications like WordPress, tuning the engine to make use of the alerts, and notifications.
If you have questions, don’t hesitate to ask.
It’s been a long time since I have had to enable 2FA on Twitter and found the process completely infuriating. Twitter’s 2FA configuration uses SMS as the default option, this is no longer advised by NIST.
We don’t have to look far to understand why; in the TTP’s leveraged to hijack a customers domain portfolio the weakest link was the attackers ability to hijack a users SIM card (i.e., which would lead to SMS hijacking).
It is recommended you leverage Time-based One-Time Password applications (e.g., Authy, Google Authenticator) for your 2FA needs. Unfortunately, doing this on the Twitter application requires multiple steps. This guide will walk you through the process.
A few months back I was working with a customer that was having the worst day of their lives. Attackers had taken full control of their most critical digital asset – their domains and the domains of their customers.
The organization affected was an agency. They built and managed sites for their customers and in a relatively short period they lost access to their site and their emails. In this article I’ll share what happened, and offer tips that would have made things a lot harder for the attackers to hijack their domains.
If you’re reading this article you’ve interacted with DNS. In fact, you’d be hard pressed to spend any time online and not interact with DNS.
Many of us spend very little time thinking about it. By design, it’s a “set-it and forget-it” tool that is often set up on our behalf (e.g., our home network, local ISP, office network). Ironically, it’s a critical piece of our security landscape.
This post will explain what DNS is and highlight some of it’s key security considerations.
The need to use HTTPS on your website has been spearheaded by Google for years (since 2014), and in 2018 we saw massive improvements as more of the web became encrypted by default. Google now reports that 94% of its traffic on the web is now encrypted.
What exactly does HTTPS mean though? And how does that relate to SSL or TLS? These are the more common questions I get when working with customers and in this article I hope to break it down for the every day website owner.
On September 28th, 2018, Facebook announced it’s biggest data breach to date. They estimated 50 million accounts were affected at the time of the disclosure. Subsequent to the disclosure, security professionals from all verticals took to the interwebs to provide what most would consider sensible advise:
Neither, however, would offer users an appropriate response to this type of data breach. This knee jerk reaction speaks to a bigger problem we have in our community of misinformation, often as a result of our own lack of understanding of a problem.
As a parent, and a technologist, I struggle with creating a safe online experience at home. I’m constantly playing with different technologies – hardware and software – trying to find a healthy configuration that will give me a higher degree of confidence inside my trust zone.
I am specifically thoughtful about what my kids will see as they traverse the web. I want them to explore, but I’m also very concerned about what the web will throw at them. As a technologist that specializes in web security, I’m specifically concerned about the threats that web-based malware pose – specifically things like drive-by-downloads delivered via malvertising or malicious injections inside otherwise benign sites (i.e., hacked sites). There are a number of different tools I’ve played with over the past year and a half, things like OpenDNS, Disney’s Circle, CloudFlare’s 1.1.1.1., and CleanBrowsing.
For years I advocated the importance of good hygiene. The importance of using complex, long and unique passwords. But where this approach falls short is that it’s dependent on one very important element – you, the user.
Today, I draw all my energy trying to impress upon users like you the importance of a password manager. I personally use LastPass, but I don’t personally care which one you use.
The Sucuri team just released their first annual security report that looks at telemetry from hacked websites – Hacked Website Report 2017. It uses a representative sample of infected websites from the Sucuri customer base to better understand end-user behavior and bad-actor tactics.
It specifically focuses on 34,371 infected websites, aggregating data from two distinct groups – Remediation and Research Teams. These are the teams that work side-by-side with the owners of infected websites on a daily basis, and are also the same team members that generate a lot of the research shared on the Sucuri Blog.
In this post I will expand on the analysis shared, and add my own observations.
This morning, Armor, a cloud security provider, released a great report into the cyber crime black market. Armor was formerly known as as FireHost – they were one of the leading hosts boasting security first and have dramatically evolved over the years. This report was put together by the Armor Threat Resistance Unit (TRU), whom extrapolated data from a number of dark web sources; focusing specifically on the fourth Quarter of 2017 (2017/Q4).
The report strives to give us a view into an otherwise elusive world, specifically highlighting the economic foundation of cyber crime. Understanding the criminal economy is critical to understanding the ease of use, motivations and behaviors of bad actors.
Effective security takes more than technology; it requires realtime knowledge of the threat landscape and risks to your data. – The Black Market Report
The SANS Institute recently released their 2017 Threat Landscape Survey: User on the Front Line in which they interviewed 263 IT and security professional on the things that keep them up at night. Survey was conducted in May / June of 2017, it’s no surprise Ransomware was top of mind (e.g., WanaCry and Petya dominated the media). I am constantly amazed at the continued impact of Phishing threats.
This survey helps provide a deeper appreciation for what the security domain is faced with, while also providing insights into what the SMB market should be aware of (but are often not). This specific audience is technically capable, with a vested in interest in security as it’s their job (i.e., security / IT professionals), and it stands in stark contrast to the SMB market.
August 2014, Google released an article sharing their thoughts on how they planned to focus on their “HTTPS everywhere” campaign (originally initiated at their Google I/O event).
The premise of the idea was that every website, regardless of what it was doing, should be communicating securely between point A and point B. To help motivate users, it went right for the carotid artery by making it a ranking factor in search.
December 2015, Google adjusted their crawlers to start start prioritizing and indexing HTTPS pages by default. If you had HTTP / HTTPS, they would start giving more weight to your HTTPS pages.
The year is 2017 and we continue to give advice on the process of creating passwords. This must stop. The phrase “These are the tips to creating a secure password” should be stricken from all presentations, articles, tips and side-bar conversations.
Managing passwords has never been more streamlined. Organizations have invested countless hours and resources into building solutions that seamlessly integrate into our habits, and every business owner, and individual, should invest energy into integrating password managers into their overarching security program. So ask yourself, why are you, or your organization, not employing the tools designed to help you from yourself?
A framework should provide the underlying structure we require to build on.
Consider a home. Regardless of the type of home, they all have a similar framework. The framework keeps the house together and defines the basic structure, it starts with the foundation on which the house will sit. From there, the developers and architects build and expand it into something that fits their specific requirements. Without a basic framework, the house will collapse.
The same is true for how we should manage the security of our websites. We believe the security problems we face today to be technological in nature. I disagree. We invest all our energy into the latest technologies, making hardening and configuration changes in the hopes that we are addressing the latest perceived media threat. This approach is flawed, it lacks the structure required to adequately account for the emerging threats.
Attackers are successful not because we’re technically incapable, but because we are behaviorally weak. – @perezbox
At Sucuri we were naive to believe early on that our product was for everyone, we’ve realized over time however that it is not. It’s not that the product isn’t effective, but that the businesses leveraging the products lack a basic understanding and appreciation for basic security principles. Tools are employed with no structure in place to define why they are being deployed.
We have to do a better job of bridging the divide between the knowledge that today’s webmasters have, and those that they require to effectively manage their websites security. Start by defining a basic Website Security Framework that any organization, regardless of size, can employ.
The basis of the proposed framework is not new. It’s borrowed from the Framework for Improving Critical Infrastructure Cybersecurity, developed by the US National Institute of Standards and Technology (NIST). The idea is to educate users on a framework that already exists and can be easily leveraged for your organizations website security needs.
It is built on 5 core elements: Functions, Categories, Subcategories, and Informative References. Their relationship is as follows:
The functions are designed to organize the key security domains you should be considering. Keep the functions to these core five domains, do not over complicate.
As the illustration shows, the categories are subdivisions of the functions, and the subcategories subdivisions of categories. There is a one to many relationship between Functions and Categories, and Categories and Subcategories. The informative references have a one to one relationship with the subcategories, they are important to ensure that everyone is aligned with the exact steps being leveraged for each control and action.
The challenges we face today are as much human issues, as technological ones. Before looking to deploy security solutions into your stack ask yourself what your general disposition is towards security. The framework above is designed to help you in this process.
As you consider the framework, think of security as a continuous process. The threat landscape is constantly evolving, your security posture should also evolve. Revisit the process at some interval (e.g., weekly, monthly, quarterly). It’s not about the frequency as much as the simple act of actually revisiting the process.
In future posts I’ll dive into each function and category. For now, consider the questions you would ask yourself in each function, and how that will have a domino affect through the design, and eventually your deployment of security controls.
A simple thought exercise: Start with the Identification function.
When was the last time you created an inventory of a) the number of domains you manage? b) the various plugins, integrations, extensions, they leverage? or c) where they are hosted?
We do not get hacked because cyber criminals have an advantage over us, or because of the platforms we use. We get hacked because we are generally lazy. We fail to take the basic precautions required when introducing a new property to the greater internet ecosystem.
Note: Thanks AJ for your designs.
HTTPS is as important today as it has ever been. If you are transferring sensitive data you should use HTTPS to encrypt data in transit, that is not up for debate. Understand though that it is but one piece of a larger security conversation, and that’s where the message falls flat on it’s face.
I shared my thoughts last year on how HTTPS does not secure websites, and in the time since the message has only grown as to be expected. You’ve seen exponential growth of the LetsEncrypt initiative which we fully support at Sucuri (making us one of the first cloud CDN / Firewall solutions to do so). Additionally, organizations of all sizes have been adamantly pushing the importance of SSL, including both hosting and service providers alike. The WordPress Foundation, the organization spearheading the growth of the WordPress platform (currently at 27% market share of all websites), also recently announced that it would only be promoting hosting companies that offer SSL by default:
On November 8th, 2016, Google introduced a new feature to Chrome that would blacklist repeat offenders.
Once Safe Browsing has designated a site as a Repeat Offender, the webmaster will be unable to request additional reviews via the Search Console. Repeat Offender status persists for 30 days, after which the webmaster will be able to request a review.
The feature was introduced to address an issue where they noticed a trend where websites would remove infections long enough to have warnings removed, only to return once removed. They go on to say that this won’t affect websites that have been hacked. In other words, it’s built to affect intentional misuse versus unintentional.
Please note that websites that are hacked will not be classified as Repeat Offenders; only sites that purposefully post harmful content will be subject to the policy.
I can’t help but ask myself – how are they going to differentiate between intentional and unintentional misuse?
The concept of Defense in Depth is not new. It’s been leveraged in the InfoSec domain for a long time, and has it’s roots deeply embedded in military strategy and tactics. That however doesn’t mean that even those in the InfoSec domain explain or implement it correctly. To fully appreciate the idea of Defense in Depth you have to subscribe to a very simple idea:
There is no single solution capable of providing 100% protection against any environment.
I recently wrote an article on the Sucuri blog sharing some thoughts on how I feel we should think about the concept, and how we should go about deploying it within our technology stacks and organizations. I expanded my thoughts this past weekend at the BadCamp Hack The Planet summit in Berkeley where I shared some of the challenges we face in the website security domain pertaining to the subject.
The idea of Defense in Depth is simple: employ as many complementary defensive controls as makes sense for you and your organization. The optimal word being “complementary”. It’s based on the idea that every tool has a weakness, so find tools that help address them and that work in unison with one another. This does not mean you deploy every tool available, instead you must strategically map out the threats that you are most concerned with, that pose the biggest impact to your organization, and prioritize your defensive posture.
Today’s threats are evolving at a faster clip than any one solution or team can account for. It’s not a matter of finding the 100% solution, but about deploying the things we need to help reduce the growing risk. This has never been truer than in the website security domain. If employed correctly we should be better prepared to quickly identify issues, mitigate the threats and respond to incidents if so required. Attackers only need to win once. As defenders, we have to win every time.
This morning I had the privilege of speaking at the Higher Education Web Professionals Association (HighEdWeb) annual conference. I took the opportunity to share a number of points around the website security threats as they pertain to the education industry, our observations on the trends at Sucuri and more importantly our thoughts on how to think about website security.
I’ll be sharing some thoughts in the coming weeks specifically on the subject via the Sucuri Blog and updating this post as necessary as the recorded video and audio become available.