Hello everybody. Thank you for attending my talk. My name is Audrey Long and today we're going to talk about keeping your enemies close and your secrets closer. So a little bit about me. I'm senior security software engineer engineer at Microsoft. I have my master's degree in cybersecurity from the Johns Hopkins University. I have my bachelor's degree in computer science from the University of Cincinnati. I'm a diversity and inclusion ambassador here at my job at Microsoft, and I like to play pc games. Some fun facts about me I'm a moderator for korean food forum and I think a hot dog should absolutely be classified as a sandwich. So let's get into the crux of this talk. Today we're going to be talking about security tooling, and this slide demonstrates some of the repercussions of not practicing good security hygiene. Data breaches, unfortunately, are not uncommon. There are around 30,000 attacks on websites per day, which a data breach can have a significant effect on both a company's public image and their customers welfare. Many of these are easily preventable by introducing secure code hygiene into pipelines, and it's a serious issue with a total cost of $6 trillion worldwide, which was sourced from 2001 study of cybersecurity ventures. However, credential scanning could be a potential solution that we can easily introduce into any kind of pipelines environments, both development prod testing and any kind of pipeline really to ensure that we have secure code hygiene before reach of production, let's talk a little bit about some common security missteps. Stored test passwords can allow an adversary to glean significant information on password structure and requirements. Not practicing secure development can also generate more openings for adversaries, which could include finding out significant information about your system and finding those passwords that we accidentally add into public repositories. Storing sensitive information in open source repository, though, can lead to insights from malicious activities because they allow for adversaries to see how the code base functions and which vulnerabilities can be exploited. Reuse of passwords is also very common, especially in IoT devices, so we need to make sure that we scrub any of those configuration files before we accidentally publish those to any kind of open source repository. Trying to tack on security at the end of a project is unfortunately very common. However, we need to be more vigilant about shifting security to the left during the requirements phase. If we shift in early enough, we could hopefully mitigate against a lot of these bad hygiene practices that we see so much in open source and in projects worldwide. Let's talk a little bit about resiliency. How do we improve the security of our applications? By adopting an adversarial mindset. This can help tease out prime attack vectors and entry points into our applications and systems, build countermeasures, and develop mitigation strategies to address and identify risks. We could use threat modeling exercises as an example to help tease out these risk factors and develop mitigation strategies. Sometimes this is left off of the developers table. Unfortunately, however, I think that we can be more vigilant in including these practices in any kind of DevOps environment. We also need to build countermeasures and develop mitigation strategies to address some of the identified risk from threat modeling activities, and we could do that also in a Devsecops continuous integration and implementation strategy. We also need to implement security tooling available as to remove accessible secrets and make security easy and accessible. A lot of the times we see security as very difficult and stringent, which makes it so developers don't like to introduce some of these hygiene and best practices into their pipelines or into their development strategies. So we as security engineers, or just engineers in general, need to make security easy to use and easy to understand. So it's not just something that's burdensome for anyone to take on any kind of security tasks. We also need to integrate security practices at the beginning of the project lifecycle. In the long run, baking in security is going to be way more cost effective than tacking it in at the end. So why is this important to my team? So my organization close here at Microsoft is comprised of many software engineers compared to security engineers, and I know here in the devsecops world that's very common for others amongst security engineers. Both software and security engineers need to have some understanding on how some of the industry best practices are leveraged within each organization so that we can both be on the same page. There is a need for tooling which should be easy to understand and easy to use for developers. The tooling also needs to be modular so they can be swapped in as they are created and updated. And modularity is also very important not only for security, but for devsecops and for software engineering best practices as well. Lots of the times we see libraries and modules go out of date, we need to make sure that we're using the highest and the most stringent modules that we can find. Security is also dynamic, so we need to have scalable and dynamic solutions as well. But sometimes solutions are hard to research, hard to create, and definitely hard to maintain. There's two areas of software insecurity, and they tend to be very siloed without much explicit understanding between the two. To remedy this, we as a security field need to shift left both in the requirements phase as security engineers to inhabit the software engineering space to better understand and work directly with software engineers and the projects that they work on. These learnings could tend to lead to discovery and prevention of attack vectors within software projects. Now let's talk a bit about developers. So what exactly is developers? Essentially, it's the addition of security layer over the normal DevOps pipelines, so tools that take the place of the SEC portion of developers can be created to address many security concerns. With the development process, we can ensure that developers don't allow secrets gaps in their pipelines by implementing such tools early on in their development phases. We also can allow for the ability for continuous monitoring and fixing those pipelines whenever we find any kind of mitigations against any type of alerting that happens throughout these observability features. Due to its automated nature, it can help address risks without significantly impeding development. And that's the beauty of Devsecops. We are continuously improving and continuously developing new practices. This allows for continuous enforcement of good security practices throughout development. Devsecops is a step in the right direction to bridge the gap between security and software. However, more needs to happen. Is there a single tool that can handle all security scenarios in any kind of DevOps pipelines? No, there isn't. There is no single tool to cover all the bases. Many tools are needed to cover all the scenarios. Static code analysis dynamic code analysis infrastructure as code credential scanning container scanning, open source scanning. The list just keeps going on and on and on, especially when we keep continuously maturing in the way of development and of security. However, my team and I have created and we'll go more into this and a demo later on into this. Talk about a tool, the detect secrets tool. Now, first and foremost, I don't want to sell a tool. That's not what the point of this conversation is about. The point of this conversation is to showcase that we need to scale and make dynamic tools depending on our scenarios and with our customers, what they need. And making easy harnesses to better adapt and grow tool sets throughout when we need them and plug and play them when we need them as well, is really important. So what my team and I did is we wrapped Yelp detect secrets. So Yelp was an open source tool which could find any kind of secrets within the code base, and we took that tool and wrapped it with an Azure DevOps open source visual studio marketplace extension. And we did those for a few reasons. First and foremost, we did it to make it easier to integrate a credential scanner into a Azure DevOps pipelines. And we did it to ensure that the coding and integrity within our development crew was always going to have credential scanning to snuff out any accidental secrets that were going to be included into the code base. Open source reliability, which allows quicker detection of shortcomings in the code base as well. So not only do we need to find proper tools for the job, but we need to understand the tooling vulnerabilities to configure them properly into the code base. Too many times a security engineer will unbox a tool and just let the default configuration do the job. Is this good enough for security and for our developers? I don't think so. Before we get into the demo, let's talk a little bit about the reusable architecture of the code that was created. So my team and I have created a reusable foundation to plug and play command line scanning tools that are needed throughout many projects that we work on. So the need to be scalable and dynamic is crucial for success. So we work with many different customers throughout many different engagements or projects throughout the year. So we always need to be vigilant about what tools are out there and what we can create quickly and easily for our customers and developers to use. The need to be scalable is very important, especially dynamic. The overall tooling architecture here reads as follows. The first and foremost thing we need to do is we need to do some research over some tooling, figure out which is the right tool for the job. A lot of the times there's lots of tools out there. There's new tools that get released like every week it feels like. So we need to figure out which tool is going to be best for us and our customer, then we need to grab the inputs from the configuration file. Having a good understanding on the optimal configuration to run a tool is really important. I don't want to preach to the choir, but there are a million and one ways to run a tool, especially if there's so many different command line arguments that you can give it. So understanding which one's the optimal one for you and your crew would be really important to figure out. And then we need to execute the desired scanning Cli so that we do get that optimal solution. After that, what our tooling and foundation does is ingests the scanning report and it converts it so that it's easily ingestible by the Azure DevOps pipelines dashboard. And then we generate a report based on those results so that we could also look through it easier instead of seeing it spit out on the command line, for example. And then another thing that we did that's really novel and interesting in this talk is craft the pipelines code to easily introduce those findings into the Azure DevOps backlog. So this one's really important because a lot of the times you will see pipelines perhaps break or fail, and we sometimes don't get around to fixing it. Well, we kind of gave you an option here to include it into a backlog so you could see what jobs also failed, why it failed, and always have a record for you and yourself to review later on. All right, let's go a little bit into the demo now. All right, so here is the detect secrets credential scanner that my team and I made. It's a visual studio marketplace extension so that we could easily ingest it into Azure developers pipelines. And that was kind of the, a lot of the customers that we work with like to use Azure developers pipelines. We also work with GitHub a lot, but in this scenario, we couldn't find a really good free, in this case credential scanner to be used for a customer that really needed it in a jiffy. So that's kind of the use case and the purpose of this project. And like I said before, I'm not trying to sell you a tool here. Instead I'm trying to sell you an idea, which is we need to make scalable tools that can be easily ingested into pipelines so that we can progress and move development crews further along instead of pushing them back. So for this credential scanner, as I said, we wrapped Yelp detect secrets. And the overview isn't really much to see here, other than the fact that this is just like a nice little landing page for anyone to come and actually download this tool. Right now. It's actually not available for anyone to download publicly. However, that will be changing here soon. Now, before I get into the tool, I really wanted to showcase to you what I'm going to be scanning for this tool demonstration. So it's called OASP webgoat. And I would highly recommend this website or this application for really anyone who wants to do some kind of tool discovery. So what this is is Oauth foundation. They have created this bad, vulnerable application, and it's a really great playground for us as security engineers also to kind of do some tooling testing to see what kind of vulnerabilities do some of these tools actually pick up. And owasp Webgoat is definitely one that I'd like to use as a nice little playground to test tools. And if anyone is looking for something else, I would definitely recommend using this to do any kind of security tooling testing. All right, now, before we get into it, I just wanted to showcase to you what the user inputs actually look like for this tool. So my team and I did a lot of research in all of the inputs for the tool, and from those research and that inputs we can determine what we actually want our users to be configured with. So that was kind of interesting in this regard to figure out what would be something that's really simple, a really simple UI, just for our users to really have a good understanding on how to use this tool without getting completely buried with a bunch of perhaps cumbersome information. So I'm not going to really go that deep into any of these configuration details other than the fact that we try to make it simple where I say, hey, where would you like the code to be scanned? Otherwise it'll default to scanning the whole repository, unless you wanted to just scan a certain section of the repository. We allowed a word list, which in this case is called, in older terms we called them blacklists and whitelists. However, we'd like to step away from that language and like to use more inclusive language such as allow list, disallow list, or in Yelp's case they like to use the word list to use as one of those allow lists. So we can skip over some of those false positives that any kind of tool will find. And that's really important to also include in any of your tooling if you decide to make them in the pipeline, because there will be false positives. Unfortunately, I've not been personally a tool which hasn't picked up on a false positive. If you definitely have found one, let me know. I'm really interested to hear what you guys have recommended, but if anything, also calling it a word list, allow list, disallow list. If there's anything from this talk you take, I hope it would be to help change that language because it starts with you. And we also gave an option to treat warnings or treat findings as warnings instead of failures. I think this is really interesting, as a security engineer to really allow our users to kind of skip over this. However, I think it's really important that we make our tooling available for any kind of person who wants to use it excuse me. All right, now here is what the output will actually look like once you run it into your pipeline. So for OWASP, we have about 150 secrets that are contained into this repository, which is another reason why I really like this repository, because it showcases also just how good some of these tooling can actually be. Sorry. Okay, now another thing about this tool, as you can see, is we ingested the reporting from the command line into this Azure DevOps dashboard. So we can see line by line, what actually was picked up from the scanner. And this is really interesting and cool to kind of see it like this, because we could go ahead and make bugs as well. So if you go up here, you could create any kind of a bug. So we could say this was for the demo, save and close it, and then it's going to just show up right in your backlog. Excuse me, so sorry. This is for the demo. Oops, I clicked on the wrong one. But whatever, here you go. And then it'll actually showcase you that. It'll link out to that issue that we found, too. So making sure that making a tool to give you that backlog report is really interesting and something that we found in our organization to be the most beneficial in regards to actually solving anything. Now, let's talk a little bit about some forward thinking. So smarter secrets detection through the use of more advanced scanning methods and algorithms, as well as security research, will advance and progress throughout the years. Advanced entropy engines to better generate streams which closely resemble secrets and more integrated security tooling are needed to make security easier. Machine learning models are also very significant to reduce the number of false positives detected. Simple models do exist currently. However, more robust models in the future will need to be made with more advanced learning so that we can bypass more of those false positives. Also, secure code pipelines would be integrated by default. Adding more tools to our security toolbox is also going to be very forward looking, and a lot of the times I do get on some of these engagements with really smart engineers, and I still don't see security being integrated into all the pipelines, which is bothersome. All right, let's talk a little bit about evolution. So, software and security need to continue to become a union, both on the development side of the house and the security side. There needs to be better integration between security and software at all levels of development. Security landscape is always changing, and as such, we need to be dynamic in our security practices. We need to develop and scale security practices, solutions and tooling to generate more secure standards across every single industry. Security research and findings are also very siloed from each other. We as a community need to do a better job at letting others know about some of the tooling practices and vulnerabilities that we've been finding within our projects. And that's it. Thank you guys so much for listening to my talk. Please connect with me on LinkedIn. You can see use the QR code or you can go to that URL. But thank you so much and I appreciate everyone listening. Thank you.