 So I'm Rachel Friesen with the Drupal Association, I just wanted to thank everyone for coming out to Drupalcon and to our session this afternoon You've got four great speakers ahead of you. So I will go ahead and turn the floor over so you guys can get to the good stuff. Welcome everyone, I'm gonna, I guess I'll talk a little closer to the mic, make sure everyone can hear me. I know it's after lunch, the last last day at Drupalcon, so I'll speak loudly and keep everyone awake hopefully. I'm gonna talk to you real quickly about how a .NET organization selected an open source CNS, a .NET organization that had a lot of .NET experience and zero PHP or open source experience. So here's some quick information about myself, we do have a booth downstairs available. Obviously there's probably not going to be a lot of time for questions after this but you can grab me afterwards or you can grab me at the booth or send us a note. So, I'm just missing a slide. So what I'm going to talk to you about, actually, why is it missing a slide? Anyways, okay, so we're going to go through Rotary's background, give you an idea of what they are, what they were doing as far as a technology part of their organization. You know, go through the list of things that you're going to go through normally. You go through a CNS short list, you want to identify a few group of vendors that you're going to go talk to. Then you want to have them do some vendor demos. What happened for us is that those vendor demos weren't very specific to the needs of Rotary. So what we had to do was do a lot of internal demos, have development teams internally set up the POCs. And then of course the outcome, which is pretty obvious since I wouldn't be doing this at Drupal Con if they didn't select Drupal. Northpoint, I just want to give you a quick introduction. We're based in New York. We have an office in Boston and Philly. And I want to go through some quick stats also just to set some context of how we go about these types of engagements. So if you go out to, you know, go to get a, you know, an Accenture or someone like that, they're going to give you a bunch of stats, they're going to probably give you a recommendation, but it's all going to be based on, you know, external information about these systems. If you go with a company like Northpoint, we actually implement these systems. We have a lot of experience, you know, nine years of average. I have over 16 years of experience. Anyone engaging in something like this is going to have my level of experience doing these. And the experience actually implementing the systems and actually building out websites on these platforms, not just reading about them. Digital Clarity Group is an organization that's starting to really identify implementation providers out there. And one of the things that they said about us is that we actually have the most diverse range of all the vendors that they looked at. And that's because my part of the organization deals only in open source, but we have a .NET part of our organization as well as a Java part of our organization. So technologies and infrastructures that we deal with are very broad. So engagement like Rotaries where they're doing .NET selection, they're a .NET organization, I can bring in .NET individuals that have experience on those CMSs outside of my group. So I want to get into the presentation about Rotary. So Rotary, as you might have read the intro part of what I'm going to talk about, they were on SharePoint, SharePoint 2007. It was quite a poorly implemented SharePoint version, as with most installations back at that point. It was built to display a website. And what happened was Rotary continued to build onto it over the course of about 10 years of custom .NET applications. So there was actually a lot of ASP in the beginning. So ASP, they had C-sharp .NET applications pulling out data from SharePoint, pulling out data from custom or even Oracle databases all over the place. So this group of individuals they had trained, built up over the course of many years, had a lot of experience in .NET and in Microsoft products. So their only PHP experience, and I should probably put PHP in quotes because it was WordPress. And I'm not going to say that because WordPress is a bad, I'm saying it because their experience with WordPress was actually WordPress.com. They happen to have a blog and happen to be on WordPress. So it was actually kind of the way into an organization like this because they kind of started investigating open source and investigating what PHP CMSs were out there. So when we came in, we actually came in with a bigger branding partner. Not because we're great at open source or great at specifically Drupal, but because we have experience doing technology. I was able to actually talk to them about Drupal as well. So we came up with a CMS shortlist. Our .NET team, we went back and forth with all the requirements and really we came down to the top two that we use a lot of times, which is Ektron and Sitecore. Both of these are proprietary systems. You have to pay for them, but they add a lot of functionality that a website would need, and especially a .NET organization that is already building in these languages. Of course, we added Drupal into the mix. And we wanted to talk to them about WordPress as well. At that time, WordPress is changing very fast. And at that time, it didn't have some of the features that even it has today. So within a year, it could have been kind of an equal comparison. But we really wanted to focus on Drupal and Ektron and Sitecore. So those were really the three in the shortlist. And by the way, there was no SharePoint. This implementation was so poor that no one in the organization would have ever accepted SharePoint being selected, no matter how good of a score it might have had. So we really didn't look at SharePoint at all. So what I talked about before, we did some vendor demos. Those vendor demos, the first round, North Point, we engaged with each one of the vendors. We actually have partnerships with each one of them. So we got to talk to them about the requirements, kind of letting them know exactly what they should be presenting. Ektron and Sitecore obviously have companies and have people that can do the demos. Drupal, not so much. We wanted it to be independent. So while we could have demoed Drupal, we wanted to bring someone outside. So we actually had Aquia come in and do a demo. And then fortunately, all three demos were really canned demos. They gave some baseline functionality of each one of them and really didn't give them a whole lot of information about any one of them. So what happened was we were still able to kind of narrow it down a little bit. So Ektron is a bit more of a simpler interface. They liked that in the admin. So they went with Ektron over Sitecore. And of course, they wanted to maintain the... and we wanted them to maintain an open source alternative. So we kept Drupal on the list as well. So the second round, we're all done on site. Everyone came out. Ektron came out one day. We actually went out and wrote a reason in Chicago. So we all went out to Chicago. Full day of demos of Ektron. Full day of demos with Drupal essentially, with Aquia coming in. And they ended up doing almost the same demos again. So unfortunately, the organization really didn't get a good idea of what each system could actually do. So what we had to do was actually get a third round of internal demos. And what we did was we had Ektron give them a license, install it, give them a little bit of training material, and let their .NET developers build out some POC functionality. And what I did was I built out the same POC functionality in Drupal. And if you're familiar with Drupal, the POC that we did was some integration with some of their back-end systems. The back-end systems that had web services. So what I did was I basically used views. I wrote about 20 lines of custom code to link views into a back-end service. And then, voila, they had an admin for configuring views. They could rearrange things. They could sort them. They could define it as 10 in a list, one in a list. They could create yet more web services if they wanted to. And that was all done in a few hours. Their .NET team took over two weeks to build out. Mainly because I had experience with Drupal, they did not have experience with Ektron. So that was something that they looked at, but there really wasn't a win-lose for either one of them. The next thing we looked at, and we were evaluating kind of all at the same time over this two-week period, we looked at development workflows. They had been developing for a number of years, doing a specific type of workflow where they kind of build everything and then deploy it and then go. And there's no branching or anything like that. So we introduced, obviously, with Git and the ability to do pull requests and forking your codes to proper development workflows for what we considered. They're a large team. They had about 12 individuals doing development on all these different systems. So, again, neither one of them was any better. These are all kind of outside things that you can do with any system. And then staging and deployment. They felt like they needed a staging server. So if you're familiar at all with staging servers, it's the idea that you can build all your content, deploy your code to an environment, and then move it over. There's a lot of talk around that, around Drupal 8, about separating the configuration and code in Drupal 7. We don't really have that. We have it in some ways. But products like Ectron and other proprietary systems actually have tools that allow them to deploy code, deploy configuration, or deploy content from staging servers. However, as I talked them through it, what we can do in Drupal is provide workflows and using the Workbench module to allow them to do all this content creation, go through a workflow of editing, and no one can see it live, approval. No one still sees it live, and then you eventually publish it in complicated workflows if they needed it. So we kind of set the field a little bit level there. And then we evaluated upgrade paths. If you listen to either one of the marketing groups or whether it's someone talking about Drupal and they really want to push it or someone talking about Ectron, oh, yeah, it's not that big of a deal. You kind of do the upgrade path and it'll upgrade all your content. The reality is no system is that easy. You're not just clicking a button. You're not just downloading the next version of Drupal and upgrading and crossing your fingers. It just doesn't work that way. Same thing with Ectron. I mean, Ectron does the vendors do a better job at the upgrade path and they do support it, but there's always deprecated functionality that eventually gets dropped. Sometimes it's documented, sometimes it's not. So the reality is they both have some pitfalls there. And then we talk about pricing, right? You're going to write a check. To get Ectron, to get it in the door to install it, you're going to write a check. It's a fairly large check, not massive. Ectron's not actually a very expensive CMS, but it is a check. And then you're talking about free as kittens, obviously, because you will be paying for things. You're going to pay for... You install Drupal, that takes time. Just downloading it. You install modules, that takes time. Whether you're working with an organization like this, us, or you're doing it yourself, there's still time is money. So you are paying for certain things. With Ectron, you know, a proprietary system, you actually just install it and go and watch the wizard essentially go through and then you have a CMS up and running. That's just not the case with Drupal. However, in this case, while it would have been slightly more expensive to go with Ectron, if you really look at all the numbers, it wasn't a big enough differentiator. So you go down this list, and essentially everything is looking very equal. And I was kind of assuming at one point that they were going to go with Ectron, because if you think about everything's equal, they've got these 12 developers that have been trained in Donet. Why would you pick an open source technology? But the outcome was Drupal, and the main reason was during this process we were really talking to them about what's available in Drupal. It's not just about the code, it was actually about it's a community of individuals contributing to a project, contributing to something to make something better. And Rotary International is the exact same thing. They are a group of individuals contributing money, contributing their time and resources to better things, better community things, better the world, eradicate polio. And they felt as an organization that it was a very close match to what they were doing. And it's not something I really thought about before that. And then as we started looking at other non-profit organizations that we do business with, it's actually a very close match to them as well. They're all doing kind of the same type of thing. So in the end they did pick Drupal. It wasn't because it's free. It wasn't because you can do development fast. It definitely wasn't because it was an internal application. We find that a lot of times where they're doing a lot of PHP and Drupal is an easy solution. They actually had to make a big decision to then cross train all their individual, all their developers, hopefully not lose any in the process and also grow because the functionality that we were providing in the future was going to be much bigger. So Rotary.org grew from basically a marketing site to now a marketing site with member access and it's translated in nine languages. Every line of text is actually translated by their staff. So user interface pieces, sort, up or down, all pieces of text were translated. So they had to do a lot of development in partnership with us to get to the final output. I'm kind of surprised. I went through a little fast. I do have some time, probably a couple of minutes if you have some questions. Also, if you wanted to grab me afterwards or go to our booth, but you can reach out to me here. We do have three offices if you are local to the Northeast, but we do a lot of work. Rotary was out in Chicago. We had no problem supporting them from our office. If you have any questions, let me know or I'll pass it over so you can get set up. Okay. Great. We're good. Hi. My name is Jeff Schreiner. I work with Imagex Media. We're based out of Vancouver, British Columbia. I work remotely based out of DC. We do a lot of work within higher education. Today I want to talk about documentation, something near and dear to my heart, something that I feel like. Oftentimes with our developer team, we use a scrum methodology and agile approach and documentation is something that gets left either to the last minute or not addressed at all. So we've taken a very, made documentation central to our discovery process and throughout the course of development. So I want to make the case for documentation today and overview of the kind of documents that we would produce during a project. Now, some context here. My title at Imagex is Solutions Architect. And that's been a point of contention with this woman, my wife, who is a real architect. And she actually can't call herself an architect. She's still completing her. She's on exam four of seven for professional licensing. And yet in our industry, I can willy-nilly call myself an architect. But there is, I think, a case to be made that there are some parallels here. So architecture, what makes good architecture in his book, Day Architectura, Marcus Vitruvius Poglio, describes three aspects of good architecture. It is firmatis, that it should stand up robustly and remain in good condition. We want our websites to do that. We want them to be the last law and they should be safe. They should be useful and function well for people who are using it. Usability. This is central to a good website. And finally, benestasis. It should delight people. It should raise their spirits. It should be beautiful. Again, that's what we want to see in our websites as well. A little bit of history. A few more parallels here. So architecture, where did it come from? Architecture is only about 300 years old. The architecture, sorry, is ancient. The architect is only about 300 years old. We proceeded by the craftsmen. So we were working by themselves to build a house. The master builder became an expert in this. And then finally, we saw the architect role emerge. And why did this happen? Three things. Technology. About 300 years, 300, 400 years ago, we saw paper and pencil become widely spread and people can now represent their ideas in a document format. We saw standardization. We saw boards and nails having standard sizes so that people could use common approaches to a project. And we saw specialization. So unlike the master builder, we had people who were experts in certain things. We had masons and we had carpenters. People got specialized and the architect brought those people together kind of like a conductor. In web development, we had the same thing. We moved from the coder into the dreadful web master. And then the solutions architect or often we would call it too, a site builder. When we're using technology is increased. So technology is advancing. We're having access to more common standardized languages and specializations. We have your front-end developer, your DevOps person, your JavaScript expert. The architect brings that together. Now I want to make clear there are some obvious differences between architecture and web development. Longevity is a big one. Most websites aren't going to last hundreds of years. The use of scale. We don't have that same ability to really impress somebody when they walk into a cathedral. We don't have to deal with physics as much as them. We don't have to worry about injuring people. We don't have to worry about the environment other than the screen size perhaps. We can't take into consideration where somebody is going to be looking at the website. And another big difference that has often been being with the case that made is the cost of construction. But on this one here, I'd say that the cost of construction for a website is starting to parallel the cost of construction of a house. You see people spending a million dollars on a website. That would be a really nice house. And so to the architect, planning a, designing a house, their documentation is super important because they cannot go back and bug fix a building, right? They need to know that when they're starting out with their plan that they have their ducks in a row. So why the role of documentation? We consider documentation to provide a source of clarity. This is, I have a favorite quote of mine is if you can't explain it to a six-year-old you don't understand it yourself. We need to be able to translate our ideas to the client through to our documentation. Documentation is a mechanism for accountability. So our clients keep us and manage our expectations, manage our clients' expectations, make sure that we're all in the same, all talking about the same thing. Finally, documentation when done right can be a source, a site of collaboration. So instead of just me producing the documents, pushing them out, we like to, as best we can, involve our clients in that documentation process, give them ownership over that. Now, we do our process. We're not going to get into how we approach the documents that we would produce over the course of the project. Unlike architecture, every web development company seems to have their own approach. But for architect, there are five phases to a project and everybody follows that. There are specific documents that are produced at the stage of the process and I'm not advocating for a standardization of documentation or a standardization of approach within web development, but I do think that there's something that we could be learning here. So I want to compare the phases of development in architecture to that in web development and Drupal development and see what the parallels are. So the first thing that an architect is going to do is call a feasibility study. You look at the site, you're going to look at the environment around where they're building, you're going to look at how much it's going to cost, what their return is going to be for the developer, the investor, if there's a cost of rent, how many units do we need to make this profitable. Our first thing that we do to work with a client is in a similar way looking at that environment as we go through the process of creating user personas. Here is the evaluation that the site will do. We'll do an audit checklist for the usability of the site, how it's functioning, how to attend an audit report, how to take inventory of everything that's in the site to know all the materials that we're dealing with. These are personas to find who our audience are, how they interact with the site, when we start to create the tasks that users need to fill and those because of the measures of success at the end of the project, those are the things that we can test against during the QA. And finally, we'll move this together into what we call the business or environment document. So here at this stage, we're not surviving any functionality or cerebral reactions. We're not surviving any solutions. We really just want to understand what are the goals and objectives of this project, how are we going to measure our success. We really want to understand the context before we start providing any specific instruction and strategy. The next thing that architects are going to do is schematic design. We're going to start sketching out ideas coming up with a concept trying to understand the approach that they're going to take. There's no, there's no real detail. These are all the stages. These are ideas on the back of the map. Next thing that we would do to improve the building, it would be a very architectural approach. Again, we're not scribing any specific functions or ways the site will use if you would like. We just want to understand everything that we're dealing with. So taking that content out of report, the last phase, we're going to be designing how people can actually use the site and any system of integration. So how is the site going to integrate with any other party systems? Back to our architecture. What we're going to do is go into what's called design development. So taking those early concepts and drawing and starting to actually provide some detail here. And again, this is we're getting closer to orientation of the building. It's not there's no measurements on the site page. This is just how we're starting to create the idea of the client site and making sure that they can sign a sign on a form or a project. In our industry here, we're going to be testing this. This is often done through wireframe. We're going to take the wireframe response slots in the rounds. We're going to type out the site. Again, we're not inviting that little detail. We're going to wireframe the fidelity. We're going to have our conversation strategy, track the details of our fonts, color, color, and so on and so forth. We're going to have a higher information vision page start to discuss the sense of that usability as we move forward. Next phase is with architecture texture. It will start to create instruction to us. So now, the architect again can continue to level up the development. We're going to be building the measurement that we have with some hallways. And for our design industry, we're going to design. We're putting colors on. We're going to identify the fonts. And out of this, we're going to be using the system wireframe process. This is the specific slide that we're going to be building. How are we going to be building the model? We want to be sure that we can identify the fonts on the budget. So, in other general expectations there, we're moving to design a style style kind of a branding rather than a site site. But we can make that systems requirements document in the absence of designs. Designs can have an impact on how something functions and how it works. So, as we move forward, we get to that point where we get to the specificities. The final stage in an architects process is called contract administration. So, they've produced their producer construction documents. Those construction documents go off to the developer. And the next phase is the architect in communication with the contractor who's building it. Often done by fax, but they are managing that process because the contractor is going to have questions about certain details. Something I interesting is that I find very useful when I'm putting together my development plan is the difference between proprietary specifications and performance specifications. So, those are the two types of specifications that an architect will provide a contractor. The difference is a proprietary specification is a very specific instruction. So, we know that this Maytag dishwasher is 32 inches wide so we need to have the cabinet space in the counter 33 inches wide or whatever that may be. I'm probably not good at designing buildings. A performance specification is allowing the contractor to use their expertise. So, if we say that the stairs cannot be higher than 6 inches that's a standard that they have to meet but they have the ability to then interpret that and go about the best way. This is really important in web development because I cannot nor should I prescribe the best way for our developers to go about developing something. So, in creating a requirement in the systems requirements document I'm not going to say use these entity references these filters on the view I can provide a performance specification. We know that the display has to contain these things. How we go about doing that I want to leverage the expertise of whoever is developing that there. So, like contract administration we then move into development. We use JIRA at ImageX but going back to those business requirements talking to the user personas that give us the material to create the epics and user stories we created development operations plan a development plan with timelines and goals and then finally our sprint plan and milestones. That brings us through to development those are the documents that we produce I'm happy to answer any questions about that and love to talk to you afterwards. Thank you for your time. I'm really short so I'm just going to take this thing off completely. Hi, I'm Belinda I work for New Relic as an engineering manager on the PHP agent team. I've got a fairly decent background doing a bunch of web app development both as a manager and as an engineer. So what I want to talk about is what every project manager should know about web app security. There's a lot of content about there in terms of app security that is very much focused on the developer or focused on the security specialist but I found that there was very little guidance that I could get as an engineering manager or project manager to make my web apps more secure. I was ultimately being held accountable but didn't really know how to manage it as a process. So my goal for you is to get a very, very high level understanding about as a manager what kinds of things can you be doing to manage security for your project. So the first part of this is moving from being a reactive project manager to being an informed project manager when it comes to web app security. And the starting place for this, unsurprisingly is customer expectations. Most customers frankly are just going to assume that you're building something secure to begin with. They don't think of security as a feature. They don't think of it as a requirement. So you have to start those conversations about scoping security in as a requirement for the site. It's not a maintenance thing you do at the end. So you can also use it as a maintenance gathering tool. But as a PM, if you haven't done this work before, you don't feel like you're qualified to have that conversation. You don't know anything about web app security. You just know when it's broken because the customer calls you. Well, frankly, you're not going to become a security expert in your first project or even your second project. So I would tell you the place to start is really from a place from humility. Recognize that you aren't going to become an expert and realize that it's going to take some time. And you put a lot of trust in your developers and your people. But to be frank, the expertise is really rare. I mean, most of us have a very incomplete understanding of security. So as long as you take the approach of, yes, you're going to lean on your developers and your ops folks, and frankly, you're going to have to trust them to do good work. But you'll have to learn to ask better questions, right? And it comes down to having those open conversations about how well are we doing, how do we measure what we're doing, and how can I gauge my team's security foo in a way that's actually helpful. It's all about the art of being able to keep an eye on things without necessarily knowing all of the details. So there's good news in that there are some frameworks for thinking about security that while they're built for developers, there are actually things that you can use and there's some common scenarios that you can have your team focus on that'll let you deal with really the most likely risks. So I'm going to talk about threat modeling because threat modeling is ultimately the big tool in your toolbox that you're going to use as a PM. It's also the same tool that the security experts are using, but I'm going to give you the PM version of it, not the security expert version. So I'm going to try to break it down as simple as I can. So threat modeling is really the art of determining the set of possible and likely attacks or risks to your project. It sounds kind of fancy, it's totally not. The starting point is talking about what do you actually care about in your system, right? So we talk about identifying assets, right? So I'm building this thing, I'm going to have users using it, there's going to be some data like what are those things, what are those tangible things that your customers or users care about? Is it, you know, documents? Is it trade secrets? Is it images? Is it, you know, personal information, credit cards? Write all that down, right? Don't just leave it in your head and acknowledge that yes, there's important things here. Write those down because those are talking points for you and your customer to talk about security. And in the context of those assets, right? What is it risk? So what's at risk if something goes horribly, horribly wrong? Is it merely your reputation? You know, those are cheap, you can build a new one. Is it your uptime? Is it your mobile apps? Is it your commerce? Is it your revenue? Again, write all that stuff down and present it as a talking tool for your clients and for your developers. You're going to think of things from the client side of the world. Your developers are going to give you a list of stuff that you never thought about when you talk about, you know, what's at risk? And when we say risk, I mean, let's clarify, what do we mean by risk? Because that list of risks can get pretty long and very daunting. So think of risk, again, as the probability of an event happening and the impact that that event will have. You know, good example, chicken box, right? Most of us have had chicken box. Extremely likely that you're going to have chicken box in your lifetime. If you have it as a child, you know, it's not really that debilitating. If you have it as an adult, it's a different situation. So for each of the risks that you've identified, you're going to go through the same exercise of assessing, like, how likelihood is this to happen and what's the impact to me if I get it, you know, now or two years from now. So you've done that. You've got your risks. You've known your assets are. You can talk to customers. They can give you feedback. You know, what's important. You know, now we'll start talking about the system itself. So what are the boundaries of the system? And a way to think about the boundaries is, you know, where is the data from my system coming from? Where is it going to? And what is it interacting with? So we talk about, you know, trust boundaries or subsystems or data flow. But it's really, you know, where are things co-mingling with other things? So that could be, like, you know, third-party APIs. That could be modules that you're bringing in, right? Where the data co-mingles is inherently places that you'll identify risks. And then let's talk about threats. So we talked about risks, but threats are really things coming in from the outside, right? It's not just bad people hacking your system. You're actually more at risk of just bad code doing bad things to your system. It's not about intent. It's about the threat from the outside. Again, you know, I'll probably get shot for this, but, you know, Microsoft actually has some pretty helpful acronyms for, you know, identifying the various types of threats that might impact your system. And they call it, you know, stride. So these are ways of sort of, you know, mapping specific types of threats to common known threats. So the ones that are like spoofing, tampering, repudiation, info disclosure, you know, DOS, elevation of privileges. And again, it's being able to take an example of a thing that you can think of and sort of map it to a real identifier for the type of threat that it is. So now that you know these threats, these outside things that you can think of that could go horribly wrong, you're going to rate them, right? Because part of your job as a PM is to, like, help prioritize stuff. So threats, again, likelihood multiplied by impact. Really, really simple tools. This is not that different for what you use for identifying requirements. And, right, you're going to focus your energy on the upper right-hand side, the most critical or the most high, you know, issues that you're likely to run into or threats that you're likely to run into. Another Microsoft acronym. Again, this is about how do I, you know, rate a threat. And so they have a pretty interesting tool. I mean, it's a really simple bit of math. Basically, for each of these areas of a threat, I'm going to give it a score from 0 to 10, right? So if it's a really trivial threat, but it causes extreme damage and it's hard to reproduce and it's not very exploitable and it doesn't affect many users, but it's easy to discover. So I'm going to assign a score to each of those, right? So let's just pretend that when I add them up, I get to a score of 20 and then I divide that by 5. So my threat, you know, for that particular issue could be a 4. So I'm going to go through this exercise for the things that I identify as probably being the top items. And this gives me a really simple tool for identifying, okay, what is my very, very highest priority threat and, you know, which ones can I just not worry about because, frankly, we know we're not going to get to them. So you're going to prioritize. Cooking with gas now. So this is the interesting bit where, white, we have all these threats. Now what do we do about them? You know, unless you've got a security expert and staff, you're just going to start googling and you're going to test and you're going to google and you're going to test and eventually you're going to google how to fix it. You're going to try to fix it and you're going to test and that is the process. That's how you build that expertise. But so far we've only talked about the application. We haven't actually gone into the rest of the system and security isn't about just the app. It's about a whole stack. And when I talk about stack, I mean everything from the browser that our customers or users are using to the JavaScript, Drupal Core, modules, themes, PHP and I'm going to miss a bunch of stuff along the way. Again, super daunting. Threats are everywhere. But that's okay. The same tools that we just talked about for the app, those are the same tools that you can apply when talking about other threats. Some are more likely than others. Sounds really taxing, right? It's a lot of work to do this. So another way to approach it, so rather than kind of doing this inside out self-analysis of the system, you could also pull in outside resources. So if you're working on a project where you have the budget or you're building a product and people find security important enough, you can get some help from the outside. And obviously depending on how important the project is and what the risks are, you can probably scale that outside help depending on what you need. So probably the most extreme case, meaning the most expensive is to do a penetration test. So that's where you bring in somebody from the outside. They do what they call an ethical hack. They try to hack your system using a combination of automated tools as well as manual hacking. Most of the time they're going to identify a bunch of vulnerabilities. Your team's going to go fix them. So there's going to be multiple iterations. So if you do a pen test, it's not just a budget a week and it gets done. It's like budget several iterations for your team to get through multiple iterations of the pen test. These aren't cheap. We're talking 10 grand and up depending on how complicated your app is. The useful bit is that you will tend to walk away with a third party assessment of the security as well as what vulnerabilities exist. Which could be really useful for shopping your project around to other customers. If you can't afford a penetration test and many Drupal projects cannot next best thing might be to use an online scanner. That's one of those deals where you pay for a subscription. You can set it up to scan your site on a weekly or daily or monthly basis. Same thing. It's going to send you a report of the issues that it finds. Anything from unnecessary open ports or places where it's able to do SQL injection or sniff URLs, things like that. One tip, try to run those in off hours. Some of the scanners out there are very capable of doing kind of bad things to your system including slowing them down. Good scanners are going to let you customize your scans, monitor them, cancel them and reschedule them. There's lots of commercial tools out there. If you're new into security, again they're very expensive and very daunting. But there's some great ones out there. For most of us, we're probably going to head towards the open source tools first. If you go to the OWASP page which is the open web application security projects at OWASP.org they're going to point you to WebScarab and a few other tools that they help maintain. Those are great tools. There's nothing wrong with them. The thing is that they tend to be built towards developers that already understand the security requirements and that already understand security testing. If you're going to go with open source tools as your de facto solution, you're going to have to budget more time for developer training. That means either them self training and reading and testing and ramping up. Or if you can be able to pull in somebody from the outside, either a security consultant or be able to send them to external training so they can learn more. They're going to have to meet up groups and they cover a lot of the topics including how to use some of the tools. Maintenance. That thing that we say we do. Again, security is not something that can be finished when the project ships. Security is really a never ending requirement. It has to be something that you maintain through the life of your application. Frankly, it kind of comes down to ownership. The only time that you're going to see this thing is if there's a dire emergency that's causing your business to come to a crushing stop. Or you have an internal team that is accountable for security of the system on an ongoing basis. If you've got a person that is just developing apps for build a valor and jumping from project to project, sorry, security is just not going to be in the forefront of their priorities. It doesn't work that way. Again, security means maintaining a certain sense of expertise as well. You can't have your best developers build the project and then hand it off to tech support or ops people that don't know anything about security and expect them to do a good job maintaining it. If you're building multiple sites, the investment that you make in tooling is something that you can reuse over a long period of time. Spend that time, build it into your process, build it into what you do every day because you'll be able to leverage it on every project. If you're completely desperate and nobody seems to care about security and nobody wants to budget time for it, I recommend at least for Drupal doing three things. They're really simple. Set up a daily scanner or, you know, weekly scanner and use that to marshal resources because if nobody cares, guess what, you're totally going to find lots of problems. So being able to bring evidence of problems in your system is probably step one and the scanners are pretty cheap. Number two is to use the security review module in Drupal. It's pretty helpful in identifying where you've got configuration problems or where you've overexposed users to being able to have certain permissions, those kinds of things. Again, it's going to give you data points for things that you need to go and update. And number three, not surprisingly, keep Drupal core and your community modules up to date. Keeping them up to date means that you're going to bypass a lot of security problems for free and that's worth something. Again, I think the best place to learn about security is the website. I would tell you it is incredibly rich but difficult to navigate sites. So start with the top 10 risks. If you're not familiar with security, that's a great place to learn. It's also a super talking point for having those conversations with your developers because they've done the hard work of identifying what's most likely to happen in your system for you. And that's it. If anybody has any questions, I'd be more than happy to do so. If I have more time I can kind of go into some of the OASP top 10s that you will see a lot in Drupal if that's helpful. A minute and a half. Alright, we can fly through this. It'll be great. Alright, so this is not a full list of OASP so go check it out for yourself. But these are the ones that we see very frequently, so keep an eye out. SQL injection is in fact number one on the OASP list. Every module and in fact Drupal core at many, you know, back in the day. And it's not to say somebody couldn't reintroduce SQL injection issues is a very common problem. Good news is it's also easy to test for, but it is extensive to test for. Cross-site scripting is OASP number three. It's where an application can take a bit of untrusted data and actually send it to a web browser without proper escaping. This actually allows, you know, hackers to basically execute scripts against the victim's browser. And you could, you know, hijack user sessions to get things to the site or like redirect people. So you see this taken advantage a lot when, you know, people get spam, things like that, get redirected to the wrong place to, you know, give people a credit card number or something. This is number five in appropriate access controls and settings. This is a significant Drupal problem because it basically comes down to, you know, are users configured correctly, you know, are my systems configured correctly and is my software up to date because those can reveal, you know, pretty significant bugs that would affect users being able to get to things that they shouldn't. Number eight is another one that you see a fair bit in Drupal which is a cross-site forgery request. So what that means is a cross-site forgery request is where a logged in victim's browser doesn't include a, you know, so it may explain better. So it forces a logged in victim's browser to send a forged HTTP request which includes the victim's session cookie as well as any sort of authentication information that it might need and it sends it to the vulnerable web application. This allows the attacker to force the victim's browser to generate requests that the application thinks are legitimate. So it basically, it's a way of sort of tricking the user's browsers into doing things that it shouldn't be able to do. And I'm done. Last but not least, update core and the modules. Thanks. Alright, so sorry. So quick question before I start. How many over here are developers in audience? Raise your hands. Okay. And how many of you developers also do a little bit or a lot of operations work like installing stuff and what not for your clients? Okay. Thanks. So today I'm going to talk about spinning up Drupal sites. I know it says in five minutes or less but really it's a little fuzzy but it's in a few minutes and I'm going to be using the Rackspace cloud. I work at Rackspace. My name is Shannak. That's my Twitter handle. So what are we talking about? What exactly do I mean by a Drupal site? So I'm talking about a complete stack which is standard load balancer, two web servers and a database server. Web servers talk to the database server and the load balancer sends traffic to the two web servers. So this is hopefully this is not a surprise. This is pretty like classic architecture. So we're going to be spinning up one of these stacks in just a few minutes with one command on the Rackspace cloud. So let's get into it. So I originally had a demo plan but then I was given good advice that you know it shouldn't depend on the Wi-Fi. Or a screencast. So I'm just going to play that and talk through it. Maybe I should do the live demo. Let me try one more time. Sorry. So as I said, I'm going to be using the Rackspace cloud. So the first thing I'm going to do is sign in to my personal account and I'm using the Rackspace cloud control panel here. And once I've signed in what I'm showing over here is that I'm not cheating. I'm starting off with the blank slate here. There are no servers or load balancers or databases already created. I'm really going to do this. So the way I'm going to do this is using the command line. The tool I'm going to use is called Heat. Why Heat? Because it makes the clouds rise. I didn't come up with that. So what it is is an orchestration tool. It spins up complete stacks as I mentioned. The first thing that I need to tell Heat is what cloud region I want to spin up my stack in. So Rackspace has multiple cloud regions they're named after airport codes. So I'm going to use the DFW which is the Dallas region. Then I tell it to actually create the stack. That's just the sub command and I give my stack a name. So I'm going to be very creative here and call it my Drupal site. Then this is where the meat of the definition is. I need to tell Heat what my stack should look like. What is in it? There's load balancer, there's servers, there's a database or how to wire them all up. All of that is specified via a YAML file. And that file is called a heat orchestration template or a hot file. So I'm just pointing the heat tool to a URL. This could also be a local file. But I'm just pointing it to a YAML file in my GitHub repo. Now the template can take several parameters. There are only two parameters that are required by this particular template. One is the name of a SSH key pair. So Heat can log in and configure stuff. I have already uploaded this key pair. This is some prep work that I have already done. I have uploaded this key pair to my cloud account. So I just give it the name of the key pair. Then of course I need to tell it the corresponding private key that goes with that SSH key pair. Being a private key I'm not going to upload it. It's on my local machine. So I just pass in the contents of the private key as a parameter. And with that we're going to kick it off and it's going to go do its thing. Ignore the warning heat is still being worked on. And as you can see my stack is now being created. And let's see what that looks like in the control panel. So the stack gets created bottom up. The database will get created first. So as you can see there is a database and it's building status. So while the stack is building I'm going to walk you through this hot file because that's where the meat of the definition is. So the hot file is just a yaml file. It has a description where you can specify just sort of a user friendly description of what this thing does. What this template does. It has a bunch of parameters and they are grouped into whatever logical groups you want them to be. So I have two logical groups. Parameters for the web servers and parameters for the database servers. A server. Now let's walk through each of these parameters. So the first parameter is how many web servers do you want to spin up under the load balancer. So I'm defaulting to two but I can specify more than two. The next parameter is the actual flavor of the web server. So what Rackspace calls flavor is essentially you can think of it as a combination of CPU and RAM. So how powerful your machine is going to be. And the one GB flavor is I believe one gigabyte of RAM and one virtual CPU. Similarly there is an image. An image is basically the operating system. And we're going to use Ubuntu 12 over here. Yeah, Ubuntu 12 over here. Then there's the two SSH parameters which you saw me using in the Heat Commander earlier. And that's the key pair name and the private key. So those are the only parameters that don't have defaults or default is false so I have to specify them. Then we get into the database parameters. So just like the web servers database has a flavor and this determines how much RAM your database instance gets. Then there's a size and this determines how much disk space your database instance gets. And we're defaulting to 10 gigs of disk space. I think it was one gig of RAM. Then there's a database username. You can override it via a parameter but I'm just going to default to I think Drupal DB users what I'm using there. So that's just the parameters, the inputs to the template. The resources where actually all the fun happens. This is where things actually get created. So the first thing we want to create is a random database password. So that's what that resource is and it is 16 characters in length. It's kind of hard to read. The next resource is the database itself. And that has a name and the name of the database is going to be whatever my stack name was underscore DB. And so if we go back to our control panel or that's my stack name. So if we go back to the control panel we should see a database with that name being created. And sure enough you can see it's my stack name underscore DB. And then I pass in the database flavor and the size and these are again derived from the parameters that were set up earlier. So that sets up the database instance itself. The next thing I want to do is create a database on that database instance. And in this template I'm just hard coding it to the Drupal DB name but you can parameterize it if you want. Then I create a user and give it access to that database. And I make it use the password that was randomly generated earlier. So that will set up a database instance with the database on it, a user on it. The next thing to set up are the web servers. So couple of things to notice here. One is that the web server setup depends on the database and that's because the web servers need to know what the database host name is so they can connect to it. That's what goes in the Drupal configuration file. Also notice that it's of type resource group because I'm setting up a group of web servers. And the number of web servers in that group is determined by this count property. Which is in turn determined by the web server count parameter from earlier. Now each web server needs to have its own definition. And that itself is a YAML file, another hot file. And we'll begin to that in a second. And that file takes a number of parameters itself and that's what I'm passing in over here. And these are again, you know, just these are similar, these are the same parameters originally, the name, flavor, etc. I am also passing in the database host name which I get from the database resource above. So let's look at this YAML file and we'll walk through it. Probably not in as much detail but we'll just walk through it real quick. I had really bad Wi-Fi when I recorded this. So again, there's a description is human readable and note that this particular template is for setting up a single web server. You know, it takes similar parameters like image and flavor. You know, I won't go into detail. It needs to know the key pair name. It needs to know all the database parameters so it can insert them into the Drupal configuration file. The interesting stuff here is the Chef configuration parameters. So Heat will use Chef or specifically Chef Solo to actually configure the web server, to install Drupal. And that right there is where the recipes live. Chef calls it its kitchen. So in the resources section first I set up a web server itself. And that's a Rackspace cloud server. So if you go to the cloud servers tab in the control panel you should see two web servers that are set up. And sure enough, they're set up right now or they're being set up. And they take a bunch of parameters. Now once the web servers themselves have been created, the infrastructure we need to install the software on them. We need to install Drupal on them. So we, as I mentioned earlier, we use Chef Solo, which is like a lightweight version of Chef. And it takes a bunch of properties. It needs to know which, what the IPs of those web servers are so it can log into them and set things up. It needs to know what user name to use, what SSH keys to use. So we pass all that in. It needs to know where its kitchen is. That's how Chef works. And then finally, these are Chef specific parameters. It needs to, the most important ones over here are probably the database parameters. So that Chef can insert them into the Drupal configuration file. And then finally, Chef has a run list. You tell it which recipes you want to run and in which order. So that's what's specified over there. So it runs the app recipe first followed by the Drupal set of recipe. And then when the web server is set up, we want it to expose the private IP of the web server. So what I mean by that private IP, I'll show you in a second in the control panel. So if you look at an individual web server, it has a public IP and a private IP. We want to expose the private IP. And we do that using this outputs section at the bottom of the template. And once we've exposed the private IP, we use it to attach those web servers to the load balancer. And so, again, the load balancer resource has to depend on the web server setup resource. And, you know, the load balancer has its own name. And if you go to the load balancer section, you'll see that name over there. It's still building. It should be almost done by now. And then, of course, we add the private IPs of the web servers as the nodes of the load balancer. And then there are some load balancing parameters themselves, like, you know, listen on port 80, listen for HTTP connections, do a round robin, that sort of stuff. And finally, when we're done here, what we want is the public IP address of the load balancer. That is the IP address of your website. That's where you would point your DNS to. So we expose that as an output at the bottom. And this is the IP I'm talking about. So if we go to this IP, we should see a fully set up Drupal website. And sure enough, there you go. This is a load balancer Drupal website, complete stack set up with one command. And yes, it's multiple lines, but that's just because I was explaining things. And that's it. That's how easy it is to use heat. Let me go back to my presentation and have one more slide. So yeah, that was the demo. And please do try this. Everything I've shown you is open source. It's on my GitHub repo at the bottom there. So if you go there, you can grab the templates that I showed. There's a read me with the instructions and all the parameters and everything are listed out as well. Before you do that, you will need to sign up for a Rackspace cloud account. If you go through that link, you'll get a discounted price. You'll get a $50 credit per month for six months. So once you sign up for your Rackspace cloud account, you can basically run the same commands I ran and see things set up. And by the way, as I mentioned, this is all open source. So please feel free to fork my repo and submit pull requests. I'm totally like, you know, cool with that. So yeah, thank you. Thank you to all of our speakers today and you can fill out an evaluation online for this session. So thank you everyone for coming.