----BEGIN CLASS---- [14:56] #startclass [14:56] Whee [14:56] Roll Call [14:56] Gaurav Sitlani [14:56] Kushal Das [14:56] Prajwal Gatti [14:56] Josh Bressers [14:56] Deepika Upadhyay [14:57] Ashwani Kumar Gupta [14:57] Sandeep Choudahry [14:57] Soumam Banerjee [14:57] schubisu, ? [14:58] Harsh Vardhan [14:58] Anu Kumari Gupta [14:59] Others can slowly join in. [14:59] bress, Welcome to dgplug. [14:59] Thanks [14:59] I’d like to thank the Durgapur LUG for having me. I’m really excited to have this chat, nothing is more fun that talking to a LUG group. [14:59] bress, As you can see, we now have less number of participants, as these are the folks who really want to do something :) [15:00] Sure [15:00] bress, if people have questions, they will !, you can type next and take questions when ever you want. [15:00] bress, stage is yours. [15:00] Thanks a bunch [15:00] I'll start with a bit of background, feel free to interrupt at any time, I'm happy to take questions. [15:00] I’ve been doing security for what feels like forever at this point. All of it has revolved around open source security. [15:00] I decided a long time ago that open source was the future. There were a lot of people who thought I was insane, nobody was going to ever pay for free software. [15:01] It sounds crazy now, but there was once a time when open source was the risky new thing. I have crazy stories about Microsoft from back then. I’m glad things are different now. [15:01] I’ve been working for open source companies since 2003 I think. Long enough I can’t exactly remember what the year was :) [15:01] These days I head up a group at Elastic (the makers of Elasticsearch) called Product Security. I deal with security features in the products as well as our security updates. [15:01] Security updates being bugs that also count as a security issue and get a CVE ID (like CVE-2014-0160). [15:02] I’ve been involved in a number of security groups for open source projects. I help out with a few still. I host a security postcast, I blog a lot. [15:02] I think security conversations on Twitter is the greatest thing ever. Pretty much everything I do seems to involve security. [15:02] I’m just going to keep talking, if anyone has questions feel free to chime in, otherwise you get to listen to my stream of consciousness ramblings. [15:02] So on to the topic of the day. Open source security. What is it, how does it work, why do we care. [15:02] I won’t go into details about why security matters today. Just read the news anywhere, everything is on fire all the time. [15:03] Something important to remember though is that open source won. Everything is using open source today. Your phone, the web sites you visit, your web browser. Everything. [15:03] Open source security can be tricky though. Not because it’s less secure or because it’s open. These problems exist in closed source too, it’s just not as obvious. [15:03] If you’re using a closed source tool you might not know if it’s using openssl. With an open source tool you can generally find out. [15:03] Most people won't find out, which is the problem. [15:04] I'm going to frame the conversation with a devops hat on. There isn't a huge difference anymore between system security and project (or development) security. [15:04] It's all becoming one big squishy thing. Which is exciting. Sometimes ;) [15:05] There is a lot of talk about what matters around security. What's important, what will matter, what doesn't matter. Nothing is very obvious honestly. [15:05] The single biggest thing I've seen though is just keeping everything updated. I don't just mean applying updates to your system. I also mean keeping whatever open source projects you work on updated. [15:05] There are few projects that don't rely on other components. [15:06] Sometimes we ship them as part of the tarball or binary. [15:06] Even if your code is amazing, if you have a bad copy of openssl in there, you're in trouble. [15:06] ! [15:06] Just like if you're running old versions on your operating system. [15:06] next [15:06] Do you think making the source open to all makes it more vulnerable? [15:06] [15:07] Heh, that's a great question. [15:07] A long time ago that was the argument Microsoft used against open source. [15:07] I used to say it makes it less vulnerable. [15:07] I'm willing to say it doesn't matter. [15:07] If you look at history, just becuase Windows was closed source it didn't slow anyone down. [15:07] Just because Linux was open source we didn't necessarily see more attacks. [15:08] Attackers are really good at figuring things out, closed or open. [15:08] I still hear this though. I think it's human nature to draw conclusions where none exist. [15:08] I can see the argument for closed source being more secure, as the bad guys can't look at the code. [15:09] Linus' law tells us open source will be more secure, but I also think that's been proven wrong plenty of times. [15:09] I read on some article that as Linux or any other open source project has large communities, they are more secure; but they didn't give any reason behind this statement. [15:09] We've seen bugs that are more than ten years old fixed in open source. [15:09] If all bugs were shallow I wouldn't expect a ten year old security issue :) [15:09] right [15:09] but the loop holes are more visible if the code is out. Though on the other hand there are more eyes on the code who improves its security [15:10] soumam007: I think that's a logical conclusion, yes. But I also have been around long enough to know that if i make a logical conclusion about something, it's probably wrong :) [15:11] I generally assume whatever I think is right isn't what happens, so I can at least throw out one possibility :P [15:11] :) [15:11] It's tricky to be honest. But I guess at this point, it doesn't matter. Open source won, it's everywhere. [15:11] Even Microsoft is one of the buggest contributors to open source now. [15:11] They just joined the OSI a few days ago IIRC. [15:12] So the real question for us is how do we manage our existing open source in a sane and secure manner. [15:12] And the answer is in the open source way really. [15:12] Things like standards and openness have been what drove the technology to where it is today. [15:13] Security isn't really any different. [15:13] There are various standards (not just compliance). Things like CVE IDs, CWE, CVSS, NIST standards, OWASP. [15:13] There is so much information out there it's crazy. [15:14] If you are part of an open source project and you're not giving security bugs CVE IDs, you should consider starting. [15:14] They're a nice standardized way to communicate with the outside world. [15:14] If you need help with this, let me know. [15:14] Thanks bress :) [15:14] I'm involved in something called the DWF project. In the past MITRE controled the CVE project, DWF is essentially CVE done the open source way. [15:15] We can easily give open source projects CVE IDs now. [15:15] And it's crazy but MITRE is adopting a number of DWF practices. Becuase open source is better :) [15:15] So anyway, back to my point about security and standardization. [15:15] Security is still a bit more exciting than it should be. [15:16] Which is partially the fault of the security industry. [15:16] We made a lot of things too hard. [15:16] We focus on perfect more than we should. [15:16] We like to say the good guys need to be perfect every time where the bad guys only need to get lucky once. [15:16] But the reality is we need to adopt more open source ideas. [15:16] If you're developing a project, make sure you can move fast. [15:17] How many open source projects spend months on a patch? No good ones :) [15:17] Deploying systems looks a bit like a Linux distribution. Make sure you have a minimal set of pieces, make sure they're updated, and make sure you know what's in there. [15:18] A lot of groups have zero clue what software they're running in their infrastructure. [15:18] This is a problem. [15:18] A lot of peojects didn't know they were shipping openssl until heartbleed hit. [15:19] So how we fix this can be a bit tricky though. I don't have great answers today. If anyone knew I suspect things would be fixed :) [15:19] I have a podcast where IoT gets picked on a lot. [15:19] There are still tons of devices running painfully old kernels. [15:19] There are plenty of systems running very old software. [15:20] There are lots of open source projects that require abandoned libraries. [15:20] This is what I think about all the time. How do we deal with this problem? [15:20] Even 5 years ago things moved a lot more slowly than they do today. [15:21] My suspicion is containers and sanboxing will be part of the story. [15:21] I also suspect there will be some things that will never be OK. If an IoT lightbulb is extremely inexpensive, why will anyone care? [15:21] Just throw it out and get a new one. [15:21] But that doesn't work with a pacemaker. [15:22] Today we treat the IoT lightbulb, a toaster, the pacemaker, and my Debian server exactly the same. [15:22] Which is nuts. [15:23] But if we think in the context of software, things get a little crazy. There are libraries that exist almost everywhere. There was a Dnsmasq advisory yesterday where Google found 7 security issues. [15:23] Dnsmasq is running on almost everything that exists today. [15:23] That's crazy. [15:24] That said though, the Dnsmasq crew did a great job. They released fixes quickly, Google had a great advisory. Everything worked the way it should. [15:24] But I bet my android tablet never sees that update. [15:25] I wonder often about how this could or should work. Today it's really up to a device manufacturer. [15:25] But I can update my desktop myself. [15:25] So it's a lot of double standards. [15:25] OK, it's the bottom of the hour. I'm going to pause for a bit. Any questions or comments? [15:25] Well, top of the hour for many of you :) [15:26] ! [15:26] next [15:26] ! [15:26] i didnt get you your android will not get the updates of the server [15:26] roll call: Yurii Pylypchuk [15:26] will you please rephrase? [15:26] soumam007: My android tablet. I have a tablet that was very inexpensive and has never received a system update. [15:26] I get app updates. [15:27] But it runs dnsmasq, and unless the manufacturer updates the android system, I never get that fix. [15:27] Nor can I fix it myself. [15:27] (I can't root this one, I looked into it) [15:28] This is pretty common problem for many devices. [15:28] and please can you refer to those standards ? [15:28] Actually they are new terms for me :) [15:28] Ahh, sure. Let me check on the next question and I'll come back to those. [15:28] next [15:28] ! [15:28] Can you tell us about Cloud security and what are issues most of us are unaware about it ? [15:28] sure [15:29] gauravsitlani: That's another great question. [15:29] To be perfectly honest, cloud security isn't drastically different than on-premise security. [15:30] But I think the gotchas make one think harder about what's happening. [15:30] Your infrastructure will be more internet facing in many instances. [15:30] So you should always assume the system you are setting up is secure against constant threats. [15:30] This should also be true of your on prem stuff, but many of us don't think like that. [15:31] I'm a big fan of something called BeyondCorp https://cloud.google.com/beyondcorp/ [15:31] The basic idea is you should push all security to each system (or endpoint). It's known as zero trust netowrking. [15:31] Trust no netowrk. [15:31] I would dare say cloud security is now just "security" :) [15:32] Does each node has its own level of security ? [15:32] That's the idea, yeah. [15:32] So you have to leverage things like single sign on heavily. [15:32] And automation for deployment. [15:32] It's painful at first, but without question a good long term investment. [15:34] I see many things moving in this direction, and I really do think it'll be amazing when we get there. But it probably won't be a smooth ride ;) [15:34] next [15:34] How big of a problem might those 7 security issues mean to, say, your android tablet? Like, I don't think I quite understand the magnitude of it. excuse me if this is a silly question, I'm very new to this [15:34] No no, that's a good question. [15:34] To be perfectly honest, I'm still sleeping well at night. [15:35] I doubt they'll ever be widely exploited. Exploiting bugs like that is really hard to do at scale. [15:35] It's the sort of thing that will be abused for what's known as a Tailored Access Operation. Where one group specifically targets another group or individual. [15:36] But my bigger problem is I can't do anything about this. [15:36] Even if I want to. [15:36] Someday there wil be a bug so bad you'll want to throw devices in a trash can. [15:36] haahhaaha [15:36] woah [15:37] What do we do when that happens? I don't have the answer. [15:37] I also don't want to scare anyone :) [15:37] But it's worth thinking about. [15:37] Something like heartbleed woke a lot of people up becuase suddenly they had to patch literally their entire infrastructure. [15:38] And that one had just enough bad so people paid attention, but no so much the world lit on fire. [15:38] I have a talk I'm working on about this. If you look at the history of humanity, we rarely fix anything until it's so bad it's on fire and people are dying. [15:38] We're not there yet with security. [15:38] I tried to do system update once and the phone was off , i had to take it to service centre , they repaired it but update wasnt done [15:39] Heh, right. That happens all the time. [15:39] Your lesson was "don't update my phone" :) [15:39] ! [15:39] next [15:39] exactly same :) [15:39] bress sometimes we don't realize the magnitude or even come to know that our system security or project security is at concern , as you said with crazy amount of information out there ,how do open source keep pace with updating security [15:39] Before they face heartbleed :D [15:40] OK, so this relates to soumam007's question about standards. [15:40] I woul dsay the biggest thing you can do is know what you're shipping. [15:40] Every project includes some source from somewhere else. Every project has dependencies. [15:41] Once you know what you're shipping, you can keep an eye on something called CVE. Common Vulnerabilities and Exposures [15:42] http://cve.mitre.org/cve/ [15:43] ! [15:44] Thanks , bress for elaborating, didn't knew about CVE's [15:45] Hi there, my home Internet just died. [15:45] Can someone paste the last thing I said? [15:45] bressers, you gave the link to CVE [15:46] Once you know what you're shipping, you can keep an eye on something called CVE. Common Vulnerabilities and Exposures [15:46] OK, thanks. [15:46] add: bressers [15:46] So the idea there is we should give every security bug a CVE ID. [15:46] That allows us to easily track and categorize these things. [15:46] Then we have other tools like CVSS, Common Vulnerability Scoring System. [15:46] That lets us assign a score to how "bad" something is. [15:47] A score above about 7 is considered bad. [15:47] A 10 is the worst something can be. [15:47] The idea there is we will have more CVE IDs than we can fix, so let's rank them. [15:47] Then we have a standard like CWE, which is Common Weakness Enumeration. That lets us categorize these CVE IDs. Then we can make note of what sort of problems are most common for us. [15:48] For example if you have a web site and you see a LOT of XSS issues, you know that's a place you can focus on fixing in the future. [15:48] Then there is the OWASP top 10. If you've not seen this, you should take a look. [15:48] Every now and then OWASP will make a list of the top ten most common problems. [15:48] Then they give nice advice what to do about it. [15:49] https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project [15:49] In fact we're in the middle of building a new top ten list. [15:49] And nobody want to agree on anything, as one would expect :) [15:50] And many of these things should be considered if you're a developer on an open source project, or a sysadmin, or even a devops guy. The rules don't change much. [15:50] the basics are still the basics :) [15:50] next [15:51] bressers, If I ask you to point out 10 things everyone of us should do, or should not do in daily computer usage. what are those 10 things will come to your mind? [15:51] OWASP did that for me ;) [15:51] I'm not sure I could come up with ten. [15:51] bressers, say 5? [15:51] bressers, for daily computer usage as linux/upstream developers [15:52] The single most important thing you can do is know what you're running. This is true of infrastructure, containers, applications. [15:52] There can be a lot of gremlins hiding. [15:52] And you'll never get your list perfect, but the journey is the reward. [15:52] Once you know what you have, keep it updated. [15:52] If you can't update, segment it away. [15:53] This is where zero trust netowrking is great, you segment everything. [15:53] Now in order to do these two things, you have to be fast. The days of having weeks or months to take action are gone. If you can't move fast, you're not going to survive. [15:54] And that's honestly the most important things anyone can do today. [15:54] If I could only pick one, I would pick fast. [15:54] If you can move fast, you can solve a lot of problems. [15:54] bressers, can you please explain "zero trust networking" a bit more? [15:55] That's the beyond corp thing. [15:55] The idea is you don't trust the network. [15:55] all traffic is over encrypted connections. [15:55] bressers: can you also explain segmenting applications? [15:55] You make all devices and machines authenticate to each other. [15:56] saptaks: Same idea. Everything exists on its own. So let's say you have a file server and a web server on the same netowrk. If they don't have a reason to talk, they just can't. [15:56] Everything has to have explicit permission to communicate to something else. [15:56] Basically there is zero trust by default. [15:57] saptaks: You can also take advantage of things like virtualizaton and containers to help sandbox certain applications and system. [15:58] A great example is lets say you need to manage an old router with IE6. [15:58] This is sadly a more common problem than it should be [15:58] You install IE6 in a VM. You only allow the admin to connect to it. And you only allow the system to connect to the router. [15:59] Ideally the router will only allow connections from that system. [15:59] As it's probably old and terrible :) [15:59] Okay. So suppose if a web server wants to communicate with a database and no one else, so we should have both in different networks and put permissions accordingly, right? [15:59] And not put them all in the same network? [16:00] The netowrk shouldn't matter. If you enforce TLS on the link and make it authenticate, the network no longer matters. [16:00] Of course if you know the IP address something is coming from, restricting access on that level is good too. [16:01] But with a lot of cloud infrastructure that's not always possible anymore. [16:01] I wouldn't say to purposely segment networks, putting things behind a firewall isn't a bad idea. [16:01] But we shouldn't assume because there is a firewall, everything behind it is safe. [16:02] ! [16:02] next [16:02] Would authenticating every move/message in the network add an unbearable amount of latency? [16:02] ! [16:02] [16:03] vharsh: There is overhead, yes. But it's not too bad honestly. New CPUs are good at offloading crypto and newer TLS versions are better about reducing round trips. [16:03] You need ot understand what your use case is and go from there. [16:03] Sometimes you need very low latency. [16:03] So you may not want encryption. [16:03] But then you can make such a trade off decision based on good data. [16:04] It is better to sacrifice some milliseconds for security anyway :) [16:04] Sometimes. [16:04] Not always :) [16:04] next [16:04] bressers, in your experience, what kind of problems do new open source projects generally face due to unawareness of these bugs? [16:05] I find they get overwhelmed when they get a securtiy report. It can be confusing and strange. Security people have their own language in many cases. [16:05] Nearly every time if you just ask them to help you get through it, they will. [16:05] If they won't, come find me :) [16:05] Most security people are decent these days. [16:05] bressers, thanks [16:05] You bet. [16:05] next [16:06] ! [16:06] next [16:07] bressers, for someone starting to explore security, what reading material do you recommend? [16:07] bressers, to understand the concepts and lay the foundation; [16:08] Twitter. There are a lot of great security people there. Things are changing really fast so it's hard to suggest good reading. Many of the books that used to be good are too old now. [16:08] Read what the security folks on Twitter suggest. [16:08] That's the future and the present. [16:08] bressers, thanks! [16:08] the security universe on Twitter is really good actually. [16:09] There are some pains there, but in general everyone is really supportinve. [16:09] Hey my other internet came back! [16:09] next [16:09] Awesome. Why don't we call it a day. [16:09] ! [16:09] bressers, maybe the last question :) [16:09] I'll idle in here probably forever [16:09] next [16:10] So feel free to ask anything anytime. [16:10] thanks man [16:10] bressers, Thanks a lot for you time. [16:10] Is knowledge of crypto a basic requirement to understand security ? [16:10] No, but it doesn't hurt. [16:10] At lest know what TLS, RSA, and ECC is for example. [16:10] Probably AES too. [16:11] Eventually you'll learn about it. [16:11] Even if you don't want to :) [16:11] :) [16:11] ! [16:11] Thanks bressers for this great session :) [16:11] You're most welcome. [16:11] Thanks bressers :) [16:11] next [16:12] bressers, i am new to open source developing , there i find a lot of test being written [16:12] i mean is the working procedure for checking security bugs same? [16:13] Security bugs are just bugs :) [16:14] I wouldn't think of it as being something totally different [16:15] ok :) [16:15] next [16:16] OK, done for real this time :) [16:16] bressers, Thank you once again. We will ask you questions in future. [16:16] I'll be around, feel free to ask questions if anyone things of anything. [16:16] Ending the session. ----END CLASS----