to one and all present here. Today, Sanvi Malhotra and I, Vanya Khanna from grade 11 of Sun City School, wait, wait, wait. Where's Sanvi? Sanvi? Oh God! So sorry Vanya, so sorry. Good morning, good morning everyone. I was so busy blowing these balloons I completely forgot about our presentation. This is not the time to play around Sanvi. I'm not playing around Vanya. This was my grand and well it turned out not so grand but this was my entrance for our presentation and these balloons aren't here to play around with their common examples of Newton's third law of motion. What? Newton's third law? In the flying of a balloon? How do you see that happening? Let me show it to you and if you still don't understand then I'll just explain it. Okay, let me just explain it. Okay, so what we just saw was when the air is released out of the balloon it exerts a downward force. This downward force has an opposing reaction on the balloon which causes it to move upward and twirl around in the air like it just did. Just look at it once again and hopefully you'll get it this time. See? Oh, I get it now, I get it now but what are you doing with that skateboard? It's not a skateboard Vanya, it's a waveboard and it is another really easy explanation of Newton's third law of motion. When I ride this waveboard I push the ground in a backward direction. The ground then pushes the waveboard and me in a forward direction bringing me into motion. Oh, I get it now but you didn't really come into any motion there, you didn't even ride the waveboard. Okay, so action and reaction is easy but the balancing part of the waveboard? Not so much. Whenever I do try to ride it I end up falling flat on my face and while riding the waveboard is an example of Newton's third law, falling off of it, maybe that's to deal with the second law of motion so let's not get into that. But let's pause for a minute, you said Newton's third law. I don't really remember the exact statement but I remember from ninth grade that it's got something to do with action and reaction forces. God Vanya, you don't remember anything. This is what online school does to people. Anyway, Newton's third law states that every action has an equal and opposite reaction which you just observed in the balloon and the waveboard. See, physics is really easy Vanya. Sure, that was a good one. Nice jokes. Speaking of nice jokes, I heard an amazing one a few days ago and you have to listen to it. Okay, so there was a sheep that was walking on the road and Newton came across the sheep. Newton realized that to stop the sheep he had to apply an external force on it and that's when he derived the first law of motion. An object in motion continues to stay in motion until an external force is applied on it. Nice joke. Wait, it's not over. Newton is a curious man. When Newton decided to see what would happen if he kicked the sheep and you know, he did and you know what the sheep replied with? Not really. F is equal to MA.  Obviously. See, now you get it. Oh God, I think I do. I think you've gotten a little off topic. So, you know, I may not be able to ride the waveboard here but I do have a few secret talents like archery. You know, I'm a really good archer. That is so cool, Sandeep. Can you show us how it's done? Well, how about instead of me explaining it this time, you try and explain the explanation of Newton's third law of motion in archery. Oh, okay, okay. So, what you're trying to say here is that as soon as you pull the arrow, your hand exerts a backward force on the string and the string in return exerts a forward force which causes the arrow to get launched in the forward direction. Exactly. What one means to say is this is the action and this is the reaction. So, let me tell you about basketball. Basketball is another sport that I'm really good at and it's interesting to see how physics is involved in the bouncing of a ball as well. Just observe. When I bounce the ball, equal and opposite reaction. That's amazing. Okay, okay, okay. I notice something strange here. I mean, I do see the action and the reaction happening here, but it's not really equal, is it? I mean, the ball isn't really rising back to the same height from which it was thrown. That's an interesting observation. That happens due to the imperfect elasticity of the ball and due to the air resistance that acts on the ball when it tries to attain its original height. If the same experiment would be to carried out in a situation with vacuum and a hypothetical perfectly elastic ball, then the ball would rise to the exact height that I drop it from. Oh, that makes it much easier to understand. And I think we're totally done with sports now.  What about people who are not really a big fan of sports? I mean, is there any simpler example like something as simple as walking? Walking. There you go. Now you're getting the gist of it. Newton's third law can be applied in walking as well. Try it. Go ahead. Okay, okay, okay, let me try this. So you mean when I'm walking like this, my foot exerts a force in the backward direction on the ground. And in return, the ground exerts a forward force on my foot, which causes me to walk as a result. Exactly. I think you're finally understanding the third law of motion. But you know, walking is boring. I like soaring high up in the air, much like birds do. You know, Newton's third law of motion can be applied in the flapping of the wings as well. Oh, okay. I think so. Can you please explain that better? Okay. So when birds flap their wings, they push the air surrounding them in a downward direction. What are you doing? I'm just illustrating what you're saying. I mean, the birds flapping their wings and action and reaction forces. Do you not see it here? Just when I had some faith in you, it's okay. It's okay. Let me continue. So when a bird is flying, when it flaps its wings, it pushes the air surrounding it in a downward direction. This air then exerts an opposing force that causes the bird to move upward. That's how they flight at such great heights. Oh, okay. Okay. Okay. So enough about soaring high in the air. I like to personally shine in the water. Let's talk about water. Have you ever seen a swimmer? Okay. As you can see, what happens is that the swimmer's hand, it exerts a force in the backward direction on the water and in return, the water exerts a force on the swimmer and causes the swimmer to somewhat propel forward. Water. I really need some water. All the speaking is making me really thirsty, Vanya. This well is your reason. Let's put it to some use now. What is this? I mean, that is one strange thing that's happening. But do you not notice anything else also that strange? I mean, you're pulling the rope downward, but the bucket of water is as a result rising up. Why so? I think that can also be explained with surprise, surprise Newton's third law of motion. And also, this little pulley here. When I pull the rope downwards, that is the action. And look, did you observe the reaction? The bucket is coming upward. All thanks to the rotation caused by our pulley. Let's show again. Okay. Let's see the reaction and the reaction. And reaction. See, it's a beautiful process. Oh, I see it. How? You know, Vanya, pulleys remind me of Etsy Verma, favorite book for physics ever. Do not get there, Sarni. Not Etsy Verma again. His monkey questions have haunted me at 3 a.m. in the night for two years. Not again. You can't be talking about that. I think the monkeys are back to haunt you. No, Sarni. Please don't. Come on. Hold one. Okay. I know Etsy Verma has caused all of us to have some sleepless nights with his questions, but you gotta admit, his examples are really creative. Just see, here we have two monkeys and one of them has a banana and one doesn't. So, you mean yours is the greedy one and mine is the lucky one? Yes. So, if my greedy monkey wants your banana as it adds to this rope, let's see how exactly he would go about it. Okay. How exactly do I get there? Audience, any suggestions? Okay. That's a good suggestion. If the monkey tries to climb up, oh, do you see what happens? Due to the action of climbing up, the monkey on the other side is pulled upward. Action and reaction. Newton's third law is back at it, Vanya. That doesn't really help the monkeys. Oh, that's true. What can we do? Oh, gravity. It acts on us all the time. Just let go of the monkey, Vanya. Let's try. Oh, so maybe they can now just fight on the ground for their bananas. Well, I guess they're free to do so. God, move this well aside. The lack of water is pissing me off. I'm really sorry. Please just let me have some water. Excuse me, audience. Sanvi, you and your interruptions. Vanya, the mechanism behind this bottle is interesting. You know how? No, no, no, Sanvi. Wait, wait, wait. It's just drinking of water from a bottle. You can't get physics in there too. Vanya, trust me when I say physics isn't everything. You know, the straw pulls the water upward. That reminds me of something we did in 10th grade. Something about plants, something transpiration or something. We did do transpiration.  That's biology. This is a physics presentation. That's transpiration pull, silly. Transpiration pull and ascent of sap is what one I was trying to talk about with her capillary action. Fancy words. Anyway, before we get to capillary action, Newton's third law of motion can also be applied in the transpiration pull or the ascent of sap. When transpiration goes on in the leaves of plants, it generates a lack of water in the leaves, which is the action. This lack of water then causes the water from the roots of the plant to be pulled upward. That's the reaction. See, there's no biology, physics and chemistry in nature. It's all just combined under a big umbrella term, science. Oh, okay, okay. I think we've blabbered a lot for the day. Let's just wrap up this presentation now. Oh, wait a second. I think the audience might be wondering why we have this UFO lying around. Oh, okay, of course. We forgot about that. So Newton's third law can also be applied in the launching of a UFO. And that's a question that we leave the audience with to test your knowledge. Thank you.


The study investigated the effects of thermal aging and chemical treatment on the physical properties of coir fiber, specifically the tensile strength and elongation at break. Sodium hydroxide and gluteraldehyde were used to treat the fibers for two hours, and the influence of alkali and aldehyde treatment on these properties was studied in detail. The results showed that thermal cross-linking of cellulose in the fiber increased tensile strength, while thermal degradation due to chain scission reduced it. Sodium hydroxide treated samples had an increase in tensile strength and reduction in elongation at break, while gluteraldehyde treatment reduced elasticity and enhanced strength. Scanning electron microscopy was used to analyze surface morphology changes upon chemical treatment. The study suggests that NaOH and gluteraldehyde can effectively modify coir fiber with excellent physical properties. This article was offered by our Manjula, Envy Redu, RPS Chokrador and others. We are article.tv, links in the description below.


Hey guys, welcome back. Welcome back. This video is going to be all about the concealers that I use. Yeah. YouTube is all about concealing reality, right? I mean, I've read and listened to, I think it was Wayne Goss recently did a video and said that people use filters and all that stuff. Well, I'll tell you. I have never used a filter at all. I have, however, used lights. I do have a ring light. I do have other lights. And if I didn't have a ring light, if I didn't have those lights on, this is what this shot would look like. I definitely agree. This is definitely better. I mean, you get to see a little bit more. You know, it's lighter, it's brighter, it's more pleasing. Of course, lighter and brighter makes me look better, but I have a high-definition camera. Do you ever watch, like, some of the newscasters and they've got all the lights and they've got everything, but you can see every pore? Well, high-definition cameras don't hide that stuff. You know, they just don't. So anyways, but what does hide that stuff? What can conceal the pores, the redness, a little bit of this, a little bit of that is concealers. So I've often said that concealers are really difficult for me. They really are. So if you are interested in finding out what to use for concealers, stay tuned. Yeah, concealers. You know, I have a lot of redness on my face. I have a lot of veins. You know, I try very hard to start out with a color corrector after I do my skincare. I try to do a color corrector on the veins on my nose, especially, because no matter what, they're popping through now. You know, if I zoom in, maybe you can see them, but they're definitely there and I try to do a color corrector. And the one that I basically have been using forever is this one by Maybelline. And you know, you can squeeze it up a little bit and I'll show you how it looks. This big green thing sitting on my nose. But anyways, I normally will use a color corrector on my skin in the morning. When I, you know, after I've done my skincare and all that stuff, I'll use a color corrector. And this is normally what I do. And then I use the Elf Putty Primer and I put that usually on my nose and in some of the areas where my, you know, where my pores and where I have a lot I want to fill in my pores because the Elf Putty Primer on me works really well for filling in my pores and kind of giving me a smoother canvas, so to speak. Not really the best, but a smoother canvas. I put that on after I've put the color corrector on. I don't know if I'm doing right or wrong, but that's that's what I do. Put the color corrector on. Then I put my Elf Pourless Putty and I love this. This is probably the third one I've had. I think this color that I use is just the universal, universal share. Let's see. Yeah, I need to get, I think I have my backup already. I'm not too sure. I'll have to go look in my backup stash. So then I would put that on, but I kind of let the green dry in. I pat it in a little bit, but then I let it just dry a little bit so it doesn't get smooshied. And then I put the Elf Pourless Putty Primer, especially on my nose. Sometimes I go up here on my forehead or have some big pores. I should do more on my chin. I never really do. I let that dry. And then I have played around with so many. I have stacks of concealers.  I have stacks of concealers and I'm not going to talk about them all because I'd be here forever, but I will tell you really quickly the ones that I don't use at all. I have a hard candy glamofage. Everyone said this was a really good concealer. Never worked on me. I have Revlon Candid. This one never worked on me. Some of them, the colors were wrong. Some of them, they just didn't cover. You know, they didn't cover. And then some of the others that I use, like especially, you know, in the summertime around my eyes.  But in the summertime, I thought it'd be really good to get a concealer that had sunblock in. I used the IT Cosmetics 50 SPF. I bought that. I think figuring I could use that in the summertime. Yeah. Even when I warm it up on my hands and then I put it in, I have a hard time with it. I do, however, like the color science, but the color is wrong. So I have, I don't know if you can even see it. The color, in the color science, as you push down, it becomes a little pump. It's just too, I don't know, too peachy, too peachy, I think, for me. However, if you blend this in, it does kind of dissipate. So it's not too bad. But that's a summer concealer. But the thing is, I have to be super careful where I put it. Because I think whatever I put under my eyes is going to show my defects a lot more. So whatever concealer that I'm using and usually the ones of choice, I've used a lot of the, this is the Instant Age Rewind. This is super, super popular. You can see if I've used a lot of it. It is not my favorite. It is probably number four on my list. But I use it. But it is just not my favorite. I also use, and I've tried to use the Bye Bye Under Eye concealer. And this, well, I will never use this on my eyes because it just is too thick. But I will dab a little bit of this on my hand. A little bit is all you need. And I will use that on my veins. Kind of warm it up. It's really thick, thick, thick.  It's just really not good for me on my eyes. But it will work as a concealer on my nose. So that's what I end up doing with it. But, so, you know, this is a little bit further down in the totem pole. I absolutely love the Essence Color Corrector. I use the pink one every morning. When I have my makeup on, I just go around the inside of my eyes. And it just kind of boosts me, makes me look more awake. I think it looks really good on my skin. But I have so many different concealers. The this one was really a disappointment. This is Garnier. This is the, it's got like a rollerball. I could never put this under my eyes. Never. This, this just, the color is wrong. But it's just way, way too heavy a coverage under my eyes. I can't, there's no way. There's no way. It does great on my hands but not under my eyes. So what I use the majority of the time is the Boeing. And I have three in a tube. Do I have three in a tube or do I have a fourth one? I had a fourth one. But I have three in a tube, different colors. So in the summertime I'll use the number three, the industrial strength number three. Then I have an industrial strength number two that I use most of the time. I, I love these these are heavy-duty concealers. Obviously none of this is going to go into my eyes but they'll go on my nose. I'll put them sometimes in my deeper Mary Annette Lens, whatever you want to call them. So I have two industrial strength and then I have another number two. This is not an industrial strength but this is just a softer, nicer concealer in the sense that it really spreads. This is more perfect for here whereas the industrial ones are here. But then I have these two. This is the liquid. So if I'm going to do in the morning under my eyes, I have this is much better for the darker spots under my eyes than even my age rewind or any of my it cosmetics. It's just way better under my eyes than this for me. However, this is the one I absolutely love. And this is the stick and it has a, it's very, very, it's non-drying. Now I know I use it a lot so you can't really see it but in the middle it's clear and then you have the color around it. I use that it just a little dab. I fill in the dark spots then I'm going to you know either use it my sponge of choice which is what I normally do. Of course it's hard when you're putting on this stuff on top of makeup. But this, if I'm going to leave the house this is the one I carry with me because I can do touch-ups with this. It's very moist, it's non-drying, it does some coverage, it feels really, really good on my skin for under eyes. I wouldn't use it anywhere else. But my under eyes, this is where I'm gonna, where I'm gonna go. And I usually have this particular one and this one. This is my number two, the one that spreads a little easier. If I want to touch up like say my nose or something like that I might have one of these in my course but these are my concealers of choice. Every single one of these I have purchased and with the exception of this one which I haven't even talked about which is the Billion Dollar. I have to change the battery so I'm from the same position or not but this was the only one out of all these concealers that I've talked about that was actually gifted to me for a review and this is the Billion Dollar Beauty and I really like it. However the highlighter I liked a lot. The concealer for me it just didn't cover as well as my other concealers but I love the highlighter. I thought the highlighter was really nice, really nice. I probably just need a different color in the concealer but the highlighter yeah really nice. Not not like spaceship highlighter so I do like this. That was sent to me in exchange for a review but all the other concealers that I've talked about I purchased. I have a whole basket of concealers that didn't work for me. I only brought in the ones that most recently I've tried. I am always on a quest. There is nothing that I have found that will hide my veins completely. You know they just they just won't. I have found my veins have been a lot better since I use CBD oil on my skin at night. However they just really they never go away and they sort of bleed through. I hate to use that phrase but they come through your concealer after time. They still pop out and that's why I try to start with the green color corrector. Let it dry and then I put on my Elf Putty Primer on top of it but by the time I get that on there I can stop to see the veins through there again. And so I've tried at times to do the green. Let it dry and then do the concealer and then put the Putty Primer on. I've tried many different ways but those darn veins they just always pop through. It doesn't matter what I do. They always pop through. So yeah it's an it's it's an ongoing quest for me you know to try to figure out what I can use for a concealer because they're up there. When you're 66 and you have all these wrinkles under your eyes you don't want to be putting concealer under there. I don't care. I mean maybe if you have a filter on your camera which I have not figured out. I mean I film on a camera not an iPhone or I don't use my can't my phone for a camera. So my camera is high definition and I don't know. I use iMovie to edit. I don't have not seen a filter in iMovie. There are filters but they change the whole color of your video afterwards. There's nothing that I've seen that says smooth your face. There is a romantic filter which will blur the background which I think is super nice but I haven't seen one that's gonna you know get rid of your imperfection. So I really don't know what filters Wayne Goss was referring to but I'd like to know. Might help me. Maybe that's you know it's really difficult I think being a older woman on YouTube because most of the people that watch YouTube want to see young and pretty and the older mature women are usually more invisible. We have smaller channels we don't grow as quick as say a younger more beautiful woman. It's gonna be a fluke when you grow. You've got to have a real viral video something that just really took off or you have to have shout-outs by some of that's huge and continuous shout-outs.  You know they're just simply not gonna stay. So yeah it can be hard being a mature beauty guru so to speak because we are sort of invisible and maybe this whole world of filters out there I haven't figured out how to use them. It could be my age I don't know but I'd be really curious. I wanted to leave him a message. I'm sure he would not have ever answered me but I went to leave a message. Can you tell me what those filters are? Maybe it can make me look younger and that might help my channel growth. Anyways yeah so that's my concealers. I have to say hands down the Boeing concealers all the ones I have they I have the most of them I use them the most. They are my number one concealers. They are sort of more tried and true although I keep getting when there's a new thing out when there's there's a hook for that new product they're always gonna conceal gonna be awesome or another person is talking about how great it looks under the eyes and then I get so tempted then I try it I put it under my eyes and my eyes look like you know oh it just looks horrible horrible lines and wrinkles and crimply skin and just so yeah so I just I think I have to just kind of stick to my Boeing which is by benefit by the way I don't think I mentioned that because that seems to be so far what has worked for me. Anyways guys thank you so much for joining me please if you're new to my channel subscribe thumbs up leave me a comment if you can I truly appreciate every single one of you and appreciate your support 100% thank you


Thank you. Come on up, Dennis. Chips just totally ruined my first line. Like, you shouldn't tell lies about me being nice. OK, my staff are over there. They know the truth. So I'd like to thank the Cloud Foundry Foundation for inviting me up here to speak. And I'd particularly like to thank Swarna for giving me the push and the support that I needed to be up here giving this talk to you today. I'm here to share some experiences that I've had that have helped shape how I think about trying to create an inclusive environment at work. One of those experiences is punching women in the face. This is a self-defense course that I was on a couple of years ago. I'm on the floor on the left with a massive bruise on the back of my leg. The one that I was training with is called Maja. She teaches an Israeli military martial art called Krav Maga. I don't get to go on these courses very often anymore. I have a business to run. I have children. But I did spend the best part of 10 years training at and going on to teach the London South Bank University Jiu Jitsu Club. South Bank University has a really high proportion of international students and mature students, which means there's a really diverse mix of people coming through the university and also coming through my club. As well as students, we had everything from unemployed people to investment bankers turning up at the clubs. We had people from every religion you could think of and people from all around the world, every continent except Antarctica. We had people suffering from mental illness. We had people who were deaf, partially sighted, dyspraxic. We had refugees from war-torn countries. And we had members of the military who had invaded those war-torn countries. So I was very lucky to be part of such a diverse melting pot of different people. One of the things I loved most about the organization, the Jitsu Foundation, that my club was a part of, was that everybody was treated equally. And nowhere was this tip demonstrated more than in gradings. This isn't a grading. The gradings weren't filmed, and they looked a hell of a lot more messy than this. But when you wanted your next belt, you went to a grading and there was a quality bar that was set. And it was lowered for no one.  Sometimes I had been in the dojo when men decided that they needed to attack women less hard, thinking that they needed to give them an easy ride somehow. When that happened, those men were threatened with being thrown out of the dojo. Because it's not okay to make assumptions based on what someone looks like about what they can handle and how proficient they are. And it is downright disrespectful to deny people the opportunity to prove themselves by giving them an easy ride. But that was the gradings, okay? And we didn't spend most of our time in gradings, we spent most of our time training. And in a training session, over the course of a couple of hours, an instructor would show you a particular attack and a defense against that attack. And throughout the course of a couple of hours, you would work with different partners, changing partners regularly, to drill just that attack and defense in isolation. Now, if when you worked with a new partner, the first thing you did was punch them as hard as you possibly could, like you would in a grading, then the chances are that they're probably not gonna learn very much.   So instead, when you were working with someone new, you had to treat them as an individual and be responsive to what they needed. That meant that you had to listen to what they were saying to you. Sometimes, these sessions would get tough, so you'd have to motivate each other. It was hard knowing what you were doing wrong. Sometimes, you needed somebody to spot that for you. And most of all, you had to change what you were doing so that the other person could get as much out of the session as possible. So fast forward a few years, and I had to move for work, became a parent, didn't have time to teach anymore, which is a shame, and I miss it greatly. But I did become a Cloud Foundry Consultant, and after going to a few diversity lunches at CF Summits, I ended up reading a really awesome book called Delusions of Gender by Professor Cordelia Fine. Now, this book collates a whole bunch of research that dispels common misconceptions about gender-based performance differences. For example, you may have heard the stereotype that men are better at maths and women are better at communication. And it seems like a lot of people have heard this stereotype because one study found that if you ask people in a survey to rate their ability in different areas, then men will say that they're better at maths and women will say they're better at communication, but only if you ask for their gender at the top of the survey. If you don't ask for their gender, then men don't rate themselves as highly at maths and women don't rate themselves as highly at communication. That first case is an example of something called stereotype boost. When you're reminded that you're part of a group about whom there's a positive stereotype, you live up to that stereotype. But this doesn't just affect people's self-perception. It can affect their performance as well. You may have heard of the stereotype that men are bad at empathising. Researchers looked into this and gave men a social sensitivity test. This is one you have to guess who this woman is speaking to on the phone. When researchers gave men a social sensitivity test and told them it's about understanding people's thoughts and feelings and that historically, men aren't very good at social sensitivity tests, you know what? The men performed worse than the women did on these tests. But when researchers gave the same social sensitivity test, the exact same test, to a different group of men and told them it was about complex information processing, and they neglected to mention that men historically have been bad at this, the men performed just as well as the women did. That first case is something called stereotype threat. When you're reminded that you're part of a group about whom there are negative stereotypes, it can negatively impact your performance. If you think you're bad at something and you think that everyone else thinks you're going to be bad at something, it's going to be very hard to apply yourself fully to the task at hand. Now, it also seems like motivation has an effect here as well. This is a mental image rotation task. I've not highlighted the right answer because I want to drive you all crazy. Men are supposed to be better at this than women. However, a study found that if you quite rightly tell men that being good at these tasks will make them good at a career in flower arranging, then they score 20% less well than if you tell them it will make them a good fighter pilot. So what's going on here? It's a complicated picture. We've got stereotype boost, stereotype threat. There are these cultural motivational issues going on as well. What it's telling us is although there is a body of evidence showing these gender performance differences, dating back decades, that evidence doesn't tell us the cause of these differences. More recent studies have shown us clearly that the way that we treat people has such a big effect that it can cancel out these performance differences all together. So reading that book was one experience. The next one was talking to my friend Therese Stowell at Pivotal who put me onto the work of Karen Holtzblatt. Karen is a user researcher who has turned her professional skills to try to find out why women leave tech jobs. You may have seen her speak at the diversity lunch last year. Now, Karen's findings were typical of most people, I think. She found that in order to stay in tech jobs, women needed to be part of high-performing, tight-knit teams. They needed to be doing meaningful, cutting-edge technical work. She also found that most like... Like most people, women needed to be given a push and encouragement to take more responsibility and to take more risks. And that once they're being pushed into the limelight, they need to be given support. Having just read Delusion's agenda, it seemed clear to me that if women needed more of a push, that's not because women are somehow intrinsically lacking in confidence. We've got enough female UFC cage fighters and prime ministers to disprove that. Maybe it's because they're women in tech. Being part of a conspicuous minority is a really great way of reminding you every day that you're part of a group about whom there might be negative stereotypes. Now, I told you about Karen being at the diversity lunch. This bit's unscripted, right?  Steve told you yesterday that he was part of the problem because he didn't go to the diversity lunches. He didn't partake in the conversation. I used to, and I stopped going. I stopped attending diversity events because I was frustrated at problem statements. I would go along to events. I would hear that there are not enough of different types of people in tech, but no one told me what I could do better. No one told me what I was doing wrong. So I stopped turning up. I saw Karen's research in a podcast instead in a webinar. But lucky me! I get to leave the conversation when it suits me. I get to ignore the diversity topic when it frustrates me. Not everyone has that luxury. This talk came about because I wanted to find out what I could do better. I wanted some action, some actionable advice. And that's how I ended up here. So what can we do? When we're trying to make the world a better place, should we be highlighting particular groups that we're aware of and giving them special treatment? Well, whether we like it or not, if we start highlighting people's differences, we could act just like that gender tick box at the top of the survey. We could trigger stereotype threats by making our differences more clear. Not to mention minority spotlight effects, where people are made to feel more anxious and less welcome as a result of having their minority status highlighted. Sometimes some people just want to get on with their job. They don't want to be the representative minority, speaking on behalf of a whole demographic of people despite being just one individual. These are the words of Sarah Novotny from Google at the last year's diversity luncheon used with her permission. It's a good one, Dan! You've come up here! You've told us a load of stuff that's not gonna work. Great! That's really helping move the conversation forward, isn't it? So really, what can we do? The good news is, when it comes to stereotype threat, just telling people about it is enough to start mitigating its effects. In a U.S. college study, students were given a maths exam. Some of the female students were told, if you feel nervous about this exam, it could be because you've heard the stereotype that men are better at maths. It's just a stereotype. Those women reported higher levels of anxiety during the exam. But importantly, they performed just as well as the men did, unlike those who hadn't been told about stereotype threats. Now, I've talked a lot about gender so far, but clearly there are all sorts of underrepresented groups in tech. There are some minorities that are obvious. There are some people that will have lived their whole lives as a minority in their culture and probably show the signs of chronic minority stress, where they've got observably lower health as a result of a lifetime of being marginalised. But there are lots of minority groups that we can't see, people whose sexuality isn't overt, people struggling with mental illness, the parent whose child is terminally ill, maybe even the distant programmer, struggling with the scars of horrific childhood trauma that they don't even want you to know about. If we focus our attention on the groups that we can see, then we're going to miss all of these people, all of the people that find themselves at the intersection of different groups. So how can we help everyone? Well, we can treat people as individuals and be responsive to their needs. We can listen to what they have to say to us. We can encourage each other when the going gets tough. We can help each other identify our blind spots. And most importantly, we can change what we're doing in order to allow other people to fulfil their potential. Now, I'm not saying that this is going... I'm not saying we should be blind to the systemic injustices that people are faced getting here and will continue to face. I'm not saying that treating people as individuals is going to fix all of these systems, but it's something that we can all do every day to help make a positive difference. Now, yesterday, Steve Greenberg was exactly right to tell people that everybody is welcome. Not just because it's true, but because it makes a difference. In another US college study, minority students, before they started their academic career, were given a 15-minute intervention, a 15-minute chat in which they were told, if you feel like you don't belong here, you feel like you're the odd one out, don't worry about it. Everyone feels like the odd one out when they first start. Everyone's welcome, everyone belongs. Look at the people that have been here for a year, they've all fit in just fine and made friends. Two years later, they had significantly better grades. Better academic performance after two years from just a 15-minute chat. Imagine what we can do if people feel welcome all of the time. Now, if you've ever been the new kid in class, there is no amount of effort that you can take to make you feel welcome. There's no amount of will and things that you can do to make you feel like you belong. The only people that can do that are the people that are already here. Any of these faces look familiar? If you're in this audience, the chances are you work in the tech industry. Only you can make other people feel welcome. You are the culture and the context in which other people have to do their jobs. You can help people fulfill their potential by making them know that they belong. Only you can do that. Now, if you're looking for the research that's gone into this talk, don't go driving traffic to my company's website. Go and pay for Cordelia Fine's book.  Thank you for listening and staying out for this talk and have an awesome conference and go and make sure that everybody else feels welcome to be here. Thank you.


Hello, welcome everyone to After Lunch. I have coffee, not enough for you seem to, so good luck. This is a very technically focused talk. I hope a lot of the content though, whether you're a very extreme tech person or you're just getting a Drupal or all these different kind of lines that we could draw with experience and skill set, I hope that each of you are gonna grab something out of this talk. We do go through the full stack. So everything from core OS services all the way up to Drupal plugins to add hardening to your deployment. So we'll probably be a little tight on time. I'll be here after my talk.  But if you do have questions, I do have business cards and all that. So I would love to get you answers if you have them and let's get started. So I'm Mark Stanislav. I'm with a company called Duo Security. We do two factor authentication. So hopefully some of you guys might know what that is. We'll talk a little bit in here about two factors since it's kind of an important deal with CMSs these days. If anyone saw the disco botnet with WordPress with thousands of computers taken over because of WordPress, basically brute force credentials. So that's kind of what we're focused on across all platforms and software. My background's in something like 12 years of PHP. I was a sys admin for about a decade. I did penetration testing code audits for security teams. My master's degrees in information and security and some other stuff. So I have a kind of a nice broad background to hopefully give you guys content that will actually be useful to you and not just kind of talking over you and hoping that you grab something. The CMS in general, I realize this isn't 100% Drupal at this point. Hopefully I think you guys are all wishing that a third of all CMSs or a third of all sites were in Drupal. But really one in three sites do run some sort of CMS. Now Drupal of course has a big market share. A lot of enterprises uses Drupal. So that's certainly very important. What really doesn't come out a lot when you're not thinking about things holistically in terms of what security looks like for an organization is that the web server, the web services that you run, a lot of which might be based on Drupal or some other CMS, that is often one of the biggest targets for any enterprise. And the segmentation between that website and the rest of an organization is a lot smaller than some of you might think or maybe you already know that, hey, my web server is also tied into my corporate network somehow or the web server is on the data center network with a bunch of our services that we provide customers. So if you look at things in terms of as an attacker, if I'm gonna do a penetration test, your corporate website is just as interesting to me as anything else. If for nothing else, one good example being, if I can steal passwords from your sys admins, if they're not all using random, unique passwords with something like LastPass, maybe I get one of their passwords off your Drupal site and then that lets me into your VPN and that lets me into the corporate email account. So don't think of things as really as compartmentalized as they may seem. Think about things in terms of what can an attacker do, what kind of malware could they send out with your, if they compromise the Drupal site, what kind of credentials could they steal on and on and on. There are with whether PHP or any other language, anytime you have a CMS, you have a lot of attack surface because there's a lot of complexity. Now you can abstract the complexities certainly, but things like plugins and themes, libraries that you might include, each of those things are themselves one new thing for an attacker to go after. So if you got the coolest plugin that just came out to do Bitcoin or something, right? Thousands of sites could deploy that Bitcoin plugin and how many of you ever had a code audit done of that by a security professional? Probably none of you. And that's almost every plugin. Certain development teams certainly have some good knowledge behind them. However, information security, especially when it comes to code audits, there are things I could show you with PHP that you would not believe you could do with code that looks completely secure. And that's kind of the trouble is you don't need necessarily the experts as a Drupal, you know, sysadmin or a Drupal theme designer or a plugin writer. You do have to know some of the things that attackers are gonna do so that you can at least kind of mitigate for those. In order to actually hopefully have a chance at security with any website, with any web service, we really do have to think of things top down, bottom up. It has to go both ways. You can't look at just the plugins or just the kernel hardening or just the firewall. And anything in that stack that isn't strong or that hasn't been protected adequately will be the way that I will get in when I do a penetration test. So let's talk about what we can actually do and some of the change we can have. So here's the quick overview of some statements. We're gonna go through these one at a time.  There's a lot of misinformation about how security actually works and the ways that you think you might be protected might be a little bit more theater than it is actual real security. And the thing I know about the development community as being part of it is engineers, software engineers, software developers want to know what's wrong with things. They don't wanna be told, oh, everything's fine, don't worry about it. You want to know why that one method doesn't go at like four milliseconds. You want to break into that problem and break it down and understand it. So hopefully some of these will, whether it's your point of view or someone that you believe in or maybe hopefully no one's told you some of these, we'll go over them one at a time. The idea of a third-party web server or having a demilitarized zone, so DMZ, this part of your network that's segmented from the rest of your corporate network so that if an attacker did break into your web server, they wouldn't be able to do anything bad. Kind of what I was foreshadowing on before is as simple and as the idea that no one would ever target you, those kinds of tropes that we'll talk about, there is so much value in that one little web server for your company and it's not just to make your company look bad often, it's often just a leg to then move laterally through your organization to actually get to the real important stuff. So maybe your corporate Drupal site or something else similarly not too scary, if I can break into that and then move laterally through your organization, maybe I get to the credit card numbers, maybe I get to the insurance documents with social security numbers. So don't think of it just like, oh, well, it's just the corporate website, that's still a big deal. Any, there are about a dozen or two that I've seen just looking at websites over the years where it says, Scanned Buy, McAfee Today, Hacker Proof. And it's just so frustrating to see that as someone in the information security because it's not that anyone could break into that day or would break into that server that day, but it's that there's no single scan, none, that will ever tell you if your web server or service or app is not vulnerable at that given time. You can do due diligence, you can hire firms to do ethical hacking type operations, but there's nothing to call hacker proof. You cannot know that at all. If you're investing your money in something like a web server scanning you every single day and you're paying 50 bucks a month or something for that, I would take all that money every year and invest it in one code audit or at least a partial code audit by someone qualified who will actually look at what you're doing and not just throw a blanket over it and say, it looks fine to me today. Web servers, any server for that matter, but it's certainly DrupalCon, right? Web servers have a lot of value. You can, I think I mentioned in the earlier slide, you can host malware and the malware that you host, if you're an important enterprise website, there's this idea of a watering hole attack.  You would go after the source where everyone's gonna go, everyone's gonna gather and everyone's gonna drink out of. If you're a large enterprise running a Drupal site and I can compromise your web server, I can do what's known as drive by malware attacks, I can give out malware to people when they visit your site that they will probably never even know I gave to them and now I've compromised their computer using your server. That's one example of bad things that happen, but simpler things, using your server as another of millions of bots in a denial of service attack. Hosting piracy off your server was a hugely popular thing for many years before the age of torrents. General attacks against other people and then of course malware. So even if your site doesn't hold data, that's important. Your server, your organization's reputation, the legal team at your organization, the security team if you have one, all of those people will be in a very bad place if your server gets compromised even if there's no data on that specific box. You should patch daily. You should patch as able, of course you should have a QA and some review and testing before you update plugins and other best practices, but as soon as you're able, you should be updating code. Especially if you have code that has a change log entry for a security feature or a vulnerability or a bug or something.  And at some point, you run out of time or you find some friends project that looks cooler and you start working on that or someone comes out with a competing plugin and they're like, yeah, maybe I'll just not do my plugin anymore and just call it a day.  So keep in mind that developers and some of you in this room may not patch plugins regularly. They may never have a code audit done. They may not actually respond when people like me contact them and say you have a vulnerability. They may go, thanks for reporting that. You know, talk to you later. I've seen everything in my different roles between development and security where there's a lot of apathy at the end of the day for some of the stuff that I've submitted to plugin maintainers, honestly. So keep in mind that the best you can do is use plugins that hopefully you've had someone audit, which I understand is not very likely, but at the very least keep in mind the development life cycle. Keep in mind that these people are still working on these projects and not just dropping them dead. And at the same time, the cool thing about Drupalcon and similar organizational, with Drupal Association stuff, you guys have a lot of money here if you're not realizing that. Think of how many core plugins that people might contribute to or download and use. What if each of your organizations instead of like getting the best banner at Drupalcon took a little bit of that money and put that towards a fund for a security audit of all the things that you guys make your money off of every day? So think about different ways to give back to the community and one thing that we don't see often enough in the open source, we've started seeing a bit of a change after Heartbleed, the Heartbleed fiasco is that not enough people are contributing to the security of the software that runs their entire ecosystem effectively. So think about that in terms of Drupal specifically. Computers, well let me rephrase. The people breaking into your systems are very rarely gonna be going after your organization in a targeted manner. We know IPv4 space is relatively small compared to IPv6 of course. It actually takes right now about 45 minutes for a software that got developed at the University of Michigan out by me, 45 minutes to scan a single port on the entire internet. So I can go to every single one of your web servers in 45 minutes on the entire internet and get the banner, get the headers for Drupal, grab the index file, figure out what version you're running. If I can do that and I can do that every 45 minutes, what if I as an attacker can find a vulnerability in one of the most popular plugins in Drupal? I don't have to target you. I just have to scan the internet, dump all the Drupal versions, get the modules that you're running through fingerprinting or whatever else and then run my exploit against the entire internet in 45 minutes. So don't think of it as no one's gonna target us, no one cares about us, no one's looking at our server, everyone's looking at your server because they don't have to care what you do. Of course, depending on which enterprises some people might be targeting you, you might actually be a direct target. However, for most of you, it's really just rushing roulette of if someone has a bug and they know how to attack it and exploit it, they will go after as many servers on the internet as possible. So here's kind of the breakdown of what we're gonna go over today in terms of overall security. Obviously, a bit of an eye chart that's for a reason, security in terms of a stack is complex and there's a lot to it. So we'll break into each one of these, again, get a business card after if you have a specific question on parts of these as I know there's gonna be a lot to go over today and the slides are available as well, so no worries. The OS and services level is interesting. I think the agility that we've been given with things like Amazon Web Services, for instance, has made this less of a big deal. I mean, you can start an elastic load balancer, build some instances, pull up a network stack and web stack and then if you wanna update, you can literally just create like 10 new instances with the patches and then take one out, put one in, take one out, put one in, now you have updated architecture. So we're in a better place than we used to be. Certainly, depending on how long some of you have been working in this industry, you may have had a web server that was running the same version of Apache and the same version of PHP for four, five or six years if no one really needed to fix anything. So we have more agility now and we have to think about using it. One way to do that is have a managed services provider take care of your underlying architecture. You can be the developers, you can be the app people but perhaps if you're not the best at security or perhaps you don't have enough cycles to do patch management, look to a third party to maybe do that for you. Manitory access controls is a big gnarly area of security. The too long didn't read on what mandatory access controls are is if you think about read, write, execute the basics of any file access. Those models, if I own a file, I can say, oh, I want everyone to read this file, I want everyone to write this file but no one to execute this file. And I can set that, it's to my discretion which is why it's called discretionary access controls. Manitory access controls are kind of a top down kernel level where the administrator and that doesn't have to mean like root or administrator actually, but the kernel level control can actually make policy and that policy can be enforced at the kernel level not in the hands of a user. So even if I said, I want all people on every account on the system to have access to all of my files, read, write, execute, delete them, add them, edit them, whatever. The kernel can still say, no, that's a terrible idea, you should not let everyone do that and I'm gonna stop you from doing that. So in Ubuntu, you'll see app armor enabled on CentOS and REL, you'll see SE Linux enabled, they both effectively do the same thing and these policies can do it on files, they can do it on ports, they can do it on network services and actually restrict bad things that could possibly happen if someone did break in and got low enough privilege to actually start attacking the system. And for Ubuntu and CentOS and REL, those are generally on by default unless you have a custom build or something else. So take a look if you get a chance if you haven't. One of the oldest things that everyone has said but when I do pen test, I disagree that everyone heard everyone the first time, network services that need to be exposed should be exposed, you want your network services to work. However, if you don't have a specific reason for that specific host to be exposed, not just to the internet, but to your internal network. If you have an Amazon deployment and VPC and all this awesome stuff going on your backend, don't give SSH access to every host from every host.  Even if you think you're behind a firewall or a VPN or whatever it is, always segment as much as possible. Don't leave things to chance. If you can control it, go ahead and do it. And then two factor authentication, whether it's the Drupal credentials for the actual accounts that administrate Drupal, it's Linux, it's your VPNs. You don't have to trust people are gonna make good passwords anymore. You don't have to trust that people aren't gonna get their passwords phished or brute forced. Don't do it, whether you use Duo Security or one of the other 100 vendors out there, use some kind of two factor, just promise me that. So patches, going over the top, the core patches, like an app get upgrade or a yum update, do those things. You should do those things on your Linux boxes or the Windows equivalent, right? One place that I see things fall down often is the latency in actually updating things like PHP. You're like, hey, we built on this version of PHP, we trust it, we know it works. There are vulnerabilities that directly affect PHP, not the version of software you're running PHP with, but actual PHP code has had inherent vulnerabilities that have been patched and have been rolled out. If you use other stacks, so maybe, obviously not everyone here is just a Drupal person, you probably have other jobs and other projects and other cool things.  It's not just the system level stuff. A lot of times you might grab a library from Perl or something, throw it into a project and not actually have system level updates for it, think about what that means long term. Will that code ever be updated? What if there's a patch to that library? Will you ever get it? And one other thing that gets missed, especially if you still have actual physical servers in a data center, is things like firmware, out of band access, lights out access. Those pieces of firmware often have vulnerabilities or backdoors or hard coded passwords or other bad things. So think about if you do control your hardware, what kind of access people have to those?  I'm gonna mand middle all that traffic on the back end and just start taking it in. So things, it starts really small and attackers really, we talk about footholds. The simplest minute aspect to a PHP library can go all the way down through your entire network in a matter of minutes with the right person. So I kind of gave you the, well, let me throw this up here. I gave you the overview of this. So basically discretion access controls, you have access to, as the owner, say what's gonna happen, mandatory, a higher power above you decides what's gonna happen even if you own the files. So here's a bunch, and again, this is why I have the slides because you guys would hate me if you had to type all these links out. Networking, firewall, stuff like that. Yes, you should still have a firewall. No firewalls won't really stop a lot. However, that doesn't mean you should get rid of things. Firewalls are generally easy to maintain. You basically say what you want open and ideally what you don't want open. Sometimes people just say, oh, I don't need a firewall. It doesn't matter. Keep in mind, one thing that firewalls do for you is if an attacker does get onto a server, if they can then connect outbound or inbound in whichever way they want, they can very easily take a PHP vulnerability, open a network socket, and then have command and control over that open port because you didn't have a firewall. So it might not stop them, but it will slow them down, it will frustrate them, and it might actually break some automated attacks we see. Again, most things that are happening out there bad to you are actually automated. They're not actually a person taking time. So if you can break the workflow of some of these attackers through their automated means, they're gonna get frustrated and go to the other 100 people down the road from you that also have vulnerabilities in their server somewhere. Network allowances, you can do cool things by user and group. So you can say this user is allowed to open this port or this group can open this port. And you can actually limit, again, more access for what network ports are happening on that. Things like denial of service, Cloudflare, if you can afford them and you wanna use them, that's a great option. Any other kind of CDN is usually a pretty good option. It will limit denial of service effects and it will hopefully keep your site up. But there's also, excuse me, there's also a lot of cheat methods to do that. Built-in IP tables, firewall, packet filtering on Linux. You can actually do some basic load balancing with that. There's, of course, there's other ways with proxies and some other cool stuff. And then one last part is you can actually also do time or calendar kind of constraints. So if your organization only works on a certain web service backend between X and Y hours, or you only log into remote systems between X and Y hours, you can actually then further mitigate the potential that someone might break in or see a service that's open when it shouldn't be or any other kind of edge case. If you have that kind of hard lines for certain things that you do in your organization, you can actually control that a little bit better by implementing some of that. So two factor, you can do two factor with a bunch of ways. There's mobile app ways, there's SMS phones, tokens. Again, there's a lot of vendors out there. Go find one that works well for your company. Web servers, you know, Apache I think has been the worst of this for all the years that I've been using Apache since the early one three days. Apache specifically has enabled modules after modules after modules out of the box that most people will never, ever, ever need. Now granted, over the years very few of those has had severe vulnerabilities, but again, think about things as reducing scope, reducing attack surface, okay? If you guys walk out of here and you go back to your office and say, yeah, Mark said don't reduce scope or reduce attack surface, that's the best thing you can say ever because it's true, like most things don't come down to what you patch or what you, you know, or the plugin that you think's really secure, it comes down to if you didn't need it, get rid of it. If you can lock it down, lock it down. That's really where security honestly at the end of the day comes from.  Simple things and you know, especially in the security community we're really, really finicky about saying like security through obscurity is a bad thing and you guys are dumb because you think it works and blah, blah, blah, not true. Security through obscurity does work. What it does, it gives you lead time and that's sometimes all you need, right? It's like you don't have to run away from the line, you just have to run faster than your friend. It's true and if you think about Heartbleed, Heartbleed came out and everyone started looking at all your servers to see if you were affected by Heartbleed. What if there was a way where very easily depend how Heartbleed or something else would have worked, what if they were looking for a banner like Apache 227? If you don't have a banner Apache 227, they're gonna scan the internet, find all the ones that do have 227, go after them first and then maybe circle back to the rest of the internet later and maybe that's all you needed for the next four hours to get your stuff patched. That seems like a win to me.  So make yourself less of a target. SSL TLS, we'll talk about that more in a second. And logs, most people don't keep logs off site, most people have their logs local on their server, if something breaks they might look at it, if they get breached maybe they catch it, probably not. You should be logging all your stuff off that server. So let's go down on a few of these. Again, if you have a web server that has a lot of modules, disable them one at a time, re-start, test your app, go through your, or your Selenium test or something else, make sure you didn't break everything and then go on to the next one until you get rid of all your extra stuff. So these I can tell you very, and I realize now everyone's Apache here, but these are things you have to have in Apache for things not to go boom in most cases. So try not to disable those, just try the other ones after.  So this is really important, and it's really important because it's really fast and it's really easy, because I usually grade things in how quickly can I get them done as a value add to my day and be like, look, I got five projects for security done. This is one you can get done very quickly. There's a whole SSL Labs team, they're from a company called Qualis, and you can go to that link where it says second, you can go to that link and you can put your web server in there. It will test everything about your SSL TLS deployment. It won't just say, oh good, you have secure sockets layer, congratulations. It will say, what Cypher suites are you running? What's your common name? Does this match, does that match? It will give you a report card and tell you what you got wrong and then you can go make those edits, retest and validate that you have a proper configuration. Yeah, yep, yep, these slides will be available. Yep, no problem. It's ssllabs.com slash SSL test if anyone's really impatient wants to test right now, that too. But yeah, just rinse and repeat until you get an A or an A plus. Like it's very, it's a grading system you all are very familiar with. So it will tell you what you need to do, the PDF file that's above will give you enough information to understand why these things are good or bad and hopefully get you on a better path. As soon as a server is breached, your logs on that server mean nothing. They mean nothing to the FBI, they mean nothing to me as an auditor, they mean nothing, they mean nothing. As soon as I break into your server, I probably can overwrite your logs, delete them, manipulate them, whatever I wanna do. So don't trust logs on the server. What you should be doing is actually pushing those logs off to a central service. Now, that central service ideally should only be for logs. You should very much lock that server down, of course, but if you're just sending SysLog data over the network, if someone breaks in, they can't delete what already happened, right? It's a one-way path, so data's going out, data's going out, they break in, they delete all your logs locally, and all your logs are already over to the safe like Bastion hosts where no one can break into it hopefully. So think about longevity, don't keep logs for a day or a week. One thing that I think happens a lot is we don't spend enough time log tuning, you might tune logs for performance to understand what's happening, but are you tuning logs for security? So think more about that, how your organization's kind of matured through security, and think about what logs you're getting and what logs might be security relevant, and then try to store those off-site. And that literally can mean maybe you have a completely different Amazon web services account with one host, just for logs.  All right, development platform. The same basic principle of any software like we were just talking about with Apache, if you don't need it, you should get rid of it. The same thing happens with languages.  Get rid of that module.  Information, same thing. If you have a PHP version, you can disable that. We'll show you how in a second. Privilege separation is maybe a foreign concept or not a phrase that you're all that familiar with. At any point in time that you can, again, limit scope or limit access to an attacker, if you can break down the level of privilege that one process or one app has so that it doesn't give access to all your other apps or all your other processes or all your other databases, you have then made, again, a bigger pan the ass for the attacker. And lastly, we'll go over one thing about kind of back end security. So libraries and modules, again, a lot of people are consuming code. Sometimes that code is not maintained or it's forgotten about or they just stop caring. The one thing I've seen a lot of is, how many people over the years have used TinyMCE and then turned out to hate it? Okay, yes. I'm not shocked. So TinyMCE has actually had dozens, let's say, maybe more than dozens. You might have to round up to a three-digit number at some point. It's had a lot of vulnerabilities over the years. Other kind of WYSIWYG-y type things have also had default code that it would install and that code was for testing by an admin. Well, that code would be default and you would never delete it because you didn't look in that folder to note it was there and then turned out there was a vulnerability in that default test code. And then you could exploit that and now you have access to the actual web server. So things get really bad very quickly when the wrong thing's in the wrong place. If you could hold on to the hope, that's great, but remember, at some point your favorite plugin, your favorite core library in Drupal, your favorite method, there probably will be some vulnerability in that. So keep in mind that even if everyone's using a plugin, that does not mean the plugin's safe. OpenSSL is a great example of everyone's using OpenSSL and OpenSSL had a huge, huge implementation problem, okay? So while many eyes and all that is great in open source and it does work and eventually comes around, sometimes it takes like five years. So don't make that your only hope, maybe if you can again, code out it's yourself, but just don't forget that just because it's popular doesn't mean it's secure and at the same point, take a look at the community, whether it's GitHub or wherever else, look at the issues that are coming in because there might be an issue in there for security and the maintainer might just not be looking, but guess who's looking at GitHub issues for vulnerabilities? Attackers, they're gonna be looking for issues that aren't patched yet for the reason of attacking them. So be ahead of the game if you really care about a certain project if you're able. Same thing with PHP, go ahead and expose PHP off, never ever ever show errors, always handle your errors. This is no more important than ever when it comes to things like SQL injection. If I can see an error for SQL injection, I don't need a person, I need a bot and I can do SQL injection against all of your plugins or all your sites or whatever it is, very quickly without any knowledge if there's a single error message for SQL. So hide those things, it's only gonna help attackers, it doesn't hurt you and honestly like production systems you probably should never show like unfiltered errors to users in the first place. Couple other ideas. One area that gets forgotten about a lot is your cookies, so your session cookies and other kind of cookies that are important. Those two settings in your PHP config are probably one of the best things you can ever do to prevent a bunch of different attacks. Now if you have SSL enabled, the second line down there, cookie secure one, means that only cookies over SSL will be transmitted. So that means if there's an attacker and your user's logging in from a coffee shop and someone's sniffing their connection man in the milling them, that attacker can't get the cookie because it's not being given because it's not encrypted. So that's a big thing and very easy to turn on. The other one which isn't done enough still is HTTP only. Cross-site scripting, I'm sure you've all heard of it at one point or another, you basically know what it looks like, how it happens. HTTP only means that if someone does find cross-site scripting, they won't be able through, without a lot of headaches on their end, to actually be able to steal the cookie from the user because that's one of the most common reasons why cross-site scripting is a big deal. If you have a cross-site scripting vulnerability on your website and you don't have HTTP only, odds are that the attacker can trick the user into clicking the link and it will immediately spit out their cookie and send it over to them and they are now your user. That's the risk and these two settings together, very quick things to turn on make a big difference. Privilege separation, if you have things like MySQL or any other kind of SQL, you've probably done what we've all done which is like grant all privileges on foo.star to user at identified by. You've all run a manual, you've granted all privileges immediately to that user and oftentimes you might do that to root. You might just say grant all privileges to root at local host. Don't do that.  So when you create a Drupal instance, create a Drupal instance, a user, a password, a database, only for that instance of Drupal. If you add another app, don't reuse the same credentials. And why? Because you wanna limit if an attacker does get credentials for Drupal, they won't have credentials for you. Other dozen sites that you're hosting on that same server. MySQL often, and again you guys are probably at some scales here that are pretty awesome and maybe you're not even using MySQL or you're using Postgre or God only knows what else these days. However, think about things in terms of MySQL is a network service. However, many of you have single deployments that don't actually have network service needs. You have local host needs. You have connect local socket and use MySQL. If you have to have network privileges for MySQL, you probably should have SSL running between those SQL servers. You should not have networking enabled if you don't need it, so turn it off. Couple things, commands that are executed. And let me give a quick example of this. I don't think it's anywhere else in here. MySQL, if you grant all privileges on a database with a user, one of those privileges is the file privilege in MySQL. If you give me the file privilege as an attacker and I can manipulate SQL queries like SQL injection, I can actually do things like write files to parts of your file system. I can also read files from your file system and there are really clever ways that I, without writing any data in your file system, reading out of PROC, how many people know what PROC is or have at least heard of PROC. So it's a pseudo file system, it's on Linux by default and it just has a bunch of metadata basically about the system, about processes. Using my browser, changing headers in my browser, connecting to your web server and having the ability to read a file, I can execute arbitrary PHP. I don't even have to write files to your file system, I don't have to pull it up in Apache. I can actually do exploitation just by reading PROC through my SQL, right? So again, it seems like oh, it's just MySQL, like maybe they could steal my database but they can't hurt the server. No, no, we absolutely can do bad things to your server using MySQL or Postgre or many of the other databases. And the PHP and CGI mode actually does do segmentation. It's not one giant account that runs all the processes. It actually, sir? So the trick there is if you have a virtual switch, like if it's like vSphere or something that you have a bunch of VMware stuff, that data, if it's not encrypted, is still vulnerable. So it's not so much that it's segmented privately. That's good that it's segmented privately and it's over a virtual switch. However, if you're still not protecting that data or if I'm an attacker on a different box or different VM instance and I'm on the same virtual switch, I can then attack MySQL over that network connection. If you have to have it at all, it should be encrypted and if not, shut it off, yeah. All right, let's get some backend security up here. So one thing that you guys might not be super familiar with is this idea of an SQL proxy. And an SQL proxy like many other proxies takes data or network data and it passes it on somewhere else. So you might have reverse proxies in your environment. You might be using load balancing type of functions for proxies, whatever. Green SQL is one example. They used to be free, I think they're all, they might have a free version these days but I think they're mostly commercial. They're cool though because the connections that you make from your web app to your database service, you actually proxy through something like green SQL. And what happens is when it gets the database connection, it looks at all the queries coming over your SQL commands from your app and it can actually flag them or deny them if it looks like SQL injection. So if all of a sudden it gets a database query that's trying to read Etsy password off a host, it's gonna stop then and prevent it from actually happening. Same thing, mod security, mod security has been around for a very long time, is free.  And mod security will actually do that kind of operation but at the web app web server level. So when a request comes in through the web server before it hits your app, it will actually say no, no, no, this looks like an attack. I'm not going to let you do that to this web app. So your web app doesn't even have to necessarily be security because mod security or green SQL will actually intercept those queries and stop them. Now this isn't how you should live your life certainly, you should still be protecting your apps and doing security and doing whatever you can. However, remember, you're not always gonna know when a vulnerability came out. You're not always gonna know that there's a bug in your software so you wanna layer on these extra controls if you're able to. So DAC Mac, we talked about earlier, anytime you can lock down permissions and privilege on files, do it. One big thing with PHP apps especially, and well I guess web apps in general, is having like that temp space in your web server directory that really, really sucks for security. If you can have read-only files in your web service directory, that's good stuff, do that. And then getting back to what we were just chatting about, if you are using MySQL with multiple servers or anything else that's network enabled, it doesn't matter if it's on the backplane network or over the internet, have that data encrypted between both points. All right, last few slides here. Patches, again, themes, themes have often been one of the worst parts of security with CMSs. Drupal in my honest opinion is probably not nearly as bad as WordPress has been. WordPress has had a ton of theme vulnerabilities. Remember, themes are, at the end of the day, code, and code have vulnerabilities. So if you have themes that do really cool stuff, you might also have some really cool vulnerabilities as well. So again, contributed themes, contributed plugins, just be selective, try not to just use all the things, try to think about what you're actually installing, and if you have themes and you're not using them, get rid of them. Again, if you have a team of experts, luckily in your company, which most people don't unfortunately, there are way too many organizations to count that do code audits, that do code reviews, that will do penetration testing. If you're in a place that you're able to budget something like that, I would highly recommend it. It'll be the best money you've ever spent. Don't just disable a theme or a plugin. This seems super unintuitive. Plug-in code that's sitting there dormant and theme code sitting there dormant, if the vulnerability affects it in such a way that I can call a file or somehow otherwise manipulate PHP to call an object in that file, which again, there's crazy stuff you guys wouldn't believe. If that code is sitting there, I might actually be able to execute that code and then use that vulnerability in that code to then escalate privilege or gain data access or whatever else. So if you're not using a plugin or a theme, get rid of it, don't disable it. Disabling it does help, but it doesn't do enough. Open source, open SSL, heart bleed.  So if this is a corporation with billions of dollars flowing through it and you are the Drupal admin, get a couple of bucks to have someone look at your code. So a few different things, security kit. Does anyone use security kit? I think it's a little bit unmaintained now. I think January might've been the last little patch to it. However, security kit has cool things. All right, I'm sorry, I'm thinking of another one that we'll talk about. I think security kit's still good to go. But cross-site scripting, cross-site request forgery, click jacking, and some man in the middle stuff. Each of these components has their own threats and their own realities and their own risks. Obviously we don't have enough time to talk about all these and what they mean necessarily in a grand scheme. Just know that security kit is here to help you and it's here to help mitigate those as risks.  Well, I support SSL and the browser will never, ever, ever again go to that site without using SSL. And what that means is if an attacker can redirect them to a site or part of the site that's clear text where they might've otherwise stolen data over the network or they may have stolen credentials, this won't let your browser do dumb things. Like you might click a link and do a dumb thing, but your browser will say, no, no, no, this site's SSL enabled, I'm all using SSL and that could actually help. And that's just a check box in this and as well as you can enable it if you're writing custom PHP code. Duo, we do two factor, good. So Tiny IDS, this is the one I think might be slightly under maintained. I don't think there's any Drupal 8 builds, so maybe you might wanna be the new contributor to that and make sure things work. But again, simple things like Tiny, so IDS stands for intrusion detection system. It's often a network type security control. However, Tiny IDS will look at your logs and actually look at them to say, oh, that looks like someone tried doing cross-site scripting or that person looks like they tried doing SQL injection and maybe at that point you might get a little bit of a heads up that, hey, some people are attacking us, maybe we should block them with our firewall or block them with Cloudflare or whatever else. And then security review will basically just say, here's a bunch of things you should be doing for security, you are not doing these three things, you should fix those. And it's just a really quick litmus test that you can enable and all these plugins are free. Even do a security is free up to 10 users. So if you have 10 Drupal admins or less, you can use us free for that as well. All right, who's exhausted and hates me and thinks that I should do all the code odds for them for free? Yeah, no, I realize that.  Like this honestly will help your organization if you do this stuff. So it's not security theory, it's not making you feel good, it's not the once a month scan from McAfee. Like if you do this stuff, an attacker might still break in, they might find a vulnerability in your code.  Like that is the stuff you can control. You cannot control when there will be a vulnerability in one of the 100 plugins you might have deployed this year. So don't think about those things, think about here's all the stuff that you could do. Now try to pick some of it and work with your team hopefully. So layering security, a firewall won't do it, a security module won't do it, a patching won't do it, all those things together will help, right? So think of it holistically, think of it the big picture, think of the entire stack, not just one layer. Attackers will do really creative things that you would never believe. If you ever get to go to like a PHP conference and look at some of the talks just about PHP security, there are things in PHP that would blow your mind that could happen just with a couple lines of code. It's not all SQL injection, it's not all local file inclusion, there's crazy, crazy stuff. So consider that an attacker often won't go after the things you think they might attack. They actually might attack the things you never would think they would attack like your disabled themes and your disabled plugins. Don't forget that Drupal actually is really security forward. They're contrib vulnerability announcements, they're PSAs, they're security page. So get on those mailing lists, look at those feeds, interact with that kind of data as well because often times they're gonna be a good notice that hey, bad things are happening, we need to patch immediately. All right, do I have two minutes or five minutes? I don't know how, does it run 2-12 or to like 11-50? Oh, two o'clock, okay, great. Perfect, well then we have a couple minutes for questions actually for once. So there's all my contact details, I did wanna tell you that if you can handle more security and I think it's more directed towards actual coding security at this point, go see this talk at 2-15. There's two guys doing this talk I believe. So if you like what you saw here and like what you heard about, but maybe things like CSERF, CSRF doesn't mean anything to you or Christ like scripting is still kind of this nebulous thing, I believe they're gonna talk more about that at developer level which is great, great knowledge for you to have. All right, any questions? Sir? Yeah? Yep, so within MySQL you can actually do file read and write operations. You can actually, you could do a select statement that said select blah into file var www and if MySQL has privilege to var www somewhere, it can actually write a file out, the same thing. Anything that MySQL, the actual user in the Unix space of MySQL, anything that can read on the file system, you can then read through MySQL's actual code. So you can say file load and it will load that file if it's CSV file data or text data, whatever, it will load up and where that becomes a problem is, and since we have a couple minutes, I'll clue you guys in. There's a part of PROC, this meta file system, that when you're using PHP, it will actually have data that will display if you read it. And what one of the pieces of data it has is header data. And if I as an attacker in my browser change my header to be PHP shell, so like something like exact dollar sign underscore get command, I can actually put that in my browser headers and when I go and actually go to that web service, it will open up PROC and it will actually execute because it's reading PHP code, it will execute it and I now have control of that web service to execute commands as if I was the everyday Apache user for instance. Things like MySQL have vulnerabilities all the time, there are MySQL vulnerabilities, probably too rarely. One of my favorite is there was a vulnerability two years ago or two or three years ago that if you tried logging in as root on MySQL like 97 times or 170 times or something like that, really low number, it would actually have an integer overflow type problem and it would log you in as root. So when I say turn off MySQL support if you don't need networking, that's why. It's not because someone's gonna necessarily break in or brute force your password, there could just be a vulnerability that you had no clue could ever happen and that's the reason why we turn stuff off that we don't need. That's a good question. I'm not super keen on GreenSQL, I think in some instance and it depends on your deployment model. If you ran GreenSQL on the actual web server and then that had an SSL connection between GreenSQL and your actual back end MySQL, that's one way to go about it. Often I'm not totally sure though, but great question. Sir, there can be, you know 2014 like my iPhone has more power than my computer did like three years ago. So honestly encryption's kind of cheap, it's not as expensive as people think. Certainly if you have crazy scalability thing that I can't even begin to imagine, yeah you might wanna test that.  Yes, so let me qualify it and then I'll answer your question, penetration testing tools in general, if you don't know how to use them and you're not gonna spend the time to learn how to use them, you're probably not gonna get any benefit out of them. There are certainly tools that are point and click, like they just work, however, if you do wanna do this, which I don't think anyone should be dissuaded from ever trying to be a better security professional, always please set up a test environment. You'd be surprised the number of developers I've worked with over the years that like, oh yeah we tested against production and like the site fell over. I was like, why did you do that in the first place? So that's my thought on that. There's a Linux distribution called Kali K-A-L-I and it's a live distribution and you can just run it and it has just crazy amount of tools built into it. One example that you guys might wanna take a look at if you're gonna go down that road would be SQL map, so SQL map and SQL map, you literally point it at a URL and like a query string and it'll actually try to brute force to see if that query is actually vulnerable to SQL injection. And if it is, it'll be able to actually by itself say, oh I believe this is a MySQL server four point some version because of that I build this SQL statement like this and now it gives you code execution, credential dumping privileges and all kinds of other crazy stuff just by pointing it at a web server. And that's a really good thing for PHP developers because SQL injection historically has been a huge problem for us. So if you wanna test something like that, SQL maps a cool one. There's also Metasploit which is a whole exploit framework and it'll actually have a bunch of tools that it actually is all open source code and you can actually, it's Ruby based for what that's worth but it's all open source code and you can actually test known exploits very safely against your enterprise testing system. It's been made to be tested and retested by professionals. A lot of the exploits on the internet that you might see on a website or passing around like Pacefin or on Reddit or something, a lot of those haven't really been tested and sometimes bad things happen and also sometimes people put backdoors into them. So be careful if you ever take exploits off the internet just because something looks cool. We saw this happen with Heartbleed where people were testing sites with Heartbleed that people posted online to test and it was actually doing really bad things to their servers. So be careful whenever you're in that space, sir. Yeah, so basically the question is like if best practices would be keeping code out of file paths that could be accessed by the web server if you didn't need to have them there because if code's accessible by the web service bad things could happen, right? So kind of a simple thing for instance if you have something like HT access files where you do basic authentication to a certain part of your website those files should always be out of the web service route. Those should be getting read by the web server within the guys of I need to read this file. So as long as I have file privileges on the server I'm okay. The web server however does not need to give those files ever to anyone on the internet. So if you have files whether it's PHP whether it's configuration data if you don't need to call that code directly by the web server you might be able to get away by moving it out of the directory and then if you have to like change some file headers to point to a new path or something else. With Drupal however I'm not sure if there's like a project that goes two lengths to make that happen. I probably wouldn't recommend doing it yourself unless you really wanna spend time maintaining it because ultimately as soon as you start changing like include and auto require statements and all these other things you might start breaking stuff every patch upgrade and that's probably gonna be the security gains by not having those files there if you start delaying your patching I would patch before I worry about the other. I would just say like again themes, plugins you don't need to get rid of them if you have built in code with a package you downloaded from like GitHub or something if you see code you don't need to get rid of it but of course things like Drupal are based on this principle that hey the stuff we're including in core Drupal is kind of important so maybe not screw with that I guess but it's a good point though I mean that's the right mindset for sure. So do you mean like proper jails like Linux jail jails? Oh I see, I see. Yeah I mean historically that's had workarounds for attackers.  I think docker has the right the compartmentalization mindset of how docker operates and segmenting apps like that that's really interesting to me. You know I think that you know we used to take the approach when we didn't have VMs like oh every server should do one thing and then ultimately budgets would say no every server should do like nine things. Now we're to the point with VMs and you know Linux containers that we can then now again actually segment as much as we should segment and then between apps actually have networking between apps to say oh no this PHP app should never communicate with this MySQL server only this MySQL server that's pretty interesting to me but there are actual Linux jail opportunities the stuff that's built in in PHP is not that rigid. I did mention earlier at the start of my deck things like GR security will actually add some additional protections to what's known as CH roots or shroots which actually kind of limits that scope kind of what PHP is doing. So GR security might be something to look at but then also SE Linux or App Armor the mandatory access control stuff we were talking about those will do things like if you have code that's trying to access files outside of the web server file path it will actually through policy say no you're not allowed to do that so that's another way to kind of limit the availability of files or data after someone might breach out PHP app. Any one question? Yes.