Security Doesn't Have To Be a Nightmare

RubyConf AU 2023

Wiktoria Dalach

@dalach

#application-security

#security-best-practices

#ruby-on-rails

#web-security

#data-validation

Security Doesn't Have To Be a Nightmare

by Wiktoria Dalach

Wiktoria Dalach's talk at RubyConf AU 2023, titled "Security Doesn't Have To Be a Nightmare", provides insights into building secure products by integrating security considerations into the software development lifecycle. After transitioning from a software engineer to a security engineer, Dalach shares her experiences and practical tips to help developers manage security without it becoming an obstacle to innovation.

Key Points Discussed:

Common Security Issues: Dalach highlights the frequent scenario where security checks are initiated late in the development process, often leading to increased workloads and delays. She emphasizes that security should not be an afterthought but integrated from the start.
Sanitizing Input: A crucial first step in securing applications is sanitizing user input to prevent script injections. Dalach underscores the importance of this practice, especially in the Ruby on Rails environment, which offers sanitization tools.
Database Protection: Validating data is essential to protect databases, which are critical assets. Dalach notes that loss of data can have a significant negative impact on user trust.
Credential Management: She stresses the importance of keeping sensitive credentials out of repositories, recommending best practices for scoping API tokens to prevent potential breaches.
Security Scanners: Investing in dynamic and static application security testing (DAST and SAST) tools can help developers proactively identify vulnerabilities. Integrating these tools into workflow systems like GitHub and GitLab can streamline security efforts.
CIA Triad: Dalach introduces the CIA triad—Confidentiality, Integrity, and Availability—as a framework for categorizing security concerns. This helps teams focus on specific aspects of security during development.
Shifting Security Left: A key takeaway is the concept of shifting security left, meaning incorporating security practices early in the design and development processes rather than at the end. She motivates attendees to proactively involve security teams during the planning stages.

Conclusions:

Dalach closes her talk by reiterating that engineers have a responsibility to build secure products, emphasizing that it should be a defining quality of modern engineering. By encouraging proactive engagement with security, she believes teams can foster a collaborative atmosphere that eliminates the dread traditionally associated with security compliance. Attendees are urged to adopt the CIA questions in their projects to ensure safety and integrity throughout their development processes and to stay informed about potential vulnerabilities.

00:00:00.000 We're not live yet because our next speaker is going to come from the internet. Wow, there we go! We've got our live feed from Melbourne to Berlin and back.

00:00:05.700 So, Selena, have you heard the cyber security joke? Michael, focus! Cyber security is no joke.

00:00:18.660 Oh, I've got one though! Why should software architects never design high-security fences? I don’t know, Selena. Why should software architects never design high-security fences? Because they will make them highly scalable!

00:00:43.800 Our next talk will show us how to build secure products. You will learn how to design with security in mind, so that security isn't a blocker, but an enabler for innovation. Wiktoria Dalach is a software security engineer, a writer, and a YouTuber. Be sure to hit the subscribe and notification button now.

00:01:16.400 She's organized over 30 workshops for web users, a community she co-founded in 2012, and she's a Rails Girls mentor. Yay! We've got some Rails Girls folks in the audience.

00:01:31.040 Now, even though she's right here on screen, we don't know if she’s alive, but given all the workshops and mentoring she does, I bet it's a skill she possesses. I heard that when you approached her about pairing, she ran away and said, 'I’m remoting in on this session.'

00:01:42.660 Well, pairing with me might be a nightmare, but security doesn't have to be a nightmare! Please welcome Wiktoria Dalach from Berlin.

00:02:09.840 Okay! Now it works. Is it okay that I don’t hear the crowd? Sorry! So, hello. I am so sorry that I'm bringing you a remote conference experience. I tested positive for COVID on the day of my flight, so trust me, I wish I was with you in this room.

00:02:21.120 But let's not talk about my health; let’s talk about security. So, imagine this: it's Monday, the last sprint of your project, and you think you've just had the planning done. You have two bugs to fix and documentation to finish. You feel great and excited for the release, looking forward to the next project coming up. It’s Monday, but you feel good!

00:02:49.080 On Tuesday, the engineering manager comes in and says, 'It would be great if we could run this project through security.' You know when they say that, 'it would be great' actually means 'we must do it.' You go to the meeting with the security team, and oh my God! They ask so many questions. They are so annoying, asking about documentation that hasn't even been finished yet.

00:03:32.519 After the meeting, you realize you can forget about the two bugs to fix; it’s now a whole bunch of other things to handle. I've been in this situation way too many times! Every time, we would agree at the retrospective meeting to assess what went well and what didn’t. We always said having the security check at the last sprint is just not a good idea.

00:04:15.840 Yet, the minute we finish the meeting, we forget about it and move on, and the same problem happens in the next project. Does this sound familiar? I hope it doesn’t! I cannot hear your response, so it's funny.

00:05:02.880 Who am I? Yes, you know my name. I'm originally from Krakow, Poland, but I'm based in Berlin. I've been working in tech for over a decade as a software engineer. Two years ago, I made a slight transition in my career and joined the security team.

00:05:42.240 By the way, all the notes and everything I’m talking about now will be under this link, which will be available in a few days. Please remember this link; you don't have to make any notes right now.

00:06:01.919 During my transition, I learned a lot because I stayed in the same company, but I had the opportunity to experience work from a different perspective. I had very productive meetings as a software engineer with my peers, and collaboration was happening. Then I switched roles; I became a security engineer, and suddenly I became a stakeholder. It completely changed the dynamic in communication, which was a very interesting experience.

00:06:55.500 Today, I would like to share with you the low-hanging fruit of security with a twist. I will focus on very practical tips and share a piece of theory that I believe will be completely transformational for your relationship with security.

00:07:34.139 Okay, so let's talk about sanitizing input. This is important. You never want to trust your user with what they are sending you. You need to sanitize input, meaning you should clean up the data you're receiving from them so they cannot inject any scripts into your website. In the Ruby community, we are privileged because we have sanitization helpers. In Ruby on Rails, we have a gem called sanitize, which makes sanitization pretty easy.

00:08:55.680 Sometimes, you want to allow your users to style their blogs or descriptions, but you still want to prevent them from injecting scripts. That’s the first step, which is basic. The second step is to validate the data. You need to validate everything that goes to the database because remember, the database is your biggest asset.

00:09:55.200 If your system goes down, people may forgive you to some extent, but they will never forgive lost data. If users log in and all of their posts on Instagram are gone, that is a major issue. Therefore, you must protect your database by validating the data you get from users, especially for legacy views and models that have been around for years.

00:10:48.420 These low-hanging fruits are pretty uncontroversial. The next point is no credentials in your repository. I know what you may think: 'For testing, it's okay.' No, it’s not okay for testing!

00:11:10.040 Two things: first, when you create an API token for any provider, you cannot scope those tokens often. What may start as just a testing token can eventually become a token that has power over all your projects in that CI account. That’s a problem. Always scope down your tokens when you can.

00:12:01.740 The second issue with testing credentials is that as programmers, we are often lazy. Over time, you might think, 'Oh, I used this token for testing in one project. I can use it in another project,' and it gets out of control. Sometimes security researchers find those testing tokens, and if found by a malicious actor, could render the whole project unable to be developed or deployed.

00:12:36.839 Therefore, don’t put credentials in your repository. There are many ways to store your credentials safely, and security and secret management is a fascinating topic, but this presentation wasn’t big enough to cover it.

00:13:39.120 The good thing here is that you can delegate as much work as you can to machines, which requires you to talk to people in your company to purchase the products, but it's totally worth it.

00:14:04.380 There are scanners that will test the security of your applications for you. Two popular types are dynamic application security testing (DAST), which communicates through the front end of your application, and static application security testing (SAST), which analyzes your code base.

00:15:09.600 What’s great is that you can integrate these into your workflow, whether in your GitHub pull requests or GitLab. They will scan only the committed changes and show potential vulnerabilities or issues that need attention. There's a lot of pressure on developers to deliver high-quality software, and using these tools can help you remain productive and make security a priority.

00:15:56.760 So, think about investing in these scanners if your organization is growing; they are a must!

00:16:11.160 Okay, now I need tea, because I feel like I’m running through this presentation.

00:16:20.150 Let me share something I learned during my transition from software engineering to security engineering, which absolutely blew my mind. There are two problems I see with our approach to security. First, product people, designers, managers, and owners see security solely as an engineering problem.

00:17:16.180 On the other hand, software engineers can become so focused on delivering an MVP that we tend to shelve security features, labeling them as nice-to-have. This is problematic because we often overlook the importance of security in our projects.

00:18:07.980 Security is a huge topic; it's an ocean. You know much better than I do that there are many threats, and it can be daunting not knowing how many attack vectors exist in your application!

00:18:51.960 However, there is hope. I believe all these threats can be categorized into three categories: confidentiality, integrity, and availability, also known as the CIA Triad.

00:19:32.220 So, let's establish what CIA means: confidentiality is about keeping secrets, integrity ensures we get what we expect when accessing data, and availability means that we can access information whenever we want.

00:20:13.500 By organizing our security concerns into these three buckets, we can better deal with the vast ocean of threats we face. We can start by asking how the CIA triad of our projects might be compromised.

00:21:04.500 This fundamental question can help guide our security efforts, making it easier to navigate this complex topic without feeling overwhelmed.

00:21:53.880 For each aspect of the CIA Triad, we need to ask separate questions. For confidentiality: Who can see these results? How do we store credentials? For integrity: Who can create, update, and remove a resource? For availability: Is this endpoint rate limited?

00:22:46.620 When should you shift security left? In traditional software development, we follow a linear progression rather than a cycle; usually, we have to engage with security very close to release. Shifting security left means moving it to the earlier stages of your project.

00:24:12.960 During design, you should engage with the security team by asking these questions. Addressing potential security issues during design saves you time, cost, and effort compared to making significant changes at the last minute.

00:25:01.680 Injecting the CIA questions into your project meetings will make security an obvious priority. This way, you and your fellow designers and engineers can identify problems in your designs. Make it a part of your standards and templates.

00:26:06.600 Trust me; the more you engage with security, the easier it will become. This can foster a less stressful, more enjoyable approach to security.

00:27:04.880 There is no week when we don’t hear about another data breach or vulnerability found in a library that we all depend on. I urge us all to earn our engineering label and understand that the careless times of moving fast and breaking things must end.

00:27:57.699 As creators of technology, we have a responsibility that impacts people’s lives at an unprecedented scale. Building secure products is a fundamental aspect of being a great engineer.

00:28:51.059 I hope you will use the CIA questions moving forward! Thank you for having me. I wish I could have been there with you; it feels lonely here. Please reach out to me on LinkedIn or Twitter. Thank you very much for having me.

00:29:44.099 Thank you very much, Wiktoria Dalach, Jenkins Australia! You're Polish, just to give you feedback. The whole huge room here was laughing with you, laughing at your jokes, and we all loved the Spice Girls reference. A lot of people are going to come out here and shift security left!

RubyConf AU 2023