Our website uses cookies, which help us to improve our site and enables us to deliver the best possible service and customer experience. By clicking accept you are agreeing to our cookie policy.

How to Account for Security with Customer Projects.

Thursday, Nov 3,rd, 2016 at 11am PDT • Dre Armeda - Sucuri Co-Founder

Join Sucuri Co-Founder, Dre Armeda and learn how you or your agency can account for security with your client projects. Often, clients are not aware of some of the inherent security risks involved with managing a website. Dre will provide concepts that will empower website creators and agencies to manage client expectations and identify points during a project lifecycle where security principles and its importance can be introduced. He’ll also provide some actionable tips on how sustainment and security can be handled by you, the service provider as as part of the project and beyond with sustainment agreements.

Dre is Co-Founder at Sucuri Inc. He is a 12 year Navy veteran that fell in love with security and making stuff for the web. After his Navy days, Dre held various leadership positions in the tech start-up world including companies such as Applied Watch Technologies, Secure-i Inc and WebDevStudios.

Questions & Answers

Question #1: Thank you Dre. We've had a lot of questions. We've got a little bit of time that we can get to a couple of them. One question that came up was, when working with outside developers, what type of security practices should be in place to protect us as an agency?

Answer: That is an outstanding question. Hopefully, you have resources internally that have some means to understand the code that's being written and that it's meeting standard. Make a requirement around whatever platform you're using or whatever language is being used that's using best practices to sanitize, to escape. Basically, stick into best practices for that platform or that language. Use some type of code repository. Whether it's ... you're using some management tool like Git or Mercurial, whatever the case. Have some way to manage that so it could all be reviewed, time stamped and associated to whoever is developing it. I think those are probably the two core principles that I would stick to in terms of reducing risk from a code, purely just writing code perspective.

Question #2: All right. Next question. There has been a couple of questions actually around the topic of working with smaller clients who don't really touch their sites. These agencies and designers are kind of helping to do the updates for them with the software and the content but how would you best approach, dealing with small customers about cost? They're very nitpicky. Is it best to offer them a package. It is best to offer them kind of an a la carte per the thing that they're doing. If there is a security problem and they need to get it fixed then they're expecting this agency to handle it, but they think it should be included but it wasn't.

How do we deal with those ... getting those kind of small site, small customers that don't really understand and haven't really been prepared for the incremental cost that come up with the maintenance?

Transcription

Dre Armeda

Welcome folks. Creative services agency projects and building amazing websites for clients are things I have always enjoyed. So much so that I've worked in and out of the agency space professionally for more than 10 years. It's my equivalent to launching a rocket ship around the world if you will. We explore at our own leisure, only to come and find new things which is pretty awesome. There is nothing worse than souring a relationship with a client due to something out of your control. Maybe perceived but something that could have been avoided. Years ago, while working in the agency space, we were super pumped up that we had finally landed our first $100,000 job.

It was pretty epic. In fact, it was an e-commerce website so we were excited about that and we were on point to architect and build the entire thing from scratch. The company branding was something that we were going to simplify and work on. We were going to design and develop the entire site and the thing was, it was on a fairly tight schedule due to some of the marketing efforts of the organization and had a product release coming up that was really time sensitive. I'm pretty sure that they had something huge industry event of some sort, a conference that they were trying to launch the website at, the products at.

The time I had, I had a space to launch into production roughly two weeks prior to the event and we were on track. In fact, we were beating deadline. We nailed all of our requirements, the new branding efforts were to be integrated into print and even on some of the product logo markings for the products that were going to the events. QA went well and we were ready to go. The final approvals came and we worked with the company's web team to get the site into production. Everything was going smoothly. I'm pretty sure the time even ... I mean, I probably shouldn't mention this but we weren't Git or any type of source code repositories.

We were probably using like FTP, SFTP or something like that to get all this code into their network, their hosting environment which was third party. At the end of the day, the launch went well and we, alongside our client, ramped up marketing efforts for their events. The email and newsletter sign ups were coming along. They had other campaigns going. They were all geared up to push out all these products. Everything was exciting, right? We as an organization, as an agency, we're excited and we're marketing from our end. This new portfolio piece was going to help us engage with a whole new audience.

We have kind of leveled up, right, and we were excited about where this could really bring our company. We announce the work and even socialized it over the internet and our websites. The feedback we were getting was epic. All was well until it wasn't. Until we get a 1 a.m. phone call, I get a call, I answered the phone around 1 o'clock in the morning. My wife is going nuts like, "Who's calling?" It was the director of marketing who was one of the major stakeholders for this project and he was heated, let me tell you. It woke me up pretty quickly. He was a bit aggressive, to say the least and his voice was a bit on the high volume side.

You can certainly sense the enthusiasm in his voice. He told me, "Dre, you know, you guys really screwed something up here. We've got a major issue and we need your eyes on it, ASAP. Our website is down, okay and there has been a weird page that keeps popping up with techno music and it's telling us that we're stupid and that we own your website. These folks are telling us this. I don't understand it. Our team has been going through it." I ask, "How long has this been going on?" They tell me, probably about a few hours and that their web team had actually cleaned it up, removed the files, reinstalled everything but a short bit later, we get redirected again to this crazy page and I'm just wondering, I guess they don't like techno music, right?

Needless to say, it was a challenge, it was a major issue, they were defaced and it was clear that there was some type of backdoor that was allowing some type of reinfection to occur. Every time that they would remove it, it would happen again. What we've done is we put all hands on deck. We stepped up to the plate and we got the team together to work with the company to figure out what was going on and although, we felt that our code was solid and everything that we placed into production was legitimate, we did a review anyways and we did come to find out that there was nothing really wrong with our code.

There was no vulnerabilities that we introduced, everything was patched and up to date in terms of what we put into production and we're good to go. The company's environment, their hosting environment was really out of our area of responsibility at that point. We didn't really have full context as to what was going on in their environment. We had turned over our code and although we had access to get them setup and get the site into production, we were really limited in the interaction beyond testing the site once it was up online and I'm introducing fixes to any bugs that they may have requested during our maintenance stage.

We would offer like a 30-day maintenance stage. It was really out of our hands. At the end of the day, we stepped up because we felt it was important to keep that relationship with our client, again, we had just kind of leveled up into a new stage or phase in our company where our audience could grow into many things and would lead to potentially great growth for our company. We stuck through it with them and really, the issue got resolved. What ended up being the problem was, the site that we put up for them was actually on a third party host. It was a shared environment, okay. They had multiple websites.

I mean, I'm talking a lot of websites. Tons of different softwares, some are new, some not, sitting on the server and it happened to be an outdated content management system, some software on the server in another directory that had nothing to do with this production site, they were putting up, that was already infected. In fact, most every site on that server had issues. They had some type of malware backdoors, they had all been penetrated, there was some cross-contamination going across the entire server, lateral movement from one directory to another, which happens often in these shared environments.

We helped out our client and we cleaned up the site and really we stepped up and cleaned up pretty much all the issues on that server, because we felt it was the right thing to do. It was the right thing to do for them and it was the right thing to do for us. In the end, however, the infection was not our responsibility and that's something we got to consider, we got to think about. We aid the cost for that because we wanted to help remediate the problem for them. We saw some strategic value for us and for them, long term by fixing that. This happens unfortunately all too often and the challenge there is that, maybe we're not upfront about the discussions that we really need to have.

Although it wasn't our fault, we learned from it, we certainly learned from it. The client learned from it. We learned that there are things that could be done to help avoid these issues from the jump, from the get-go and we just used our time a little bit wiser in terms of discussing it being upfront about these things. We have learned that their environment was maybe not in the best shape. We have learned what it looked like, had we taken the time to do that up front? What could have or would have happened putting the stuff into production, if we would have known what was going on already with their site or that they had multiple sites there?

Maybe we could have done some cursory scans there and figured out that they had issues. Ultimately, this could have led to us picking up a new sustainment contract before our project ever went into production with them, right? You as a service provider have a responsibility to your clients and to yourself. Accounting for security is a big part of that and I would like to share some of those ideas with you today. My name is Dre Armeda and I'm a CISSP and I'm co-founder of Sucuri. Before Daniel Cid and Tony and I set off to build this service and this company, I was the CEO and founder of a small WordPress agency.

This is in a different lifetime and most recently, I served a couple of years as a chief marketing officer at WebDevStudios, which is an agency that creates sustainable web applications and websites for companies like Microsoft, Discovery Channel and even Campbell Soup. You got to get your chunky suit, man, it's amazing. Today, I want to talk to you about some of the things that you can do to expand your opportunity to become a long term partner with your clients and how you can help them become more secure while you expand some of your revenue over current revenue opportunities, because the opportunities are there.

It's really up to you to expand beyond the project and we'll talk about that a little bit at a high level. Before you get engaged though with any project, any new potential client, really the discussions need to start around what you can and can't do, what you're willing to do and really settle expectations both ways. What does success mean for you in terms of your interaction with the client and the projects that you engage with and what does that success mean to them? What is it, their business goals are and how can you align your services and your expertise with what their end goal is, their strategy? You build a relationship that last a long time and that everybody leaves happy.

I think it really comes down to understanding, communicating the requirements of the project and mapping that back to the overall business case. It's about expectations and setting those up from the beginning of the engagement all the way through finish, right? You don't know how many times, I've seen where people are just not aligned, in terms of the client and on the project side, on those resources and it ends up turning into just a big soup sandwich. Having that communication, setting up expectations up front is super important. I think it's really okay to tell a client if something is just not possible, right, or if something is out of scope and you need to be consistent with that.

You set the tone as to what is part of the project and what is not and I think being firm around what you will and won't allow will set the pace to make sure that you're meeting all of your timelines and milestones. For us with the relationship, you need to be candid and upfront. It's okay when things aren't included, right? Being open upfront about that will have you in a better place and will help you preserve the integrity of a project. You need to help educate and make aware your clients around everything that happens in that project. They're not subject matter experts in web. Typically, they might have some resources around it.

They might have some web folks on their team but they're only seeing a sub-portion of what that means to the business. It's up to you to help educate as the service provider. You've got to realize and help them realize that every action has a reaction and adding feature is a nice to have, which are always nice to have during a project will affect the timeline and the budget. Be firm about that again, right, scope creep will kill a project so you got to be careful what you allow in and sometimes there are strategic value to allowing things to push into the project and adjusting things accordingly but you got to be comfortable with not allowing scope creep and being consistent around that.

Don't assume, make sure that everything is worked off of documentation and approvals, okay. That's super important. Again, keep the project flowing. Always, remember, just like clients have expectations around what they get for what they pay, you should have some expectation of your own. I mean, that's something that is often not communicated. Make sure that you're talking about what you expect from your client as a responsible partner in this engagement to make this a success, right and make sure everything is formalized. As you've had that engagement, you've had those initial discussions, that initial contact, you've qualified a client.

It's time to really continue pushing beyond that and establishing your entire project lifecycle. This is sometimes something that is not clear. I've seen it even at a large agency level, where they don't really have a built out formalized lifecycle. Here is kind of a breakdown, and we all have our own magic approach to a project, okay. Everybody's got some type of sequence that they go through. There is going to be some approvals and there is going to be some scoping and all that fun stuff but we need to make sure that we understand that this is an integral part of a successful project. It's an integral part of building trust and showing that you are regimented and can step up to the plate at any scale of project.

This starts through the sales process. It really does, right, because now you've had that initial engagement, you set expectations, okay. You make contact and you learn. You do some type of high level discovery, understanding what those business requirements for your client are. Then, you move through the different phases of the project so that you can kind of make the project consumable. You break it into parts that you have a beginning and an end. A demarc place and you can work through approvals to move on to the next stage. Initially though, once you have that high level discovery, you're going to probably ... if it's a qualified client, you're going to engage and say, "Hey, look. I'm going to send you an estimate and a proposal and see if we're aligned and see if it make sense to start building this relationship and us becoming your partner."

As that happens, you start to formalize service agreements and what I found for me, is more to give that estimate, right? You only know what you know and at the end of the day, if they want every bell and whistle, once you get into the formal, really deep rooted architecture and project building, project plan building and discovery phases, you're going to learn really what they want beyond just, "Hey, I want design and I want the development of a WordPress, of a Drupal site, what have you." You want to learn what the business requirements are. You want to help make recommendations as what those things are but also figure out, at a granular level what the details are.

Do I want a slider that does these cool transitions to what type of dynamic effects need to happen, how forms will be populated, where they'll be sent, third party integrations, all of these things need to be part of your formalized project plan, okay. As you go into a formal design and development discovery, it's going to help you flush these things out as you architecture the project into a more formalized plan of attack that you can now send to your clients beyond that initial high level discovery and initial estimate so that you have a concrete idea of what the timelines and the budgets look like in every single requirement that need to come and be fulfilled for that project to be successful.

Not until then, should you start getting into the design and development of things because without those approvals, a lot of things could change, right? Once it's set in stone, then you have a vehicle and a foundation to start building change orders and things of that nature in the event they want to add or change things down the road. Once that happens, you want to go into the design phase and my recommendation is always to make sure that the design phase is completed and approved before you go on to development. It's hard when you piece or kind of portion the design.

This template and this part of let's say, if there is a branding and logo marking and things of that to be done, it's easier when everything is kind of completed and approved and all of those versions are completed and signed off on, then you move into development and create the entire environment. That's where really things start to come together. What is that dynamic effect? How is that slider going to work? "Holy cow, look at the logo and how vibrant it looks on the site. That is fabulous." The life that you're putting collectively into this project now starts to be something that's tangible.

You can see it, you can feel it and it's an exciting stage of the project. When you get to that point of development, it's the same kind of thing. Keep the same controls in place in terms of approvals. Make sure everything is approved and once it's approved, you should go into some type of QA phase. That QA phase in my opinion should be two headed. It should be in house QA for you and your resources, your development and design team to make sure that you go and balance that off of actual requirements, that were approved, that entire architecture and project plan and make sure that everything was fulfilled from your end.

What it is, and when everything is fulfilled, then you send that into the second part of that QA phase where you send it over to your client and the stakeholders from the client side for them to review and make a punch list of things that they feel and things that they may find that weren't fulfilled in terms of the contractual obligation. From that end, you can kind of cycle through them and say, "Yes, this was definitely part of that requirement, let's fix that" or, "Hey, this is a change or add, let's look at change order bid, to get that done. Let's get this into the development and then we'll move on from there."

Then you get into the deployment stage and you get this into their environment, whether it's them deploying or you deploying it. That is really the birth of the project, right? For the success of a project, all these phases need to happen in some capacity and every shop, every agency, every service providers is different in how they do that. They use different specific methodologies and so on to kind of come to their lifecycle or something that make sense for them, something sustainable, repeatable. They all vary but you have some of these components. Once that site is deployed, this is really just the beginning of the opportunity.

In fact, launching the site is a great feat, it's a great milestone but you don't see a return on investment, the day you launch. It's always exciting but that's something that needs to be measured and iterated on, overtime. Launching the site, after successfully moving through each phase of the lifecycle is active birthing the site. It is now alive, it's a breathing, moving entity. People are interacting with it. It's important to understand that this isn't the end. This is just the beginning of realizing that investment, okay. It's the birth of the site.

For it to be successful, it needs to be a long term thing and why not introduce services that could build a long term relationship with your clients in terms of maintaining and being a partner to help realize that investment, that return on investment for your clients. Extending offerings to them that help them be successful and at the same time, increasing your revenue stream. That's really where we're getting the opportunity beyond the project and I think there is a couple of things that could sit there. This is high level but I think it's important nonetheless. Why did they come to you, right? I think they came to you because you've done something really awesome. You've killed it for this client, in terms of the project but they came to you initially for some reason, right?

It was your experience building websites and you got a portfolio that you've worked with topnotch clients. Is it because you're renowned as the subject matter expert with a specific platform, Joomla, WordPress, what have you and you're just known for being able to kind of push the limits there? Is it because the site is important to them but their game is on the marketing side or they really want to push their search engine optimization capabilities online to really drive sales and your game is on point when it comes to SEO, SEM, things of that nature and can tie that back into the website that you've created for them?

There is always a reason that they come for you and when you get through a successful project, I think that that iterates that and it really validates that you are capable of being there for them. It's an easy sell at that point, right, for your clients to kind of think of you as a subject matter expert in these things and to build a long term relationship so why I went to you? Okay. Your benefit as a provider is low overhead and long term in terms of contract opportunities. There is a strong potential for revenue streams there and with minimal effort, really if you think about how you compare long term sustainment and maintenance to projects.

Projects take a lot of resources, right? We just talked about the different phases. From the discovery phase, what did the account executives and those getting involved to actually make the lead or client put in ... what's that resource take, what does it take from a development and design standpoint for your team to come in and develop these things? QA and testing. Step back, it's like a natural architecture for this to be successful in the first place and then deploying this. There is a lot of effort that goes into that which diminishes some of your potential return, in terms of profits.

Profitability can be really great in projects but sometimes, not as much as, you can kind of see or realize with maintenance and sustainment which could be a monthly thing. It could be a yearly thing but it's a recurring model that gives you the opportunity to do work to sustain their efforts with minimal effort and resources from your end. It's a great opportunity to extend one, the relationship but also your revenue stream beyond the project. I think that establishing value for a sustainment solution is pretty simple. There is some caveats to that but certainly, I think that there is already things that your clients are thinking about that you can really push in a way that's meaningful to them and help them realize their value of partnering.

One, it's in their best interest, right? Ultimately, again, the site is just coming alive, the day that it's deployed into production. You need to continue to build on that. If they're doing things right, they're measuring the successes of those websites, right? Whether that's from a traffic perspective or a messaging or what have you, they should be measuring that and making decisions on improving that in certain areas so that they drive conversions, they drive traffic where they need to and they reach success. Success is different for everybody. It could be on a marketing site to have someone fill out a contact form and seeing thousand submissions to that contact is maybe a really big success for them.

It could be that you're selling products online and you're selling your favorite hat in Ireland and you want to continue to push that so how do you do that? What's an iterative process? It's in the best interest of your clients to have someone helping to maintain and make those changes. Often times, they don't have the resources in house to do that. It's critical for SEO in terms of having sustainment opportunities as well as performance. As vulnerabilities are found or as patches are created because new maintenance things or bugs are found in software, they need to be updated in the longer you let those kind of sit back, the higher risk of one, being penetrated from a security perspective, losing SEO and even performance increases.

These are all the things to think about. There is also a lot of areas that like we said, outside of your client's expertise, again, do they have the resources in house? This is really dependent on the size of their team and it could be things as simple as publishing content to even again, the performance monitoring and what's the health of the site look like. Having a partner to manage these things centralizes all of those efforts into one area. You have resources that are centralized and one point of contact kind of go do these things. It becomes something very easy for them to manage. Again risk management is important and consistent security monitoring and protection is essential to lowering the risk for ... all around and that's for any website out there.

Ultimately, as this opportunity start to rise, you always got to remember expectations so you should be setting the foundation not just to your clients but also in terms it's you, in terms of what you're willing to offer, okay. Are you willing to work 24 hours around the clock? Is that something that you can even support? What are the work hours for your team? In a case of an emergency, where you get into this position where you have a service level agreement with some of your clients, how do you support that? What are you willing to do? What can you sustain? What can you charge for? Does it make sense to have multiple tiers?

This is an opportunity for you to think about those things? What are service level agreements? All right, so service level agreements are some type of agreement with your client in terms of time to answer and resolve issues. For example, they may have a security alert that comes into their dashboard and they alert you that this came through. From the moment of alert, if they have some type of formalized service level agreement with you, they tell you ... In that agreement you both agreed to charge a certain amount for let's say your response within three hours. Within those three hours, you need to respond or else you get some kind of fine or something like that. Then, you have a certain amount of time to go ahead and mitigate that issue.

This is all contractually formalized so you have an agreement on that. There is an opportunity there to make something that your clients obviously will value but ultimately will give you a revenue stream. Offering reports. Can you offer reports and something that communicates what you're doing to them. This is value added, puts it in your face. What are you doing daily, weekly, monthly? This is something of value that now, they can see that there is efforts and things happening on their site consistently, okay. This all really relates into the maintenance and sustainment side of things which I think we often miss the ball.

"Hey, look, we're up online," and that's great. Again, that's when the life of the site starts and if you're not taking that opportunity and sending them off they're going to find someone to do it, whether it's someone in house or another service. They will find somebody to come and manage these things for them. More often now, we find that the folks putting these sites up, don't want to deal with it. They just want it done. There is three kind of areas that I like to consider when I'm thinking about maintenance and sustainment is, one, what's that audience look like? Who can I support?

What are those services and we talked a little bit at a high level about it. What are those services that I can offer, our team could offer these clients or these audience and really, how and when do I think about introducing these services to them. If they're existing clients, where do I go and what have you? I think when we think about the opportunity there, those three areas are really important and we also got to consider the size of the potential audience. It's ridiculous, it's super, super big and it's a super great time to be in agency space or a service provider because it's a continually growing effort in terms of the internet and amount of websites out there.

In fact, as of this week, it's recorded that we have over 1.1 billion active websites on the internet today. That is just an astronomical number when you start to think about that. Certainly some drop off everyday, some are not attainable portion of this audience that you can reach but that's still a pretty significant number and the potential audience is still pretty large or a large subset of that number. When we start to think about how that's broken down, the biggest effort or I think the biggest opportunity for any provider out that are thinking about maintenance and sustainment and offering security services, is really around content management systems.

I say that because they have a lot of moving parts. They've got third party integrations, they've got content. They've got the course offer that gets integrated. They sit on a platform or a stack of servers and networking tools and other software. They provide a level of necessary maintenance and administration. When you think about all the active 1.1 billion websites out there, about 33% of those are powered by some form of content management system, open or closed, okay. That is a pretty big number and it gives you, I think some context as to the potential market that you can introduce your services to.

Dividing that even further, 73% of that 33% are powered by four main platforms, okay. Drupal, WordPress, Magento and Joomla. What do those have in common? Pretty interesting to know, they're all open source and when you think about all those content management systems which is roughly what, 350 million active websites out there today, 80% of those are all open source content management systems. About 65% of them in total are WordPress driven websites. WordPress today drives 25% of all active websites on the internet, to give you some context. Yeah, open source, 73% of that 33% are driven by four platforms, Drupal, WordPress, Magento and Joomla.

Now, that you get a better idea of kind of where your opportunity lies there in terms of the grand scheme of things, who can you support? What makes sense for you? You've got this awesome user base, maybe you have a bunch of existing clients now that you've done projects for. What's stopping you from reaching back to them and offering them some type of sustainment opportunities so that you can engage with them, rebuild or continue that relationship and take some of the load off of them, okay? New clients that you're onboarding so that's kind of twofold. One, that maybe that you're onboarding for a project.

Then we'll get into kind of talking about some of those maintenance and sustainment, security things that you could offer them as you're onboarding them or maybe you're looking for clients that only, only need maintenance and sustainment. Maybe they've already got a website or websites and you can become that partner for them to do that. I think that's an interesting model as well that can help supplement just your project engagements. Last, I think the big one that often is overlooked is talking to your peers. There is a lot of companies out there. They just frankly don't want to touch maintenance and sustainment, they just don't want to do it.

I think it's a challenging business move for them because it gives them some opportunity but for various reasons, they just maybe don't want to do that so why leave it out there for someone else to get? Partner up with your peers and offer them and their clients, maintenance and sustainment. Maybe even some light label service opportunities that can arise, some type of profit sharing abilities so good to consider. Often, play to your strengths or bring in folks that are strong in certain areas. I hate for people to limit themselves when there is opportunities out there to partner with folks to bring in services.

For example, what can you offer, well, we talked a bit about it and kind of the easy sells. Search engine optimization, SEO, SEM type of capabilities is something that's highly sought after and something that you keep building in your maintenance and sustainment plan. If it's something that you're not familiar with, look at their party services out there that you can integrate and that you can work with to provide that to your clients. Often times a site is turned over and this is going to vary based on the requirements of the project and typically you see this in smaller websites or websites being developed with smaller budget.

It's the lack of education and training that goes into managing and sustaining that website. Really introducing kind of the theory and thoughts around how you should reduce risk with security and making sure that you have a great security posture. Offer education, education services are something that are really important and I've seen some organizations build this as a complete revenue stream, even away from just maintenance and sustainment. They go out and educate firms and their web units or organizations on how to use certain platforms or how to manage them and maintain them and such.

That's our opportunity. Now, these kind of next two areas, when I talk about software updates and uptime monitoring, I separately noted them here but I think that those are really important part of security and I think they're important part of security for a couple of reasons but when you think about software updates, that's a huge challenge and we'll get into some of the details there. It's a huge challenge, it cost a lot of problems for a lot of people overtime, not maintaining software updates. I think that's an imperative thing to get done and although we see some great efforts from a lot of the content management system authors and other platform authors out there to automate updates at least with, for point releases which helps out a lot.

It kind of decrease that risk for, but it's still an ongoing issue and something that you can help support. Uptime monitoring is another one, right and I think it's an important part of security and I classify it there because it talks about availability which is one of the legs of security. If the site is down, well that's a security problem. It's down and no one can reach it, it's dead in the water. It's important to get it back up. I like to bundle that with security. Security certainly, and it's what kind of we're talking today because I think it's probably one of the most intricate parts to making sure websites and a company's reputation is maintained.

That you're protecting those that are coming to engage with you online, it's something that everybody should be taking about in terms of managing and maintaining websites. Two big parts of that is the security monitoring, alerting, making sure that we understand that, "Hey, if some type of security anomaly happens, I'm going to be notified of that so I can take action. I could deploy an incident response team or some type of remediation process to fix that." More importantly on the more proactive side of things, offering security protection services with some type of web application firewall.

Something at the perimeter to check on traffic, that's coming in to a website to really block and forward any potential attacks or bad traffic coming into your network and coming into your environment and only letting the good stuff. These are opportunities that you can engage your clients with to help protect them and their investments. We talked a little bit about SLAs. A lot of these can lead to service level agreements there and another really cool kind of area that I think is interesting beyond all of these services you can use to help maintain a client is also on that iterative side.

You could build these into an hourly retainer type opportunities into these engagements where you say, "Hey, I'll give you, for XYZ amount of dollars, I'll give you five, 10, 20 hours of development time a month to help you do new landing pages. Help you with, it could be education efforts. It could be creating a new plug in." Whatever the case maybe but now you have development and design hours built into this maintenance and sustainment agreement where beyond just the administration of stuff, you're helping them expand and tweak those necessary things to iterate on the site to really kind of push the needle towards return on investment. Another grand opportunity, I think.

Why security? This is for me, I think it's an important education and awareness play but before we get into the whole security piece, I want to talk to you about when you introduce this service. This is a no brainer, you should be introducing this from the first engagement. It's never too early to talk about maintenance and sustainment. It's never too early to talk about security in a relationship. I think it's something that you need to evangelize through the entire lifecycle. From the initial engagement through hand off, after build, right? You have the chance to socialize security and how you can help sustain your client's site.

What I found works is talking through the entire lifecycle, beginning to end. The initial discussions are probably one of the most important ones. For example, you have an initial discovery call to talk about high level, about what they want. This is a great opportunity to talk about your lifecycle. Here is how we break things down. We're going to formalize this then we're going to get into design and discovery. We're going to get into design and discovery and we're going to develop and design everything then we're going to deploy it, after extensive testing, QA stuff, right, but we want to make sure that we are your partner beyond that.

We offer maintenance and sustainment. We offer security services. These are some of those things that we offer for you. You're setting expectations, from the beginning and recommending the long term as responsible partners, not just dropping them off when the project is complete. It really gets your clients thinking about all these moving parts, it makes your job of adding maintenance and sustainment later in the contract a bit easier to talk about. Okay. The security piece, security to me, it has overlap of course, with maintenance and sustainment for obvious reasons, like it's typically included with maintenance and sustainment in a lot of efforts, right?

Updates and performance. Site availability, we just talked about it, it can be included as part of these security services. I encourage agencies to make security requirement and a security plan, add a security plan as part of the project architecture. During the build, formalize your requirements and the client's requirements. Make sure that you're really talking about these things. What are the security controls in place to protect the entire stack, not just the application or the actual website that you're building. Who has access to what and when during the project and after. Who's responsible for each area of security during and after the build.

Make hosting recommendations. "Holy cow, the site is going to live there." They don't have something in place. You really need to think about these things with them and the items that you should be considering around hosting. What are the security controls in place there? Educate the importance of where the site is developed and where it will be in production but I also think it's important to think about security as a stand alone thing. It needs to be at every phase of the project, not just in maintenance and sustainment. When you introduce the concept and how you can help your client manage their website security, talk about the entire life of the site, from the very beginning.

Again, I'm saying it ad nauseam but it's beginning to end. It's strategic and beginning to end. Now, that you've recommended it from the job include the language around that in your proposals. Without including that there, one, it gives you another opportunity to socialize the concept, which again, makes it easier every time but now, they're seeing it in writing. They could come back to this, they can share it. I personally like adding a whole section, talking about my recommendations, be on the build, into my proposals and why it's super important. I also like noting that security is important not just during the build again, but through the whole life of the site.

I usually add pricing as well as services around security, maintenance and sustainment into my initial agreement. It's a line item or sets of line items that include each area that I think, that's important for them to be considering, beyond how, describe it into actual proposal. This gives them the opportunity to really see what that cost is to them and how they could break that down from a business perspective within that contract, within that project and over a sustainment period, okay. They may want to remove it. I've seen it where they go, "You know what, let's think about this," but now it's introduced again, they've got a good gauge and you can continue to socialize that through the life cycle.

I'll split it into different areas like security monitoring and alerting, even down into the protective measures we talked about, web application firewalls and what that takes, application tools, right, what type of plug ins. I mean, one of the things that we at Sucuri really are adamant about is defense in depth. No one single solution is going to give you ... even multiple solution is going to give you 100% security but you got to do everything possible to reduce risk and by layering your security and using defense in depth, you can do that. It's a myriad of items and breaking down pricing inside of these proposals is super helpful.

The last one is the remediation incident response which of course, we don't want people to get infected with malware or serve Viagras if you will but it happens and what happens in that event? Well, you give them that opportunity to understand that they have course of action. You're being a responsible party by letting them know this. Whether they end up taking it with you or not, they've got some awareness of some of the things they need to be thinking about. We talked a bit about vulnerabilities and patching and it's still a major issue. Again, probably releases in a lot of software is generally being updated automatically which is exciting but it's still an absolute problem.

Upgrades and updates are generally ineffective, okay. What I mean by that, it's not new news to us and it's not because it don't work. It's because nine times out of 10 they'll get done. That is an opportunity for you to help people. For you to help your clients. Question for me becomes, why is this the case? What are the challenges contributing to this? Okay. We kind of took a look at this study from Northbridge in which they analyze a bunch of different organizations and how they work with open source technologies specifically. Again, we started talking about the potential market for you and you look at what went well building websites.

You look at those using content management systems then you look at those using open source content management system. You have a big opportunities specially when it comes to the patch and vulnerability management side of security. Exploitation of software vulnerabilities is the leading cause of website compromises, okay. We need to do better as stewards and educators and thus making our clients aware that there is ways for them to remediate or minimize this risk. Companies out there today, 33% of them in fact have no process for identifying tracking, remediating known open source vulnerabilities.

That's a pretty big number when you start thinking the grand scheme of things, the amount of websites using open source software, okay. Again, these are numbers for you to start considering about, how you can help your clients and opportunity for you. Of active websites, 47% of those same companies, didn't even know what open source technologies they were responsible for tracking. How are you managing your risk if you don't know what website is going on. This goes back to the story of the issues that we ran into when I was in the agency space. They didn't know that they had all this stuff and it was outdated in their environment.

All of a sudden, we get this really high value website launch for them because they're going into a product release event and it gets completely infected and they're playing techno music, right. Awesome, not awesome, right, that's a problem and it's because they didn't understand what they were really dealing with there, right? They didn't know what open source code or what code they had on their server at all. At the end of the day, the challenge is again, around the resources that they really have in house. Fifty percent of the companies had no one responsible for these open source vulnerabilities and patching them or doing this work.

Think about that for a moment, right. Where does that affect you and where does that affect your clients today? Do they have people taking care of their software in this capacity? Do they have people identifying or remediating vulnerabilities in their code? Maybe, maybe not but that's something that you should be considering, okay. At the end of the day, what we need to be understanding of is that security is not just about the best tool you find, deploy or configure. That is probably one, I think is the misnomers. One, not tying that back into your business case. Hey, WordPress sounds good or Drupal sounds good, that's good.

What is the goal you're trying to accomplish? What is the business impact, if security becomes an issue for you or the site doesn't do what you needed to do? Build a business case or have them, help them build a business case. Figure out the requirements to fulfill that business case and then build technology into that. Now, that's a process and you're getting people involved. Perhaps the biggest reason, I can find as to why these problems exist is because of a fundamental lack of understanding of security, okay. 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.

Okay. It's past the technology. Well, let's really think about our behavior there. There is an over-emphasis on finding the latest tool to satisfy a check box in most cases. Unless I'm trying to understand what that tool is meant to solve or more importantly, how that aligns with your specific security objective. Security really needs to be much more than a tool, configuration. It's certainly a mindset and it's certainly a process, right? Continuous process in fact, it's never going to be a static state. It's built on three pillars, security sits on the foundation of people, process and technology.

Neither meant to exist on their own, okay but they all work in unison. They need to work collectively in this circular motion of connectivity. Deploying only the technology without having a process in place for the people to manage it, look, you're just looking to fail from the beginning. Really think about the constructs of this chart here, where we start talking about people, process and technology and how in marriage they work together to really give you a solid and secure foundation. Here is a couple of ... I wasn't really going to bring this up but I want to because it's something that comes up often and you've probably heard it as a service provider.

Well look, you're building this website, for me, it's a cupcake website or it's this awesome website that does a lot of cool stuff but I'm only selling like 20 products, I'm not a target. No one is going to mess with me, it's not that big of deal and that is just a really challenging oversight on that person. That is not something that happens because look, zero one percent right, 0.001 percent of all tax today are actually targeted. Certainly they happen, everybody is targeting, Donald Trump for example, right now and there is a bunch of different things you see online. You've seen some large breaches for some of the major retail stores and stuff out there over the last few years.

Yes, there are targeted tax but 99.99% of them are opportunities to be taxed. They are automated. They don't have a specific target, okay. It's automated software going and scanning the bowels of the internet and finding and looking for specific vulnerabilities. If they see that vulnerability, they inject. All of a sudden, they have command and control. They put a backdoor on your server and they could come in and inject whatever code and take control of your site. We've seen that recently with internet of all things. You see all these devices, that aren't even directly connected in terms of being websites but security cameras and DVRs and things like that.

That are connected to the internet and they've got these really poor password credentials, they're being enumerated and they're being infiltrated by these larger buttons and using those devices, millions of devices to attack other websites. To attack the availability of other websites, okay. It isn't whether you're a target or not, it's whether you're connected to the internet or not and you've done the right things to reduce risk. Attacks of opportunity, that's where we're at in this day and age of the internet and security. Everybody is a target. A lot of different attack vectors that are abused.

I think that we need to think about the three different types of attacks. Your clients seem to be thinking about the three different types of attack. External, internal, and reflective. Now, external attacks are those, we're probably most familiar with. An attack exploit or exploits of vulnerability, remotely. The SQLI, RCE type of vulnerabilities and attacks, while internal attack might refer to the concept of cross-site contamination, right. We saw, in my example, earlier, where you have this lateral movement. One website is infected, there is bunch of directories, all of them are nailed now and that's a challenge.

The third one is reflective attacks and that's probably not exactly the most appropriate name, right but that's what we're using to describe it today. Think about attacks that are able to abuse your website resources without compromising it per say. Think about malvertising or abusing a third party integration like jQuery. Think about your domain names server services. Your DNS services, maybe that's infiltrated and all of a sudden, your DNS is changed and all of a sudden, when people go to your address, it's going to some other sites. These things happen, there is a lot of different attacks. The risk are there and we need to do our best to mitigate them.

Actions and objective, it's various reasons. Again, these IOT attacks, where we want to take down availability of sites, we're making the Spotnet and Distributed Denial of Service attacks to malware distribution, all of sudden those Viagra ads, spam email. Even on the e-commerce site, you see stuff like the payment page is being cloaked. All of a sudden, you're on a third party website, you don't realize it, it looks exactly like the vendor you were purchasing from. Now, you're putting your credentials into some other site like these things happen. At the end of the day, we got to realize that the percentage of risk will never be zero, okay.

It's a continuous process and we need to clearly define our scope. Understanding that clearly identifying your risk tolerance and your client's risk tolerance will help you prioritize the security activities for yourself as well as what you could provide with your clients. They can't do everything and either can you so you need to figure out what's the most important and in many cases, if you're not prioritizing that, nothing is obtainable. Last, I think the value that we lose or the ... Well, value that we gain from security, the value that we lose by not being secure is twofold or in two different, I think distinct areas, right. There is impacts to your organization from a technical perspective and business.

From a business perspective, you can see a loss in brand equity. What happened to Target and all these other companies when they were nailed. That's a big brand hit. Do you trust using your credit cards there? Certainly they've mitigated those risk, they've implemented controls but that's a challenge that people run into. There is economic loss. If your e-commerce site is now distributing malware or stealing credit card credentials, you're probably going to lose some cash there, right? From a business perspective, you're going to be distress emotionally, it's going to be impacting and you certainly have a liability.

When it comes to standards like PCI and things like that, that you might be working with, with your clients, as you're setting up these e-commerce sites for them for example, they've got requirements they got to meet from the payment card industry, from the card companies. If there is a loss of personal and private information or payment card information, they can seek fines of thousands and thousand dollars a day, per month. They could be blacklisted altogether and all of sudden, now, they can't process Visa cards on the website, right. There is things to consider there from a business perspective and you need to be making the clients aware.

From a technical perspective, sites can be blacklisted, that ties back into your brand and economic loss. Again, SEO impacts, you get these search engine attacks where all of a sudden, people are searching for your site and Viagra ads and links and stuff are popping up. That's bad news. You don't want that association. A big one again, with the PCI space is a visitor compromise. Their credential, their information is stolen. What if they start serving malware and all of a sudden, it's a whole debacle of drama. A lot of things you could do. I won't get into too much in terms of the Cloud-based security technologies.

One thing that we are super hip on again defense in depth, having those application level tools and controls in place, like plug ins and things of that nature. There is also something on the edge, like a cloud-based security technology that offers web application, firewalls, intrusion prevention system. Everybody should be thinking proactively at the edge. You should be thinking about this and really socializing this with your clients. I mentioned defense in depth a bit. Again that's a layered approach to proactive and reactive website security but layers. Think of the onion, you're peeling the layers back.

You should always have some opportunity to provide response to your clients. We offer professional response from a security perspective but if you're there and you have your service level agreements with them, this could be something that you're on point for and you could capitalize on. At the end of the day, being proactive and offering some type of protective layer and again, the monitoring with some type of alerting capability with detection, continuous website security monitoring is something that's important to really identify or figure out indicators of compromise quickly and then take action on those.

I know I went long, the recap is pretty quick. We talked about setting expectations, beginning to end. You need to be very transparent and communicate with your client around what you can and can't do, what you're willing to do, what your expectations are around them, that's going to lead you to a successful relationship. The foundation to that or maybe the framework is establishing some type of project life cycle, beginning to end. What that means, help them understand what each phase is and how those requirements work and what happens next after approvals. Always be thinking beyond the project because that's really where the life of the website starts, right.

I think that you have the opportunity to do that by building some type of maintenance and sustainment opportunity into that lifecycle, become long term partners with your clients. Offer this as part of your long term solution to your client, offer the assurance of monitoring and protection to their investment. It's going to go a long way. Make sure to document what the offering is, what services you offer, how they'll be offered, how long they'll be offered. I mean, this is all pretty basic stuff in terms of how you want to formalize this but what make sense for my agency or the next, it may not make sense for you so make sure that you're tying it into your business model.

Again, what's that communication mechanism for your clients to request assistance? You always want to make sure you have that open line of communication with you and any third party services you've build in. Building a service level agreements, that's something that you can nurture and build into a revenue stream of its own with your clients and it's I think important specially when you start getting into the bigger businesses. Offering security is awesome and I think it's going to help you ... the level of trust that you build with your clients and certainly will help them reduce their risk for long time. It's an on going process beginning to end.

They can't just think about it, set it and forget it. It needs to be iterative. Defense in depth, we talked about it. I said it's a blew in the face and that will continue to be because I think it's certainly an important part to helping establish good security principles for any organization. That is it in a nutshell and I am open to questions and answers.

Questions & Answers

Question #1: Thank you Dre. We've had a lot of questions. We've got a little bit of time that we can get to a couple of them. One question that came up was, when working with outside developers, what type of security practices should be in place to protect us as an agency?

Answer: That is an outstanding question. Hopefully, you have resources internally that have some means to understand the code that's being written and that it's meeting standard. Make a requirement around whatever platform you're using or whatever language is being used that's using best practices to sanitize, to escape. Basically, stick into best practices for that platform or that language. Use some type of code repository. Whether it's ... you're using some management tool like Git or Mercurial, whatever the case. Have some way to manage that so it could all be reviewed, time stamped and associated to whoever is developing it. I think those are probably the two core principles that I would stick to in terms of reducing risk from a code, purely just writing code perspective.

Question #2: All right. Next question. There has been a couple of questions actually around the topic of working with smaller clients who don't really touch their sites. These agencies and designers are kind of helping to do the updates for them with the software and the content but how would you best approach, dealing with small customers about cost? They're very nitpicky. Is it best to offer them a package. It is best to offer them kind of an a la carte per the thing that they're doing. If there is a security problem and they need to get it fixed then they're expecting this agency to handle it, but they think it should be included but it wasn't.

How do we deal with those ... getting those kind of small site, small customers that don't really understand and haven't really been prepared for the incremental cost that come up with the maintenance?

Answer: If they're not prepared for it by the end of the project then I would argue that the service provider or that agency is failing to again, set expectation and to educate their client from the beginning. One, you lose the opportunity or you're minimizing your opportunity but two, and most importantly, is that you're not educating them what to expect in the short term, at the build, when it goes into production and long term. Okay, that's really on how you approach that from the beginning. Certainly there is going to be cost there. Certainly, it's going to be cost prohibited for some folks to do that and that's the reality of it.

You're not going to turn every client into a long term maintenance and sustainment. I think being up front about that from the beginning and talking about, "Hey, this is what a life cycle looks like on a website," so we go into the build and now it's live. That's like the beginning of it. Awesome. Now, we have this whole sustainment cycle and these are the things that you need to do or one, you're going to end up high risk of having infections, losing performance, dropping SEO, not having educated people to take care of your site. My recommendation is that you look at implementing these things as part of maintenance and sustainment with us, long term.

Here is how that breaks down. Here is how we prioritize these things and we think that security is a really, really important one. Making sure that everything updated is an important one. You can break it down based on the client. Again, based on your model, it's going to dictate whether you break that down into consumable cost, right, and these are just kind of different entities or line items that we could take care of. That granularity gives a good breakdown of what is and isn't included or you could package that up if you think it's a consumable cost point for that client.

I would argue though that you lose the opportunity to educate them on the importance of that if you just group it and don't give them a good breakdown of what those services are that are included and what's not, right. Just like form field validation and we get a use case, for like, "Hey, they should be doing this." There should be a misuse case too, right? You want form fields to do one function, not others. Make sure that you're really educating them on the things that aren't included. If you're willing to include those things, educate them on what that cost is, what that takes from a resource perspective or shoot them to a third party, if it's something you don't want to cover.

Question #3: All right, I'm going to ask one last question for you and I'll ask it two parts. As an agency that uses third party companies for hosting, security monitoring, should clients go directly through the agency to ask questions that are related to that provider or directly to that provider? The second part, well, in conjunction with that is, how do they explain to their customer that this is our third party provider and it what instances is that ... Is that always the best practice or is it case by case?

Answer: That's a challenging question to add because every agency and every relationship that they build with their client is going to be potentially different. I work in a capacity where we white list all of our third party stuff and we offer an all inclusive plan like years of the maintenance stuff and security things and after build items that we offer. We handle that relationship with your client. We're the intermediary to the third parties. The relationship is something that we build for them, the third party. Now, in other situations where it's direct, again, it's setting expectations and having all this documented upfront.

For example, you have the opportunity to build in a third party security stuff and you want to tell them you're using Sucuri. Great, have that discussion with them. Set the expectations there. We're going to handle that relationship for you. We are using this service because they're amazing but we're going to do all the heavy lifting for you. We are your provider. We're going to bring this service in as part of that maintenance solution for you. Really, it just depends on how they want to handle that relationship or if they want to off load it. Again, it's just documenting what that flow is going to be from the beginning so when the client gets involved and they go, "Yes, I agree to this," they know what they're agreeing to.