Webinar: In-Depth: How to Design and Deploy a Secure CMS Installation

We have a very interesting topic to discuss today. We're gonna be talking all about security. It's a major issue right now, not just for organizations and companies it's across the news. This has become a major thing that a lot of people are talking about.

One of the biggest areas where there's problems on the Internet, in terms of security, is with their content management systems, so we're gonna talk about that today, dig in-depth to why these things happen and what you can do to avoid it happening to you.

Today's agenda, first off, I'm going to introduce you to who I am. Anyone who's been on the webinar before, you already know who I am obviously. I will dig in that in a second. We're gonna talk a little bit of the overview of what our topic is today. We're gonna talk about why you get hacked, which is gonna being kind of interesting. There's two different types of approaches. We're gonna talk about the types of attacks, you know, how these things happen. We're gonna talk about how if you have an open-source CMS today, how you can secure it. Then, we're gonna talk about a more secure type of architecture, something we've talked about before. To give you a preview, it is decoupled, and we're gonna talk about that a little bit. Then we're gonna go into a Q & A from there.

Who am I? My name is Peter Czech. I'm the CEO of the New Possibilities Group. I co-founded the company back in 2001. My background is custom web development, UI/UX design. If you ever need to get me, that's my email address. What we do? We're the experts in development of safe, secure custom content management systems. We focus on custom web development and web design to create websites and applications for customers/clients with complex requirements. That's basically what we specialize in. The more complex the better. We try to take complex problems and solve them with unique solutions tailored for each individual customer. Our experience with just a couple of the companies we've worked with: We've launched hundreds and hundreds of websites over 16 years. This is just a small preview of some names that you might know. We work with a lot of smaller companies, obviously, small to mid-size, but many enterprise customers as well.

Who are you? You're here probably because of one of these reasons. Maybe in the past, you've had some security issues with your website. Maybe you're about to undergo a design and development project, or maybe you are in the middle of one right now. Maybe you're concerned about potential vulnerabilities for the CMS that you have today. You're probably interested in some quick and effective ways to secure your website. No matter who you are, thanks for being here.

We have quite a lot to go through. I think I had 56 slides here today, so I'm gonna try to take you through them as quickly as possible. Also, on the right side of the GoTo control panel, you can put in questions, so feel free to ask questions as you go. I'm happy to answer them. I will have a time for Q & A at the end, but if you could put up your questions early that will help me pick and choose which ones we're gonna answer.

Let's talk about website security and why's it's so important.

The first thing is: a lackadaisical approach to security can really make or break your company's reputation. It's very difficult to recover when your website is breached from a security prospective. Worse than credibility and reputation, and you also have a liability. There's an economic liability, which we're gonna tell you an example of something that happened to Yahoo in a little bit. Again, you have to worry about how you look, how people perceive your organization, but also you have to worry about what's the liability if your website gets hacked and valuable data is leaked. Don't forget, from a personal perspective, if you're a marketer, a CMO, or an IT professional, you know a security breach—I hate to say it, it kind of means your job, it means your butt's on the line, so ultimately somebody at an organization is gonna be responsible for this. If you're the person picking and choosing what your future platform is gonna be, you really have to take it seriously. Every time, I talk to potential customers, they say security matters, but it's like fourth or fifth on the list. This year, 2017, it really needs to be number one on your list of concerns. Flexibility in any platform is important, but security has to be the number one concern.

Let me just break down some recent news, some things that have happened. Here's Rudy Giuliani, America's Mayor, the Mayor of New York City over here, which is about 10 miles to my right, to my East. He had a really bad January. He was appointed to be the Cyber Security Advisor to the new administration and instantly, the internet did what it did. It went and vetted him to see, "Hey, does he actually know what he's talking about?"

What did they find? They found out that his websites, two of them, I think it was Giulianisecurity.com and then he had another one. They were both completely out of date. They were running on Joomla from about four or five years ago. So bad were they, that he actually just took them down and the sites are gone. If you go to Giulianisecurity.com today, it just brings up a DNS error. Obviously, it doesn't look good. We don't feel that he's credible on the subject when something like that happens, when news happens. He is obviously someone who's well known. He will recover from this, but for companies that are staking their claim on security or things like that, if he was any other cyber security company, they would be toast.

This is one example. Unfortunately, I have just too many political examples, but it just happens to be the hot topic right now. That's the first example.

Yahoo. This is something that happened. They're obviously looking through, going through an acquisition. They lost $350 million of value based on the fact that they exposed [32 million] accounts via a vulnerability. This is a huge price to pay, which is going to effect every single shareholder. This is an example of a liability in terms of finances—$350 million is quite a lot.

Again, I hate to get into politics, I am going to try and stay agnostic from it, but this is something that's been huge. John Podesta, his emails were stolen from a Gmail account, which is inherently a relatively secure system. He had a weak password and there was a brute force attack, I believe that's what it was. Those emails got leaked all over, and we all know how that may or may not have effected the ultimate outcome of the election last year.

Internet security affects us in all different ways, it affects not just your personal finances, if those passwords get out there, but it affects what's happening globally. This is a story that's going to become more and more prevalent, and you're gonna hear about it on a regular basis. I'm gonna talk about a major WordPress hack that just happened a couple of weeks ago. We're gonna get to that.

We're talking about this CMS here. This CMS is a very logical place for hackers to go after. It has a lot of moving parts. I'm gonna focus the conversation today more on open-source content management systems. Obviously, a lot of these types of vulnerabilities exist with closed-source or licensed models as well. I'm gonna focus a little bit more on this just for the purposes of this conversation. Open-source CMS's are, just what I said, their open communities get together. They work on the code for these. They share the code. The code is there for everybody to see. It means it's open. It's accessible, and as the community goes through changes, they push it out and distribute it as new versions of the software. The larger the install base, the more it seems to me that these things become targets, simply because there's so many out there. We're gonna talk about the types of hacks that are automated, just looking for popular platforms in a little bit.

Because it's open-source. The accountability, it's a little more minimal versus something that's licensed or enterprise. There's no one person you can go after. The accountability really falls on you or the person that you hire to go ahead and secure the website. That's always something to remember. The real issue with these systems is the extensibility. Everybody says, "Hey, these platforms are great because they allow for plugins and extensions and modules and every different application has its own vernacular for that." But those modules oftentimes aren't being vetted by the community that puts out the platform. Therefore, there could be gaps in the plugin or gaps in a theme that were never looked at by the core team for WordPress or Drupal or Magento or any of these platforms. In that area is where there's a lot of vulnerabilities that people have to worry about. So I want to end, it's a great thing. You can make your website do anything very quickly by installing this software, but you really don't know what's under the hood.

Let's talk about why perhaps your website might get hacked. Unfortunately, I am sure many of you have had this happen to you. There's two main ways. Number one, people are targeting you; it's a deliberate attack. Number two is more of an automated type of attack where people are looking for vulnerabilities for a variety of various reasons.

Let's get into deliberate attacks first. These things are the worst. They make you feel the worst. You know you're a target. You’re super paranoid. It's a violation. Nothing feels worse than when this happens to you. The types of attacks that people use, we'll go into each one of these in a little bit—brute force trying to steal your passwords, denial of service trying to take you offline, SQL injections or cross-site scripting. We're gonna talk about that in a second. There's a lot of different ways that they can do this. The purpose is typically to deface the website, to embarrass you, or to take you offline. That's typically why these things would happen in deliberate fashion.

Now, automated attacks. These are focused on vulnerabilities within software, and it's automated machines that are gonna try and do it. This is very common with open-source software. I'd say this is the vast majority of hacks that happen. Most of the time, when we onboard people, new clients, and they come and they say that their site's been hacked, usually it's something such as this. Typically, a goal is to inject something that has a purpose, so it might be malware.

The purpose to putting malware on a machine—well, there's a couple of reasons. First is maybe just to propagate itself. There's a really great documentary out there about the United States Intelligence and Israeli Intelligence. We actually created malware that got introduced to computers all around the world. We were looking very specifically for one set of computers, and it was in the centrifuges, or was it in the—where they keep ... I don't even know. I'm not a nuclear scientist obviously, but where they keep the centrifuges in Iran was the target. Millions and millions of computers, all around the world, were getting infected by this software. The software specifically was looking for a particular model of the centrifuge motor made by Siemens, and when they found, it was going to infect the motors, causing them to go into overdrive and burn them out. Your local computer might have been infected by this malware with that particular purpose. That's one reason why this gets out there and propagates.

Another reason is to distribute bulk email. This is getting a little bit less prevalent, but a lot of times, software will get installed on your server, flood your mail queue, next thing you know you get an email from your host saying, "Hey, why are you sending tens of thousands of emails and we're gonna take you offline?" It's gonna happen through malware infection. One other thing that used to happen, but it happens a lot less now, is black-hat SEO where these scripts would go out, install links on your site, trying to build up the backlinks to a particular website. Google's pretty good now about avoiding these types of things. We don't see that as much, but that's a reason why it used to happen.

What exactly does happen? Here's a great example. Here is an example of some code that was appended via a malware script. It actually went into an installation of a CMS and started appending this code. This particular code here is, I believe, just appending a link to a particular site. This happens all the time. This is extremely common. What will happen to you? If they know there's malware on your site, when users go to Google, do a search for you, or if they're using Chrome, they might actually get a warning like this. This is death. This is the worst possible thing that can happen to you. If this warning goes up, it's gonna be difficult to get rid of it. It's gonna effect your SEO. You could spend years and tens of thousands of dollars making your site rank organically well and something like this will absolutely kill you. Very, very, bad thing. This happens all the time.

Here's a defacing attack. This actually, and back to politics, but politicians are very good targets for people. This is Donald Trump's personal fundraising website. This got hacked a couple of weeks ago. The hacker went and made a political message. These are the types of things that happen. I've seen this happen to sites where they were not necessarily a known target but a person found that they could get in, and they put up a message like this as well.

Let's talk about the types of attacks, what specifically these things mean, so we're gonna start with a distributed denial of service, which is also known as a DDoS. This is something where it is typically aimed at you in particular. What happens is thousands of computers around the world all start to focus on and target one destination with the goal of taking you offline. This is an actual attack map, and I forget what it was, it was toward a company in the United States. You can see all these different, all this inbound traffic coming from all around the world with the express purpose of taking them offline. These are very difficult to fend off if you're not prepared. Luckily, there are providers—I'm gonna try to give you a little bit of quick defensive tips for each one of these, by the way—there are providers, such as CloudFlare, that actually can work to mitigate this level of risk, and the price point on these things are like $20 a month. It starts at $20 a month and it can effectively mitigate the risks.

DDoS is something that we see. Typically, again, it's aimed at somebody in particular. Another thing you have to keep in mind is if you're hosting environment is hit by DDoS, let's say you’re using a shared hosting environment or something similar to that, you have another server, another company is in the same network and they're getting hit, that can take you down as well. There's definitely a little bit of secondary causalities with something like this. You always have to be careful and make sure you're hosting in the right place and have a little bit of separation from everybody else.

SQL injections, very interesting. If you have a simple login form or form entry on your site, an astute hacker could actually try to inject SQL code into the form, causing it to do all sorts of other nasty things. At a top level, your database is probably gonna handle SQL code. SQL is the language structure, query language that powers your database. In this example, the guy actually put SQL code into the username box, and it's actually telling the database to destroy a table of data. Now it takes a little bit of guessing, but let's say you’re using WordPress or Drupal and you didn't change your default tables in the database and someone finds a way in. They could destroy, or steal, or do any number of things with your database just by doing a SQL injection. It can affect the webpage output. It can give access information. This is a really dangerous thing.

The best defense. First off, with something off-the-shelf like a WordPress, change your root table name. Instead of having WP_whatever, change the naming convention. That will actually significantly mitigate your risks. Another thing, just have proper coding and development techniques. Make sure that you look for this sort thing. Make sure that when you have a username field that you don't allow these weird characters in there. This is like Development 101, but a lot of people don't think about it, unfortunately, a lot of the developers.

Another thing, if you have a database with important information or a table with important information, don't store it in the same place as your CMS. Try to decouple at least that, so that if, God forbid, you are hacked, they're not gonna get access to it. These are relatively simple things.

Cross-site scripting is very similar to SQL injection, it also uses typically forms or the query string on a website. In this case, they can actually inject malicious code into your site, into the front-end experience, so they can put malicious javascript and access your cookie data. If someone were to access cookie data, they could then figure out how to pretend to be you on a particular website. How do you prevent this? Be on the lookout. Have proper coding and development techniques; that's gonna help you. Make sure that you don't accept these weird characters and these weird inputs into query strings or forms. It's actually relatively simple.

Brute force attacks. You can get software and you can download this to your computer that will attempt to log in over and over and over again to a variety of different services. It happens all the time. It targets login areas so they'll try for a username they might know. Maybe somebody who did research on a target, and they know the person's email. They might try to log in over and over again. There's a couple of ways, this is trial-and-error obviously; you can definitely fend this off with a couple of development techniques. You can have login limits. You can lock people after five failed attempts. This probably happens to you guys with your banks all the time. You can do two-factor authentication. This should be kind of like a no-brainer. It shouldn't be a possibility that someone can log in over and over and over again to try to guess a password. The first thing you can do as a user is have a password that actually is significantly complex, or it has characters, it has numbers, letters, upper case, lower case. Try to make it as complex as possible.

With automated attacks, again, they focus on known vulnerability. This is most common with open-source software. The goal again is to propagate itself. What do you do in terms of this? This is where you keep your CMS up to date. You keep the software up to date. You prevent these injections from coming in. You not just make sure your core center is up to date, but you make sure the plugins and the themes are as well. Those are areas where these automated attacks are really going to try to focus.

A couple things I've seen. This is just from my personal experience. In one case, we had a vulnerable WordPress install. I onboarded a new customer. I'm home on Friday night. I have nothing to do, which I shouldn't admit, but it's the truth. I log in to check out their WordPress install. They hadn't logged in in a couple of months. The minute I went in and tried to edit a page, every single file on their WordPress install got appended with malicious code. It was waiting for a trigger, and I triggered it. This is something we'd actually seen.

Another thing that was interesting. We actually saw someone whose office computers got infected with a worm. It was looking for FTP credentials. Once it found them, it would log into those sites and then change every HTML and PHP file, which is fascinating. It happened to one of our customers, and that was, again, these things always happen on a weekend. It was a very long night, where we had to manually go in and restore file or edit file to get the malware out. That was an interesting week.

Another one, viruses that compromise databases and try to actually dump out all the user data. This actually happens. When you're coding the website, you always make sure you encrypt as much of that data as possible, especially passwords. It's unbelievable how often this sort of thing comes up.

Then, there was this nice hacker. This guy who actually broke into a client computer, didn't do anything malicious, but left a note to say, "Hey, I was here and maybe you should do this and that." That actually happened a really long time ago, but I remember going into a client account and seeing a note and being like, "Oh man, that hurts." That was one where it wasn't malicious, but it was targeted. The guy was after this person in particular, this client.

I'm gonna talk a little bit about platforms. Some are obviously worse than others. On the open-source front, WordPress and Joomla just seem to be the absolute worst. Drupal is a little bit better. The larger the install base, the larger the risk because they're gonna be bigger targets. WordPress right now, I think, has 6,000+ vulnerabilities that we know about. It's actually a pretty astounding number. Now, I don't want to pick on WordPress too much, but I am because it's the worst offender. I absolutely have to bring it up. I'm gonna digress in a minute, I'm gonna tell you my thoughts about WordPress. It's getting more and more popular, and this is why we need to nip this in the bud and really look at this and think, "Is this the right choice for us to make?"

Just a couple of weeks ago, and here's an article from the 10th of February from the BBC. There was this massive hack that was enabling hackers to come in and deface tens of thousands of websites, and WordPress actually delayed the notification. They sent the update out first, but didn't say what they were updating. They were just telling hosting providers. There were people that were finding it and taking advantage of it. This again tells you how important it is when there is an update, to run it. It also tells you how every single time they released that they tell you, "Oh, we fixed these problems. We fixed these problems." But there are so many people looking to take advantage of it. This just happened a couple of weeks ago.

The core problem with WordPress is really just the architecture. It's kind of dated at this point. It's not really built for security. Being a tool trying to solve so many problems for so many people, it has taken on these layers of risk. The more you try to do, the more software you need to do, the more of the code you need, the more holes and gaps you're gonna introduce. One of my biggest problems with it is it's an old methodology. Your display, which is what users use, and your admin—they're so tightly integrated, they use the same code, the same code base; you can't really separate them. We're gonna talk about that in a little bit.

The other thing about WordPress is just installing, it isn't enough. You really have to take extra steps. I can assure you, 90% of people don't know or don't do those extra steps. Which is resulting in this bubble. This is where I'm gonna digress a little bit, and we're gonna pick on WordPress just a little bit more.

I really do believe that it's kind of like a software bubble at this point. Everybody's using it. Now it's making its way into the enterprise environments because the people that are now being the decision makers have been working with it for a while. They know it and they have a comfort level, so they're requesting it more and more and more. I assure you that if management really knew what the risk levels were with WordPress that it would not be happening. When you look at the top 100 sites using WordPress, it's a smaller percentage than when you look at the top 100,000 because it's near the bottom of that range where everyone is really using it, but it's starting to infect back upwards. I think this is dangerous. One of things is the ease of use of WordPress and how easy it is for people to customize it. It has really introduced these nonqualified developers into the world of web development. They're infecting the enterprise area because they might be good salespeople, but they don't necessarily know what to do.

Back on our political theme, the liability here to these enterprise organizations is huge. It's just big. I think that people have to start thinking about this. Also, on the lower tier, you have people picking WordPress because it's budget conscious. A lot of people know it. A lot of those nonqualified developers, well, they're cheap too. These people that save money continue to save money because they don't update it. You have to continuously keep it up to date, or all those risks we just talked about are gonna come and bite you in the butt later.

I just want to give you this little example of what we did. I don't even know how I came up with the idea to do this. I had an intern do this, help me out. We found a list of the top 500 cyber security companies in the United States. They do security software, hardware, consultant services, physical firewalls, all sorts of things like that. We have 302, literally, 302 of 500 used WordPress as their core. Out of those 302, 297 of them skipped some level of step or some step in their level of security and it just—I'm at a lack for words. I just don't know why that would be. Again, I think that they're not really paying attention. I think everyone cares about security, and then they hear some lip service from people that say, "Oh, WordPress is very secure per X, Y, and Z," but they're not taking these extra steps. These are relatively easy things that you can do. We're gonna talk about that in a little bit as well.

To give you food for thought, and then I'm gonna get off the WordPress, stop beating it up. Automattic, this is the company that's really behind the WordPress movement. They have a VIP hosting plan and basically, this is aimed at enterprise organizations that want to use WordPress and they need to keep it up to date, they need development support, they need CDN delivery, traffic insurance, and things like that. Look at those prices. Their basic plan is $5,000 a month with a $15,000 setup fee. That's just for a company blog. When you go up from there to an enterprise site, you're looking at $25,000 per month. $300,000 a year, $15,000 setup. That's what they're charging to keep their platform secure.

Everybody has to think about this. This is what they're recommending for a high-availability WordPress installation, anywhere from $60,000 to $300,000 a year.

I'm gonna leave the WordPress stuff alone a little bit from here on in.

What can you do if you're choosing a platform now? Consider better alternatives. If you're stuck with WordPress or Joomla, start securing it immediately and then continue to manage and monitor it. I should have also said continue to update it. If you're not updating it, you're gonna pay later.

At this point, I want to introduce you to a couple of graphical models that we've made. I think these are very helpful in kind of understanding how the whole security setup of these platforms works. This first model, and it is complex when you look at first, but we're gonna take it step by step. This first model is gonna talk about the classic integrated CMS like a WordPress or a Drupal. We're gonna talk about how it looks when it's insecure vs. how it looks when it's secure.

So we start with your classic integrated CMS. This is what you get off the shelf. You have your website, your front-end experience, and you have your CMS, and these are integrated pieces. They live together, they share a code base. They can't be uncoupled in any easy way. I know someone's gonna comment and say you can decouple WordPress, but the vast, vast, vast majority of people, 99.9%, are never gonna do that.

This is how it looks. You have your website, you install WordPress. This is what's gonna happen. For these pieces of software to work, they need other tools on the server, so you have your database, which could be SQL server, mySQL in the case of WordPress or Mongo, just some common examples. Then you have a scripting of interface or scripting language, which will allow actual logic to be conducted; .NET, PHP, Ruby, Java. These all operate on a server such as Linux, Windows, Solaris. These are all examples of actual physical server boxes, and in order for it to be served out to a user, they go through a web server like IIS, in this case a Microsoft, Apache, or these other ones that we mentioned here.

All CMSs need these tools on the right side of the screen to actually work. Here come your visitors. On the top you have your little ... The blue guys are the nice guys. The purple guys are, you know, these aren't good people, and then you have your little administrators in the green and they're all coming in and using your website. They're hitting this one integrated unit. Every time they're operating with this integrated unit, all this stuff on the right side—in fact, let me use my pointer so you can see—all this stuff on the right side is obviously going to be in motion, it's gonna be talking to each other, the database is gonna be ... The scripting language is gonna request information from the database, the database is running on the server, the scripting language is gonna script, put it all together, compile it, send it to the web server, and that's gonna go to the user. Just to make things nice and easy. Everything's working to handle all these requests.

The real issue is, you have your happy little visitors and your administrators, but you have these other people trying to get in at the same time. They could be an automated bot, could be a malicious character like an individual, it could also enable that denial of service attack. It could be a lot of visitors coming at once. When all those visitors come and visit your integrated system, they're going to be exposing all these individual units underneath. They're going to be able to—obviously, the website is going to be using the database and the scripting language, but if it's not set up properly, like I said with cross-site scripting or SQL injections, these nefarious characters can actually get access to a database or access to your scripting language or your web server or the server itself.

Not only is there that, but if you’re not set up correctly, these characters can actually try to infect the individual components. They could try to break into SQL, they could try to break into PHP,or Apache, or the Linux core itself. You have a lot of areas of vulnerability. This is pretty much what happens when you take WordPress off the shelf. They have some layers of security and common coding practice to prevent things like cross-site scripting and SQL injections at the core,—again, plugins, you can't always be assured. Off the shelf, it's not gonna go and protect individual components from being maliciously taken advantage of. It doesn't have anything to handle denial of service off the shelf. It's fully integrated, and these guys that get in, they can access all these individual components if they're astute enough to be able to do it.

Let's talk about how you would secure it. The first thing that you note is different. This is step one of securing. We've hidden the CMS. It's little bit darker, so you can't really see it. So many people who use WordPress don't hide the admin pass. What I'm trying to do here is make it more difficult for people to determine the platform that people are on. We have to hide to a certain extent. That's the first thing I want to do.

The next thing I want to do is install a firewall. We talked about this before. Cloudflare can do this; it's $20 a month. There's no reason not do it, so let's put a layer of protection between the people that are going to be coming in and the CMS itself, the entire framework. Now, by hiding it like we say here, we've made this admin portal more difficult for attackers to figure out. An astute attacker, they're gonna find other ways, they're gonna dig deeper, but we're making it more difficult. We're making it hidden, the administrators are free to find it because they know where it is, but then some of the people who look to do you harm or even your competitors just doing a little bit of research are gonna have a harder time finding it.

Now, the next step is to protect your components, your web server, your server, your scripting, your database. Put those behind firewalls as well, preventing ... Let's see if I have it here, hold on. Oh, we're gonna have to go to another set. If we do the firewall, we're gonna protect the individual components from the hackers or malicious characters trying to get into each individual piece. We only want these things to communicate with each other to the CMS and not be open to the outside world, very, very important. As you can see here, I've added the visitors, we still have the same visitors but with proper protection, we're gonna start bouncing off things like visiting DDoS. Cloudflare is gonna protect that from happening. That's with their services they provide, so they're gonna come and hit that firewall and they're gonna be bounced away. You're gonna have a layer of protection. That's still gonna have your malicious characters who are gonna try to get in, they're always gonna try. What's gonna happen is they're gonna find it harder to get through to here to all these components because we will have protected it. Also, we've put a little layer around this entire interface here. Let's just say that represents proper coding practice and keeping things up to date. There's no real gaps in this scenario.

The other thing, and this is what I talked about before, and I should probably change the order. I'm gonna do that next time. These individual components are now protected from the firewall, so even if the people do get through, we're gonna work to make it so that they have a harder time getting deeper into the platform. Here we are again talking about how we protected its individual components. This is what it looks like when your system is integrated, off the shelf, but properly has been protected. We've taken the individual components and we've said, "Hey, let's put them behind, put them in safe quarters, let's make it harder for people to determine who we are. Let's have a layer of protection against things like denial of service attacks. By keeping up to date, we're going to prevent some of the automated bots from taking advantage of us." Obviously, there are some other tricks and things we can do as well, which probably would go beyond the time I have here today. This is what it looks like. With that said, that's how you have something off the shelf, how you take it from insecure and make it secure.

Let's talk a little bit about what a good architecture, the perfect architecture looks like. We strongly believe that the best securities be a separation. This means taking the administrative portion of your website and separating it from the front-end experience. This minimizes access points. It minimizes points of failure. This, we believe, is the most secure way to actually have a CMS running today. It's sort of a new concept, it's getting more popular today, but it also goes against the grain of what everyone's been teaching you about WordPress and Drupal and all those things for a very long time.

On the left side of this model, this is what the integrated and secure system looks like, where you have your website, your CMS, and your components. This is what decoupled looks like. It's a little bit different. You have this unified unit of your CMS, which is still using the same tools, but they’re locked away and they're kept away from your front-end website, which is communicating through this pipe, which is an API or some other method of connectivity. Let's just dig a little bit into exactly how this works. Your CMS, it's hidden away, blocked behind a firewall, administrators can easily access it. They know where it is. There's no issues for them to make the changes that they need to make. Then we have your website. Your website is living in another environment. I have it here on the cloud just to show that's one possible way to do it.

It's funny we talked about S3 earlier in the call, and they're having some issues today. But S3 is actually a very good delivery model in terms of security. Kind of ironic saying that today when they're having issues, but it's true. S3 being cloud-based, let's use that as the example. Your websites on the cloud, your CMS is over here. How do we make them communicate? We can hook it up with an API, that's one way. We can actually publish flat files, and I know that's another way. There's some other methods that you can use as well. What we've done is we've limited access from the CMS to the front-end site. We have one point of access only. This is what decoupling is all about.

As you can tell here, if the malicious characters, the nefarious characters—I love those words, especially when we're talking about security—if they're trying to access your CMS and your framework, they're gonna have a really hard time getting through the firewall. One of the reasons is, they may not even be able to determine where the CMS lives. We have customers who have the CMS on an internal network that's behind their VPN, their private network, and they may even turn their CMS off. You can't do that with WordPress, you can't say, "Oh, I'm just going to turn the CMS off. I'm gonna hide it," because they're so integrated. These are things that live together. The same goes for all these off-the-shelf platforms whether they're enterprise-level or open-source. Here you can see again, you're still gonna have the problem. There's always gonna be the bad actors that are gonna be dispersed among your normal traffic, but in this case, it's very limited as to where they can go.

They can get to the website, they can view it, but they're not gonna have any of those avenues or gaps that they would have if the system was put together. This is a pretty simple approach. Let me just go back to it. There's not a lot of moving parts to it. You can utilize, on the server side, the same exact software. You can use PHP. You can use .NET. In this case, it could be Windows; it could by Linux. The web server could Apache. It could be IIS. There's a lot of different ways. You're agnostic with the database. It could be mySQL or Mongo or whatever you prefer. This layer of protection, this is something that can't be matched by anything that you take off the shelf. It simply can't be done. With the caveat there, I am gonna say, there are plugins now that people are using to attempt to decouple things like WordPress. I'm not sure what the purpose of that is because WordPress is inherently still going to be insecure; you're gonna have to take all those steps to lock it down. There's just not a lot of upside to taking ... It's kind of like putting lipstick on a pig. I guess there I am picking on WordPress again.

A couple of other benefits of decoupling, and this is actually the last slide. I was able to talk pretty quick. Decoupled, and we have a whole other webinar about this. Take a look at The CMS of the Future, where I talk about this pretty exhaustively. We talk about, we have a webinar, and we have an ebook as well. Decoupled systems are front-end agnostic. If you look back at the slide, you can use any technology you want for the front end and remember, front-end technology moves at a much faster rate than back-end. Just because the front-end technology has changed over the past two years, that should never affect you and your CMS and have to make any changes to your CMS. You shouldn't do it because the front end has changed. If you have a decoupled system, not only do you have the freedom and flexibility to make your front end interesting and use a decent technology that might be cutting edge. You'll have a CMS that can actually survive through those interactive changes. We see off-the-shelf systems continuously changing what they can do to keep up with these technologies on the front end that should be completely agnostic from the back end. Yet, it happens.

The other thing too is ... I'm gonna go back and forth just to use my model. Let's say your website isn't your only delivery method. Let's say you have a mobile app or feeds going to partners or OTT devices or things like that. This database really serves at the center of an ecosystem of various things. Your display isn't just the website anymore. If you look at—WordPress was built ... I'm picking on WordPress too much. Let's pick on Drupal. Let's go that way. Drupal was built for web display. It was not built for all these other devices that are coming out. It is not device-agnostic, and that's why the people who control these projects, they're starting to realize that. They're attempting to decouple these systems, but again, the original intent was to have them tightly integrated. If you're building some sort of application for something complex and you're gonna have more delivery methods than just the web, you absolutely have to consider decoupling. As I said before, the lifespan, having a CMS that can last you five, six, seven, or more years, running in a separate environment vs. the front end, there's an economy there. As opposed to over seven years, you could be through two or three versions, massive versions of WordPress or Drupal. You just don't know. You don't have predictability there either.

With that, I'm gonna open up. I see there's a couple of questions. Let me just get to them in a second, bear with me. There's the little microphone. If you have any other questions, send them in now. I have a couple.

Sharon. “What are some decoupled CMSs that are available?”

It's interesting. Again, the off-the-shelf platforms like WordPress or Drupal, are obviously trying to become decoupled with plugins. I would not call them native decoupled. The most interesting things I see right now in terms of decoupled, other than custom, which is what I recommend doing, is building a more customized framework. There are some SaaS companies right now, like Contentful. They're offering a CMS platform that is actually hosted similar to any other software as a service. You define what your data types are, and they make everything accessible through the API. I think that's a very interesting model. There's another enterprise model that's doing that right now, but I forget who it is. You'll have to excuse me on that. I think you're gonna see more and more companies doing that in the coming years.

My one hesitation with that is that I feel like that is more handcuffed than even off-the-shelf software because you're dependent on someone else's business to be successful in the long term. In terms of the proper way to do decoupled to give you complete flexibility and ownership, I would say probably building one is the best way to do it. If you went for a Contentful and they're not successful, and one day they give you a 30-days notice (if you're lucky) and says "Hey, the site’s going down," you're gonna be in a real bad place. You do have to consider that.

I have one more here I'm gonna do. Tim. “Thoughts on hosting providers that maintain WordPress?”

There's a lot of them out there. I brought up WordPress VIP, which is ridiculously expensive. I don't know who's paying that much, probably some of their super enterprise customers. It's funny, Automattic also, I believe, owns WP Engine, which is a decent environment. WP Engine, I believe, that they run the updates for you. They help you with a development vs. live environment. It's not a bad offering. It's not super expensive. I have had some issues with it. I believe, on the Drupal side is Pantheon. I think they're doing the same thing. One of the things you have to remember is that it's a good architecture that they have, but it is shared. If a lot of traffic is coming in to another person within their network, there is a possibility that could take you down as well. I think that's something to always be concerned about.

Another issue I had there, which is interesting, they made their development environment for each site publicly accessible. We had a client on WP Engine who had something like 5,000 pages, and their subdomain was crawled by Google at the same time as the live domain. There was nothing we could do to stop it. This was a massive bug, which resulted in Google thinking that there were duplicate content issues and affected the SEO of the live site. I was surprised that a company like WP Engine wouldn't have a solution for that, and this was not years ago. This was recent; we ran into this in the last couple of months. That might just be a specific problem to them.

There are hosting providers that take care of some of the updates for you. You could definitely give them a try. Always keep in mind, again, WordPress really thinks the value of enterprise level of security and upkeep is starting at $5,000 a month, so it's a pretty sizable sum.

With that, I'm gonna get going a little bit early. Our next webcast, I know it's gonna be on the 20th of March, a month from today. I'm just not sure what the topics gonna be yet. I'm still working on it. It's gonna be something, maybe we'll go back, talk about decoupled CMSs. Maybe we'll talk about a design development process. I have a couple of people with ideas. If you have suggestions, happy to take it. We'll probably know in the next couple of days, and then we'll start emailing everybody, so you can join us.

From there, if you need anything else from us, you can always go to our blog: npgroup.net/blog. I write at least one long-form post a week. If you have suggestions about a post this week, I could use a few—nah. We have videos, we have some great stuff up there. I also put up all these webinars, and we have a bunch of ebooks that you should check out. We're gonna be working on an ebook just about security because it's such an important topic. If you do need to catch us, again, it's npgroup.net. There's our phone number: 855-NPGROUP. Always happy to hear from you. We're located just outside of New York City. That's all I got today. Thanks for making it through with me. 45 minutes out of an hour. That's great. You have 15 free minutes. Go enjoy your day, and I will talk to you soon. Take care.