Tony Perez On Security, Business, And Life
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.
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.
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.
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 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.
It’s impossible to go a week without seeing some reference to a data breach, whether it’s a write up on what happened years ago, or updates on breaches that are still happening. The two breaches I found most interesting where a treasure trove of business data (not credit card data) was exfiltrated, and subsequently released would have to be the 2014 Sony Hack and more recently the Panama Papers hack. With this in mind, there has never been a better time for more discussion around how we think about data protection in our businesses than now.
I am partial to these hacks because as a business owner, especially one in the website security industry, the threat of a compromise is very real. We work under the guise that someone is always watching and the fact that a compromise is inevitable. As such, a lot of what we do is about minimizing the exposure and impact when it happens. There are many ways to do this as well as many areas to focus on, but one particular domain for us is the protection of the data that keeps our company going.
The threats of a compromise are real, and are not specific to operating an online store. Attackers find value in a number of things, some of which include your audience and resources. In this webinar I spend some time exploring a number of the impacts we should all be aware of as website owners.
I recently gave a webinar at Sucuri in which I discuss the impacts hacks have on you as website owners. In this session I dive into three core areas:
If you are currently infected, or know of someone that is, I encourage you to learn more about Sucuri and how they can help!
Recently I spoke at WordCamp US 2015 on the topic WordPress Security — Navigating Today’s Website Threats!!
WordPress is one of the most recognized website CMS platform available in the market. Dominating over 25% of the websites on the web, and over 50% of the CMS-based websites, it’s no surprise that it’s the preferred technology by marketers, sales professionals, small and large business alike, and those intent on nefarious actions.
Open-source CMS applications are no stranger to the battle they face with security. The size of the organizations adopting the platform also has little to do with it – from bloggers to mom and pop shops to Fortune 500 companies; the concern is the same. Can open-source CMS applications be deployed securely within their respective stacks?
There are those that look at open-source and have a general distrust for it. The idea that people can see the code and submit patches makes them uneasy. There are also those who can’t get their head around the general ambiguity of open-source, in which the code belongs to no-one and everyone. What they don’t realize is that most open-source projects have a stringent commit process.
The security perception is still a very real problem for the open-source CMS industry, and many feel it’s unattainble.
Over the past couple of years we’ve been reminded time and time again of how susceptible our communication mediums are to prying eyes. Classic examples of its susceptibility can be seen in the very public disclosure of General Petraeus affair in 2012, the release of over 170,000 emails after the Sony compromise in 2014, to the recent Ashley Madison compromise in which the CEO’s emails were shared publicly in 2015.
In either case, the information gleaned from these emails were damaging at best, and destructive at worst. In either case, what we should take away from it is that how and what we say, even if in what we perceive to be secure, is not necessarily the case.
Emails are a treasure trove of information, and as such we should all be spending a bit more time thinking of not only what we say, but how we keep what we say safe from prying eyes.
I work in the field of Information Security (InfoSec), specifically website security. With that in mind, it’s but one very small piece of a very large pie. Security is complex, even at the 50,000 foot level; within each specific area of the industry, it can get even more complex. It’s no wonder it can feel overwhelming.
I have to remind myself that Security, regardless of which domain you’re focused on, always comes down to three basic elements working in conjunction with one another:
When I think about blogging, there is perhaps no more important feature or concern than impacts to SEO. It’s perhaps one of the biggest concerns many will likely experience when performing a migration to the Ghost blogging platform.
I recently migrated my personal blogs to this platform and share some insights into the installation process in case you want to give it a go.
As you might expect, it’s had it’s up’s and down’s, much like when I first got started with WordPress. Needless to say, I’ve been making my way through it over the past few days. I’ve learned a number of things, and one such thing pertains to permalinks.
I recently wrote of the migration from WordPress to Ghost. In this post I want to share with you the installation workflow I used. I plan to go cradle to grave through the process.
I’ve tested it a number times, and it works every time, so even if you’re a novice you should be able to get it going. Just follow the steps:
Assumption: You have a clean install of Centos 7.0. For my scenario I’m using a droplet from Digital Ocean. What’s really awesome is that Digital Ocean actually provides a preconfigured Droplet for those that want to leverage Ghost. I believe it’s built on Ubuntu. I personally prefer Centos.
It’s only been recently that I have come to the realization that I fit into the blogger category. In doing so, I have started to place more emphasis on the technologies I’m employing to get my work done.
For the better part of 5 years I have been an adamant WordPress user. Not sure if you would say I was a power user, but I definitely employed it in my day to day activities, whether at work or at home. In that time frame I have witnessed the evolution of the platform.
Hosts are concerned with the security of their infrastructure, not with your website.
This is a distinction that most website owners fail to make, and it’s made more evident to me every day. This same misunderstanding however puts hosts in a precarious situation where clients expect security, and to some extent get it, but on the other it’s not the type that matters nor will it address today’s challenges. This is all compounded by the economics that drives the hosting ecosystem.
I should probably clarify however that this is probably not a blanket statement for hosts. But for a majority of today’s Shared hosts that deal specifically with end-user websites, it’s very much the case.