Developing a Security Mindset Practical Lessons for Pythonistas - Hayley Denbraver

Speaker 1: My name is Haley Dunbraver, and this talk is about developing a security mindset. And I hope to give you some practical advice for all Pythonistas. Let's talk about a security mindset and what it is. And I have excellent news for everyone. And that is that you have a security mindset already. You may just not be applying it to your projects. The idea here is that There are things that I do in my daily life that help me stay personally secure.

Speaker 1: But there are also things that I can do within my projects that are just good habits, good maintenance things that will help my project be more secure and you know they don't even have to be all that hard necessarily Now, how are we going to discuss security? If you'll allow me, we're going to discuss Security and security mindset with a bit of whimsy and mystery, and I hope you're all along for the ride. Now, this talk is going to feature some excellent guests And they

Speaker 1: are some of the luminaries of English detective fiction, Hercule Porrow, Sherlock Holmes, and Miss Marple Now, these are our Python detectives, and we're going to discuss some security concepts. through the lens of uh what we can learn um from detective fiction And the reason to do this is just to have a little bit of fun and uh to inspire some curiosity and I just really like detective fiction. So that's it. All right, so let's learn a little bit about our guests.

Speaker 1: Now, Miss Jane Marple is a bit of a busybody and she knows a lot, maybe too much, about her neighbors. She's often underestimated and she's always listening. She's thoroughly educated, but she's not officially trained. Excuse me. She's not officially trained, uh, nor does she have any official credentials, that sort of thing. All right. And then Ercule Poirot. Now he understands psychology. He believes in the predictability of human behavior. He's fastidious. He keeps his cards close. And he can spot when someone is pretending to be somebody they're not.

Speaker 1: All right. Now we have Sherlock Holmes. Now he observes minute details. He doesn't net he knows that you don't necessarily need to leave your home to dig up some interesting information. Which is very useful nowadays. He's a thorough researcher. He questions assumptions and he ignores rules when they don't suit him. So each of these detectives, we're going to have several questions for them, and we're going to use those questions to introduce some security concepts. and uh see what we can do to build our security mindset. All right, so the first question is, what do you know about your neighbors?

Speaker 1: And for this question, we're going to go to Miss Marple. She is up to date on the latest going on. She has an understanding of the general character of her neighbors, and she knows who associates with whom. She also is not hesitant to expose bad actors. And my recommended reading for this question is The Murder at the Vicarage by Agatha Christie. It will give you a good idea of how she understands her neighborhood and her little village in St. Mary Mead, and how it helps her solve a mystery. All right. And so by what do you know about your neighbors in security, I really mean do you understand the vulnerabilities in your open source dependencies?

Speaker 1: Now You can think of the open source libraries that you use as your neighborhood. This is the very first Python project I wrote several years ago, many, many years ago. And this is a dependency tree from that project. The little indicator things there are showing where there are potential security issues. So this kind of gives you a map and understanding of your neighborhood. And it's important to know what you're using, right? Now, we spend a lot of time in our code writing original code, writing code for ourselves, writing code specific to our project, and because we spend so much time doing that

Speaker 1: It can make you think that your original code takes up a larger footprint of all the code in production than it actually does. So you may think that like sure I have a lot of dependencies, but I've written a lot of original code myself. And so maybe the breakdown um where this circle represents all code in production. Maybe the breakdown is something like this where uh it's about half and half, something like that. Um and it's very natural to think of it this way, but you know, your mileage may vary and depending on the project Your code in production could really look like this, but it could also look like this, or this, or

Speaker 1: this. And what's significant here is that Any problems in um in production are problems for your projects. And if you are really precise and well thought out and stuff in your original code, but you don't consider this stuff. uh all of your dependencies, the known vulnerabilities in them, etc. Uh you have a fairly large footprint Of code that could be a problem. And it's not to say that open source is bad

Speaker 1: or that you shouldn't use these dependencies because it's A really great tool. And you know, we're Django Con. I love Django. But it's It's about keeping your eyes open and knowing when there are known problems. And uh Balancing your risk and reward appropriately, and just being aware if there is an issue and if you can fix it. So you above all just want to know the information. And that's part of why I like using detectives, is

Speaker 1: that You're really out to have all the facts and make an appropriate decision. So, anyway, let's continue. So what should you know about your neighbors? Well, you should know if any of the packages that you use have known security vulnerabilities. Additionally, you should know which packages that you use indirectly. So these are things that you are not going to pip install yourself, but they get dragged in. with the dependencies that you do pip install. That makes sense. So you should know what these are and you should know if they have any vulnerabilities.

Speaker 1: Then you can make a decision about remediation and uh whether you're okay with what's there. All right. So how do I keep track of all of this? And I recommend automating when you can. It can get really complicated and um You know, the dependency chart that I showed you earlier was for a very, very simple project. Something on a more enterprise scale is going to be a lot you're gonna have a lot more so I recommend automating when you can and I would recommend you check out um potential solutions There are open source and enterprise solutions that can help you do this.

Speaker 1: PyM has some security testing. Pyup. io is a Python specific thing and sneak. io has a free tier and they are compatible with Python. All right. So to summarize, understand your open source dependencies and remediate known issues. Use a tool to help you do this. There are open source options and enterprise options. Alright, so let's go on to our next question for our detectives. Are people who they say they are? Now for this one, we are going to go

Speaker 1: to Ercule Porro and Sherlock Holmes. And um They have a lot to say on the subject. And here are the things that we might learn from detective fiction. First is if there is an actor in the story, you should be suspicious of them. And second, um We can think a little bit about how we confirm identity. Now, in detective stories, it might be something like handwriting or mannerisms or how they look. But is there something more to that? Is are there other ways, right? You're gonna want to consider

Speaker 1: the importance of names, nicknames, and aliases when you're reading detective fiction. And for this particular question on identity and how do you know someone is who they say they are, I have the following recommended readings. And they are Lord Edgemore Dies after the and after the funeral by Agatha Christie. Although a murder is announced by Agatha Christie is another good one. And then by Arthur Conan Doyle, there is A Case of Identity and The Adventure of the Stockbroker's Clerk. And so If you're curious to read about mistaken identities, that sort of thing, uh, those are fun books.

Speaker 1: Now. So, when I ask about how do we know people are who they say they are, I want to talk a little bit about authentication and permissions. Now Let's turn to authentications first. So what should you know about authentications in Python? So first uh you should know not to roll your own off. Um there are people who get PhDs in cryptography and um You know, if you you should be using encrypted passwords and

Speaker 1: you don't want to do that yourself. Don't roll your own encryption your own authentication um use the tools available uh secondly don't store plain text passwords anywhere Don't store them in a text file in your computer. Don't store them in your um Chat with yourself in your Slack channel. Don't store them on post-it notes. Don't store them in the database for sure. Don't do it. Third, use two-factor auth on your personal accounts wherever you can

Speaker 1: and try to offer it for your project, for your users, if it's at all possible. And then finally with authentication, you should know that Django doesn't throttle user authentications by default. So you should use a complimentary tool to do so so someone can't brute force try to log in a ton of time. So something like Django Defender is useful in that case. All right. So, what should I know about permissions? And for permissions, uh that's basically Where you have a user and

Speaker 1: the user should be allowed to do the things that you want to allow them, but they should not be able to do things outside of that limited scope. And you need to be thoughtful about what permissions you need and how to apply them. And I would say first that you'll want to be as granular as possible. Granular is practical. It's always easier and safer to grant an additional permission than it is to try to revoke one. So if you have a user that finds that they can't do something they should do, they should be able to do, it's easier to grant them that permission than to Um, that's a better error

Speaker 1: than it is to grant someone more permissions than they should really have. That makes sense. And finally, I would say that with permissions, you're going to want to think about your permiters. And For that, I want to turn to the case of the speckled band. Now, this is a story by Arthur Conan Doyle, and um It features Sherlock Holmes. One of the qualities of it is that it is a locked room mystery. Basically, the door is locked, the window is locked. So how did someone die, right? How could they have been murdered if they're locked in from the inside?

Speaker 1: You know, so you have these perimeters that are known and protected. Um, but The solution to this case involves a perimeter that was not known and not protected and it actually involves a snake. So I think it is an excellent read. for Pytanistas who are interested in thinking about their pro the perimeters in their project and how you need to protect them and think about the permissions for those perimeters. So I I give that a recommend too All right, so to sum up, treat authentication and permissions conservatively.

Speaker 1: Don't roll your own off Be explicit about the perimeters in your project and apply permissions carefully. All right, so the next question that we have for our detectives. is should I trust this mysterious package? Alright, so we're gonna turn to Sherlock Holmes for this one. And Sherlock Holmes has some wild stories about things like this. There was once a case where a client received a package containing three severed ears packed in salts. In another case, a client received five orange pips and it turned out to be this huge threat.

Speaker 1: So a pip is a seed for fellow non-brits. It this story was uh one of two stories where the client died after seeking Holmes's help. So this mysterious package really was um Quite threatening and quite a problem. So no, Holmes does not believe that you should trust that mysterious package. All right. So , with respect to software security, I want to give you a brief introduction into injection, user uploads, deserialization, and typosquatting. All right. So first, let's talk about handling

Speaker 1: unknowns. There is a common saying that you'll probably hear, you know, not in tech, but wherever. And it's trust but verify. And I would say no, uh verify and then trust. Assume anything that comes to you from outside could potentially be compromising and act accordingly. All right. So let's talk a little bit about injection and specifically SQL injection. Now this happens when uh through some means, uh usually it's user input, something like that.

Speaker 1: Um A user is able to run raw SQL and they can get back information, they can delete stuff, it's uh it's potentially Really troubling. And something you can do to help prevent this is to write Roth SQL sparingly, if at all. It is a lot safer to use the Django ORM than to execute RaSQL queries. You can use RaSQL with Django. But RawSQL, especially RaSQL that is a string and then it's formatted using user input, it's particularly dangerous.

Speaker 1: It's just a a bigger risk than using the Jenga or M. So what I would say is that you should become really good friends with the Django ORM and know how to use it well. Additionally, if there are things you would like to do with the Jenga Orem, but it's not quite flexible enough or something like that. Using a different ORM and like plugging it in to Django is a better option than writing this RASQL. So I know I've worked on projects that have used Django

Speaker 1: and SQL Alchemy with or together. And that's a better option than Raw SQL. All right. And just in general, string formatting should be done carefully. It can sometimes pose a risk of injection or code execution. All right. So let's talk about user uploads and deserialization So when you're getting a user upload, you basically want to confirm that it is what you suspect. So If you if you're asking your user to upload a picture, you want to be sure that it's a picture and not say a script.

Speaker 1: If you're not careful with user uploads, it can leave you exposed to the risk of code execution. Now, um, serialized data is another way in which a threat can come in, and it's tricky because there's no way to know What the data is before you deserialize it. So if you deserialize something without being sure that you fully trust the source, you open yourself up to problems with code execution. So in this case, E. I don't like using serialized data for this reason,

Speaker 1: but you have to be certain about your source. Now, uh typosquatting. Typosquatting is another way that you could get a mysterious package from the internet, which Is a little terrifying. But my question for you would be: have you ever pip installed a package without checking its name? I know I have, and it's not a good idea. It's not a good idea. And that is because you could be subject to something like typosquatting. And typosquatting is when a malicious actor uploads a package and they select a name that is either like a typo

Speaker 1: of another package. Or perhaps it's uh not a typo but um like a natural guess for that package. And uh if people were to download it, um then Where if they were to pip install it and uh accidentally type the wrong thing or you guess what the package should be called, you could be using a malicious library. So to summarize, be wary of user inputs and uploads. Don't guess How do you handle sensitive information?

Speaker 1: And this is something that all three of our detectives have encountered. Through their work. Now, they all understand that information is valuable and sometimes dangerous. They tend not to reveal their hunches before the appropriate time They will explain their methods when it's appropriate, but not before. They don't always tell the authorities the full story. And they have discussed for blackmailers because blackmailers wield personal information as weapons. We want to consider the data that we are collecting. And using that comes from our users. And here I would give you the following broad advice.

Speaker 1: First, I would ask myself, um, do I need to collect that? Do I need to store that? And um being selective in this way protects you um because you can only lose you can only get hacked for the data that you have. If you don't collect and you don't store something , then you can't lose it, right? So just be thoughtful. Second, I would say that this is an area where it really makes sense to delegate.

Speaker 1: There are options both in the collection and storage of data to outsource this to groups that are going to be very proactive. about their security. And it makes sense for teams and organizations to consider when that's appropriate. Third, I would say that you want to give users tools that will help protect themselves. So this goes back to what I was saying earlier with two-factor authentication, giving your users tools to help protect themselves. Has can have a multiplicative effect. It's it's great. And then finally, just

Speaker 1: um a Personal point of view, something to consider is think about personal data like glitter. If I had a tuba glitter , I know that if I unscrew the cap and dump it on the table, that I am never getting all that glitter back. that that glitter will end up uh in places that I don't expect and that It can travel and transfer to different people and um It is not something you can undo. So to summarize, both source code and user data deserve careful consideration.

Speaker 1: You can't lose data that you don't collect. So the final question that I have is, are you up to date on your knowledge of Cigar Ash? And we are going to turn to Sherlock Holmes for this question. So Sherlock Holmes is constantly learning about his field. He's an experimenter. He is a knowledge sharer. He shares his findings with Scotland Yard. He is willing to do things in new ways. He's on the top of his game. And so this question really boils down to the importance of continued learning and forward progress. All right, so what does this look like for a software developer?

Speaker 1: So I would first say that security is a continual process. You are never secure and then able to like check off something from a list. New vulnerabilities are found all the time. New exploits and attack vectors are executed. And um you know, to stay security-minded, it's this continual process not only for an individual. But for a team and a company and on the industry level as a whole. To summarize that, security is never done. Good security is a product of continual learning and iteration.

Speaker 1: Oh, this is a summary of the talk as a whole. Now, I would encourage you to generally approach your code with skepticism. And This means just asking questions and testing theories and being willing to Find out that there's something you don't know about your code or that there could be a problem. Um, it's just kind of a a stance and a mindset, right? So we're going back to the security mindset. And this is part of why I like the detectives. They are curious and inquisitive and they are

Speaker 1: Um trying to do something positive and make the world better. Finally, I just want to say Thank you to tell you that it's been really great to be here. I wish it could have been in person, but I'm delighted regardless. One quick thank you to uh Noelle Cook for drawing these excellent Python detectives for me. And finally, a thank you to you and to all of the Django Con organizers who've been so flexible in this really weird year. So thanks so much for being here and I'll be hanging around the slack.

Speaker 1: So feel free to say hi.

Speaker 2: I think we're the stoop the uh promotion already

Speaker 3: Are you all enjoying uh Django Khan so far?

Speaker 2: I am.

Speaker 3: Yeah.

Speaker 4: It is weird, but yeah. We

Speaker 2: would prefer to be in post right now, but uh

Speaker 3: Yeah, no me too. So are most of you in Europe? Probably.

Speaker 2: I'm close to Israel.

Speaker 3: Oh okay, yeah, yeah.

Speaker 2: So Closer than the time zone.

Speaker 3: So I haven't been to a QA session yet because uh I woke up just for this talk. So I'm not sure how uh things have proceeded earlier. Uh but if anyone has questions, feel free to ask. Uh I also We'll be watching the slack occasionally, so feel free to shoot me something there. Uh but but yeah

Speaker 5: Uh I do have a question. Uh we said there's like not a checklist that we like make sure your project is absolutely secured and so on, but like Is there a checklist to at least start off? Like to see the basics?

Speaker 3: Yeah. So what I really meant by that is that you can't um it's not like you do security once and then you're good, I guess.

Speaker 5: Yeah.

Speaker 3: Uh because the code is changing and um new problems arise. But I think that it's gonna depend a little on the type of project and um your own personal risk tolerance. Um Uh so I really hesitate to give kind of a one size fits all answer to that. Um If that makes sense.

Speaker 5: No, totally. Uh I was just like wondering if there's like a source where we can search for uh useful uh tips to start like checking well is my Django project uh failing in that and that and that other basic uh security issues.

Speaker 3: Right, right. Um Yeah, you know, Django actually has pretty good documentation on security. I was impressed. Um So I would recommend giving a poke around their docs, um just because they they list um some good places to start. I also um I believe I cut it for time, but I think the links are in my slides, which I tweeted out, but I had um first a like Quick list of Python security tips and then a quick list of Django security tips.

Speaker 3: Um so That might be an interesting place to start because I had gone through the docs and had kind of pulled out um Ten things that stuck out to me, I guess. Uh so

Speaker 5: yeah.

Speaker 3: So if you want, you can find that link in the slides.

Speaker 5: Thanks. Did you send uh the that link somewhere? Uh sorry.

Speaker 3: Um so earlier in the Slack I had um Oh, you know what, I'll just drop it into the uh I can drop you a link to it, but um I linked to my Twitter earlier um that had a link to the slides.

Speaker 2: If you put it on the with the hashtag of uh DjangoPyCon DjangoCon uh twenty twenty I think it will be also uh be on in the uh Twitter uh in the Slack

Speaker 3: Right. Okay. Yeah, I can do that.

Speaker 5: Cool.

Speaker 3: Mm-hmm. Well, it looks like maybe they're starting up the next Maybe I'm wrong. Um, was there anything else? I'm uh really pleased. Um to virtually meet you all and um I hope you enjoyed the rest of Django Con. Uh uh

Speaker 5: Thank you.

Speaker 3: Mm-hmm. Now I'm gonna go back to sleep, but I'll uh distract you guys later. Take care.

Speaker 2: Good night again.