Talisman Security Testing with Harinee Muralinath

Welcome to the Test Guild Security Podcast where we all get together to learn more about security testing with your host, Joe Calantonio.

Hey it's Joe. And welcome to another episode of the Test Guild Security Podcast. Today we'll be talking about Harini, all about Talisman and Security testing. Harini is a security practice lead and product owner and core contributor to Talisman. She is currently co leading the capability functions for ThoughtWorks India. She joined ThoughtWorks over a decade ago as a quality analyst. Application security has been her passion since then and is striving for the best quality and delivery is an obsession. She has been conducting training sessions and workshops for security practices through delivery processes. She focuses mainly on defense security and is an evangelist for security practices and an agile delivery setup. Harini also is passionate about encouraging innovation and is also a recipient of Women in Corporate Award for Luminaries and Innovation. Really excited to have her on the show. You don't want to miss it. Check it out. It's no secret that the number and complexity of applications are growing, but what is alarming is that 90% of security incidents result from exploits against defects in software. The need for better application security has never been higher and Micro Focus Fortify is here to help. Fortify is the recognized market leader in application security and it is the most comprehensive and scalable application security solution that that works with your current development tools and processes. With Fortify, you can start security applications in a single day, including custom code, open source or commercial components and scale as your needs grow with an on premise as a service or hybrid implementation. Check them out. Head on over to micro focus.com app security.

Hey Hyruni, welcome to the show.

Hi Joe, It's a pleasure to be here.

Awesome. Awesome to have you on the show. But before we get into it, is there anything I missed in your bio that you want the girl to know a little bit more about yourself?

It covers pretty much everything professionally just outside of work. I love being creative. I have learned dance. I paint a little bit. So there are multiple things that I dab into. I may not be too great at them, but I like staying in touch with my creative side.

Very cool. So how does that play into security? I know you did get a award for innovation. Does that help you with innovating because you're taking disciplines from outside of security and maybe being inspired by them?

Probably. I never thought of it that way. But yes, innovation is something that I have always been craving for. I always think that there's a better way to do something. This particular award was Actually, for innovating in processes around building a culture of security in the organization and having the ownership and how do we build a community around it. So this was particularly for that. Yes, very cool.

So I definitely want to touch on Culture of Security because I think that's a critical piece or component that a lot of teams miss. But what got you into security in the first place? What drew you to security? Made you passionate about it?

That's a very good question. Actually. I was kind of thrust into it to begin with. So I joined in as a quality analyst. And there were multiple. There's so many disciplines in quality analysis itself that you can touch upon. There was this startup that my company wanted to work with and they were building an E commerce website. So one of the most important things that was getting built was a payment integration service. And of course, that kind of sparks the whole idea of what happens to security. So that is where I was brought in. And I was thrown a challenge, you know, about getting an idea of security starting from scratch, learning how it works, and then implement that. And I learned it a really, really hard way. I realized that security is so vast that you can just get into any area and it's a rabbit hole after that. And it's too late that you realize that, oh, there are like 50 other branches of security that have not even explored. So I realized that, and that was the time that I also felt that I do not want others to go through this. And there must be a structure to learning security. There must be some way that someone who is starting off with security, there would be a way to explore which doesn't overwhelm them too much. And that is what got me into security and just building communities and thinking around it.

So I admit on the show that I am a newbie to security testing. So you just mentioned that there should be a structure, a way that people can start off to explore security. Do you have any tips for people that I think Scrum teams, again, ask to do more and more things, one of them being security. How does one learn security? It seems such a big topic that a lot of people seem to shy away from.

Yes, it is.

And I think the first. First thing to conquer there is to give up on the idea that it's rocket science. It has always been someone else's responsibility to think about security, you know, but the industry is really shifting away from that now. Security is very much a part of quality, and that needs to start from the very beginning. It starts from the point that you even think about what a product is going to look like and thinking about or breaking down into features, requirement analysis starts right there. So the first thing that I think people need to shun is the whole idea that security is not my game. It's too tough, there's nothing that I can do about it. And as long as we are able to work, you know, by shunning that mindset, the next piece would be to understand the scope of what you are getting into. Because security is that vast, it's really like testing. You know, we used to have these water polish methods where QA's used to sit separately and it was someone else's job to think about testing. It's the same thing with the security as well that has been there for the longest of time. And getting that into the DevOps process means that you need to understand what is the scope of quality, which involves security. And I really like the idea of threat modeling if people try that out. There are of course many, many ways of doing that too, but it at least gives you some kind of a scope. You know, it doesn't look infinite then. And then breaking that down into digestible consumable units and understanding how a developer could contribute to that, how a QA could contribute to that, how a business analyst, pm, client, product owner, whoever it is, can contribute to that, that just really narrows it down to practices that every role should follow. And that just makes it easier to digest, you know.

So when you talk about threat modeling, I assume who does the threat modeling? Would you say if a tester was embedded on a team that maybe they could just try to do some threat modeling and then bubble up that this is a concern? Maybe we should think about it in our sprint, how we can make sure we're covering security or our code from a security perspective.

Yes. So I think threat modeling has been a security professional's job for the longest time and it makes sense because they a flav they bring in a very in depth analysis from their experience as well. But if we approach threat modeling in an iterative fashion, if we are able to think of threat modeling to also exist in the agile world, this is very much a place where every role can participate. There is a great article by Jim gumbly on Martin Fowler.com which talks about how threat modeling can be agile and it can be iterative that way the few things that you need to take care of is that there are enough handbooks or there are enough templates that can guide the team to perform threat modeling. There would be of course some few vocabularies that people need to be confident with. There would be a minimum set of understanding of what kind of vulnerabilities or threats or attacks can happen. But having said that, there are quite a few methods of doing threat model. One of my favorite ones are stride, which I think fits very well with agile threat modeling. And if we are able to get to a point where we do it iteratively and we do it as frequently as possible, and as long as that gets into your story, backlogs, your test scenarios, your requirements, it can be a success. And it doesn't have to necessarily be a security professional doing it. It can be a tester who does it, it can be a developer who runs it, it can be a who runs it as well. And I think as a tester, it's a great tool to get insight on what kinds of test scenarios that you need to be looking at, what kinds of acceptance criteria you need to be handling and get that feedback early on so that the development that happens happens around it. So getting involved in threat modeling for QAs or any role in that team, I think is a great idea.

Great advice. Now you did mention earlier that security is not rocket science. Is there like a checklist someone can have that helps a team, like something as simple, low tech as that?

I prefer talking of checklists at practice level. I really believe that if we understand the practices that we need to be following, it drives the other checklists, which would probably be custom to the project that you're handling or the context that that brings in. Because any other checklist that I would give always be context dependent. But practices are something which is, which are more independent of that, you know, and that can be followed by just any team. So I prefer thinking of checklists at a practice level.

How do you get teams start thinking at a practice level though? You did mention culture. So how do we get the teams to embrace this type of security type culture where they are all contributing and making sure that within their context that they are covering security. And you do a lot of sessions and workshops. So is there anything that comes up all the time that you see teams struggling with security wise?

Yes, I think one of the key things that I think people try to find a way with security is they want to dump tools, you know, they want to just dump tools into the problem and they want to get that get sorted. And I think while that is not a bad idea to get yourself a safety net, that's not all that you need to do. So so many times my participants would just want to list down the different types of tools which are there and what to do with them and how can they get that rather than actually dab their own hands into security? It could also go back to the mindset of getting too nervous about touching something which might have a high impact. But I guess the fact that because it can have a high impact, because it can get really severe, it means that it needs more attention than just tools. And there is only so much that tools can do for. You need to be able to get beyond that and not just go into these sessions to just list down how to get these from outside. Because security really, really lot of context. It really needs to understand your project well. You cannot just replicate something that you have learned in, let's say another project or another application and see that that will exactly be the same problem in this one. So you need to understand your architecture very well. You need to question everything that you see and you just need to secure by default. That is a very, very important learning that people need to take back with them.

Nice. So switch of gears. I know you said it's not about tools, but I wanted to talk a little bit about Talisman. So I guess what is Talisman?

So Talisman is a tool which actually started off being just a tool pre commit or a pre push hook which would check for secrets so that they don't accidentally get checked in. That's where it started and then it grew from there. And today it also has a CLI tool utility where you can run a scanner on a repository. So it actually gets down to your git history, it looks at your commit which have been there and it tries to scan and tell you if you've ever probably let out a secret or you've checked it in, or maybe you checked in, you realize that you did and then you reverted it without really cleaning your git history. So it can still be brought out from there. So Talisman actually does that also for you. So it is essentially a tool that basically is to safeguard ourselves from consciously not checking in secrets that could just harm our clients at any cost. That's. That's what it is.

What do you mean by secret? Is it like someone actually checking in a valid username and password, things like that?

That's a good question. Because secrets could be beyond that. Secrets could not be this at all. So it depends on multiple factors. It depends on which environments we are talking about. It depends on what is a secret for my project. So secrets could also be your API keys, Secrets could also be your server keys, it could be authentication Tokens, it could be PII data. So personally identifiable information. So all of these things are healthcare data. Right? So there are many types of secrets and sensitive information that could be there. This essentially Talisman essentially looks for a certain pattern. So it checks for entropy. It checks for keywords like, you know, RSA tokens or API tokens and, and things like that. It also checks for encoding, you know, so it checks if there are, let's say, base 64 encoded values, or there is something which crosses a certain level of Shannon entropy. So it would actually report to you by checking on all of these different validations that are there.

So this sounds like this is a must. Most teams use a tool like Talisman, or is this something you think most teams lack?

It is a must. Many organizations actually enforce using this tool or any other, you know, equivalent which monitor secrets from getting checked in. They enforce it at an organization level, but it also lies as a responsibility with the developer and the QA to not move away or find workarounds from using it. Practically speaking, and I understand this very well, that anything that stops you from checking in or deploying, people get an urge to bypass that, and it's pretty natural. I've been there too. In fact, my colleagues, Suhas Dinesh and other maintainers of Talisman are constantly grappling with making the validations to be stronger. And at the same time, the usability should remain easy and it should get even easier. It is a tough balance to strike, you know, at a product. But as a developer, qa, tech lead product owner, whoever we are on a team who are handling secrets, we should recognize the responsibility that we have and understand that such tools are aids, not enemies. This tool, for example, helps you keep your coat safe from further breaches. Loss of secrets could actually lead to a lot of disasters, and having to go through such monitoring is a smaller price to pay in lieu of that. Especially in the current situation. With the advent of the Coronavirus pandemic, many people who are stuck at home, they're using their personal laptops for coding. And it becomes, becomes all the more important in this kind of a situation to be careful of how you're handling your code, how you're handling your secrets, and use such tools to come to your aid?

Great. How did these tools work? Do you plug it into your, like, CICD pipeline and with your CLI command line that somehow can be called to make sure that before it's actually pushed to production or to the repository that it has been scanned, or if it does find a secret, it Denies the build or the check in.

Yes. There are two ways you can use Talisman. The first one is as a pre commit or pre push hook which sits on a developer or QA's machine to ensure you do not even accidentally check in sensitive information and secrets such as keys, credentials or actual credit card numbers. And all this prevents such information from even getting into VCS to begin with. So this is the most ideal place and the most ideal situation that you can have. And the second way of using it is that you can use it as a scanner on your pipeline by using the CLI utility that it provides. This is to monitor that if someone who was not using a tool such as Talisman and checked in Secrets, the scanner will still run and it will capture such misses by looking into the git history across comets. Since this is a static analysis tool and you do not really need an environment where the application has been deployed on, you can execute Talisman really early on. You can run it as soon as the code is checked in. So if you, let's say have a pull request based mechanism, you could hook it in as a test to be executed before the PR gets accepted. So it becomes a mandatory step at that point. So this way a code with secrets won't even get merged and it would be just an easier way to clean such changes from history.

Cool. So I guess another thing is with false positives is reporting being able to see what's a real issue. What kind of reporting does Talisman give give someone that uses it?

If you're running Talisman as a pre commit or a pre push hook, well, it's something on your command line itself that you will see because it'll just block you from checking in, right? So it'll throw an error right there or your ID wherever you're using your integration from. For scanner, there is another open source project called reportmine which we have integrated with and it has a very pretty HTML, CSS, JavaScript, the usuals. But it has been. It is something that we we can customize with our project so that we have just integrated with a report mime and that just gives you a very detailed report on which commit Sha's. Did you see the the commit go in with the secret and so you can actually get into.

And fix your issue if you would want to. It actually also tells you that how many occurrences did they see of a certain secret that got checked in and it lists down all the different various commit where all it exists so that you can clean it up from each one of them. And you can make sure that it's not there when it goes further from here.

Cool. So are there any other features or functionality of Talisman that I didn't mention or that we should know about?

Yes. So we have built a few extra things like in the scanner itself, we have brought in the possibility of defining your own regexes. So when we have got something called Talisman Run Configuration, you can tell Talisman if there is a false positive while you're checking something in and it caught and it blocked you, you can tell Talisman that this is something that I know is not a problem. You know, you might have. It might have failed one of your checks. But I've, I've ensured and I have reviewed and I know that this is fine to check in. So you can actually set that up and run configurations. On the other hand, if you want to be a little more stringent, if you want to see that there are these kinds of regexes which are possible because I have actually got tokens around which follows this kind of a regex, or I have got secrets around which has got this kind of a regex, which probably Talisman Core doesn't really test for. You can add your own. So let's say you're a tech lead on a project and you know that there are certain kinds of secrets that you're handling and you want to make sure that everybody is checking for that. You can actually put that regex into Talisman as well and you can make sure that the Run Configuration checks for that. And it would fail if someone tries to check in a secret with that regex. So we also have that built in.

Okay, Rini, before we go, is there one piece of actual advice you can give someone to help them with their security testing efforts and what's the best way to find or contact you or learn more about Talisman?

My piece of advice is going to be look into threat modeling for sure, because that would open up a lot of areas and would actually help you understand security in the context of what you're building. And try and go from there and break it down into sizable chunks that you can digest. Try and understand where you need to outsource it to other people who are probably professionals who can come in and help you at the right time. And to reach out to me, I'm there on Twitter under the handle of Harini M I.e. h A R I N W M. I'm also on LinkedIn. You can find me there. I work for ThoughtWorks, so you can look for Harini Muralinath and ThoughtWorks and you can find me there too. And if people want to reach out to Tal for Talisman. Talisman is an open source project so feel free to leave an issue. If you see something missing, please please contribute because that's how open source projects live. And if there's anything that you want want to reach out to us for, then Talisman maintainersoughtbooks.com is the place to be.

Thank you Harini for your security testing awesomeness. For links to everything of value we covered in this episode, head on over totesttestguild.com S23. And while you're there, make sure to click on the Try Today link under the Exclusive Sponsor section to learn all about Micro Focus Fortify, which is the recognized market leader in application security. So that's it for this episode of the Test Guild Security Podcast. I'm Joe and my mission is to help you succeed with creating end to end full stack testing awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Security Podcast. Head on over to testguild.com for full show notes, amazing blog articles, and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.