DevOps Cybersecurity 101 with Jason Mar-Tang

[00:00:01] Get ready to discover some of the most actionable DevOps techniques and tooling, including performance and reliability for some of the world's smartest engineers. Hey, I'm Joe Colantonio, host of the DevOps Toolchain Podcast and my goal is to help you create DevOps toolchain awesomeness.

[00:00:19] Hey, it's Joe, and welcome to another episode of The Test Guild DevOps Toolchain. Today, I'm really excited because we don't have a lot of material on security and cyber attacks and cyber ops and all these types of cyber security within DevOps. I'm really excited to have our guests join us today, Jason.

[00:00:33] Hey, if your app is slow, it could be worse than an error. It could be frustrating. And one thing I've learned over my 25 years in industry is that frustrated users don't last long. But since slow performance isn't sudden, it's hard for standard error monitoring tools to catch. That's why I think you should check out BugSnag, an all in one observability solution that has a way to automatically watch for these issues real user monitoring. It checks and reports real user performance data in real-time so you can quickly identify lags. Plus, you can get the context of where the lags are and how to fix them. Don't rely on frustrated user feedback. Find out for yourself. Go to bugsnag.com and try for free. No credit card required. Check it out. Let me know what you think.

[00:01:32] Jason Mar-Tang Joe, thanks so much for having me. Really appreciate it.

[00:01:34] Joe Colantonio Awesome. I think before we get into it, maybe tell us a little bit more about yourself more how you get into security?

[00:01:40] Jason Mar-Tang Sure. I've been in the industry for about 15 years at this point, and security was always interested me as a kid. I got fished by a friend and completely destroyed my machine. Yeah, he's like a check out this picture, man. I was like AOL days. And I was like, okay. And it was just a Trojan and just messed up my machine. And it always intrigued me that you could do bad things through mechanical means with computers. And as time lapsed, things just got more complex, more complex. So I had the opportunity when I was for first got out of school after my first job to get into the role of sales engineering and sales engineering is really focused on helping other companies solve security problems, in this case with tools. And as I've been doing that ever since, I've been doing it for since than 15 years. So I've seen a lot of different industry verticals, a lot of different tools, a lot of different problems, and a lot of different solutions too.

[00:02:37] Joe Colantonio Love it. I love that role because you speak, like you said, with a lot of people, a lot of different verticals. Are there any common themes you see like, oh, people still get this wrong? You're kind of surprised by it.

[00:02:47] Jason Mar-Tang I think the first thing that comes to mind is that from a security perspective, if you're playing a tech insurance, you're playing a what if game. And I think security teams have a hard time articulating, hey, this could happen. This could happen. We're at risk. We're at risk. But it hasn't happened yet. So everything seems cool and copacetic until something happens. And that's a common thread that I've seen throughout my whole career. And unfortunately, it remains.

[00:03:16] Joe Colantonio All right. You have experience convincing people then. So if someone's a developer and they're in the team, they're like, I think we should get security involved in our DevOps pipeline. What do they do to convince maybe their team or the management to say, yeah, we definitely need to invest in this?

[00:03:32] Jason Mar-Tang So it's tough actually. I mean, what I've experienced with developers. Developers are there to get their job done, which is to develop right and build things. The problem is, is that when we look at cyber security, cyber security is focused on what you hear called the CIA triad, the confidentiality, the integrity, and the availability of information. How it relates to development and development in general is that when security is not kept in mind, and to be fair, development is one aspect. Security touches everything. It touches infrastructure, it touches identity, it touches development, and applications. And when it's not considered in the pipeline or in the process, you can leave things or what I should say is it's almost like this. Like when you put on a suit, you tuck in your shirt, you make sure everything looks good and it's tight. It's almost like I put on the suit. But my tie's crooked. And it's not a huge deal, but it can become a big deal if not look correctly. What do I mean by that? Talking about exposed API keys or secrets that we just or saying, oh, it's not a big deal, I'm just developing. But if it makes it into production, attackers are going after this stuff because the development side is one portion of a larger attack kill chain that we call in the industry, and security becomes everybody's responsibility at the end of the day, all the teams I mentioned, including development and keeping that in mind, can go a long way.

[00:05:02] Joe Colantonio I guess maybe that's not part of the problem, but because you said it touches everything and development apps and infrastructure. Does anyone know that they're responsible for it? Is it just like this? We have a security team that handles it. It's out of my hands.

[00:05:14] Jason Mar-Tang Well, that's the thing. That's where the security team. It's always funny because I've seen so many different organizations. Security is often seen as more of a hindrance. And there's a very fine line between convenience being, I want to be super secure, but if you're too secure, the business won't be able to operate. But if you don't put any security controls or processes in, then the risk is very high. So you have to get to a middle ground. And that is the job of the security team is finding that middle ground. It's all about risk and risk acceptance. How much risk are we able to accept to make sure that the business can continue? Here's an example, Developers typically have a lot of privilege and need local admin rights or whatever to do what they need to do. But guess what? That makes developers the target like developers are going to because of the privilege and the power that they have. They're going to go after the developers because they know that they have access to certain things, or certain code repositories or certain privileges to say, hey, you know what? Joe does X, Y, Z. I'm going to send a phishing email to Joe and see if I can compromise Joe's credentials, because with his identity, the attackers can be you, and then they can get around and do things as you.

[00:06:25] Joe Colantonio So yeah, I mean, that's a great point. Like a phishing email. How do you like you can't really develop a phishing email? It seems like a lot of the attacks are not necessarily hard technology-focused. It's more like social engineering. And so you may have maybe you have great security, but like you said, you're talking to a developer that's a little gullible and that's clicking on a phishing email. So I mean, how do you even fight that?

[00:06:47] Jason Mar-Tang Yeah, there's a lot of thoughts on this. I've had some, CISOs say, we don't do phishing tests anymore because we know they're going to fail because I've been part of a breach where you had 30,000 employees. All it takes is one email. And then, the way an attack propagates is you get a beachhead and then you move laterally. You mean persistence. So all it takes is one. I'm not saying education is very important. This is why understanding that's why I say it's everyone's responsibility because just knowing that I have power and my identity actually means something to the attacker. It might maybe think twice before I click on that link. I think education is very important. You don't really train for other than like I tell my family, never click links, don't click links on, never give you information over the phone. Authenticate. Make sure you know who you're speaking to like that stuff matters and can go a long way because that can be the difference between an attack starting or not.

[00:07:41] Joe Colantonio Absolutely. So you did mention, secrets being leaked out, especially with developers sharing things like GitHub and these code repositories that are more open to people. How then can developers get involved with security and try to bake it in to what they're doing? Do they do as a development, or do they wait till after everything's done and then like, okay, let's put it in our pipeline? When we check in code, it does a scan or something.

[00:08:04] Jason Mar-Tang It's usually working in conjunction with teams. So the security team and it does determine of course on the organization you're working for. Typically the security team will want to get involved if they understand that there's risk and it becomes a matter of, hey, they're going to run maybe an audit throughout the pipeline to make sure that, again, secrets aren't just hanging out there. Hopefully, you'll catch it before it even rolls into production. If it's in production, it's like hopefully it's found at that point. And this is why continuous testing and auditing is very important. I guess to your question was how could the team think about it beforehand? And it really is doing little things like that. Like if you know that access is always key point wasn't intended. But yeah.

[00:08:50] Jason Mar-Tang But it is key, right. Because you can't get anywhere without the right access and you need keys to do that. So whether it's API keys, secrets, SSH keys or just your simple identity, making sure those aren't out there are really important. And you'd want to make sure, for example, you're using, of course, to stand like if you're in the cloud, you want to be making sure you're using some type of secrets manager, for sure. And that might also be coming down from a policy from the security team. Hey, if you're going to do this, use this tool. Make sure. What they can do is just keep in mind that it's important. It is part of their responsibility and work with the security team. Believe me, they're not there to make your lives harder. They're there to help the business. It may seem that way, but I promise you they're not.

[00:09:29] Joe Colantonio Yeah, I mean, that's a good point. I do speak with developers, once security gets into the pipeline, though, they start getting all these alerts and it slows them down, like you mentioned earlier. And then you said, they should be focusing on risk, but like, how do you mitigate then, when you have like 100 maybe alerts saying security issues, security issue, how do you know what's a real, what's the highest thing that they should attack to make sure that they're addressing it?

[00:09:53] Jason Mar-Tang Well, prioritization is always the name of the game with anything. And this is where shifting into the attacker's mindset as opposed to a defender's mindset will help with prioritization because when we look at how attacks are propagated, the attack, kill chain, the intrusion kill chain, the attack life cycle, whichever always comes up. And it's never just one thing. It's always a series of subsets that happen A, then B, then C, then D, then E. It's conditional. It's if then statements. If this and then that, if this and then that. So if we can start it earlier or mitigate risk earlier in the life cycle, the rest of the life cycle cannot come to pass. And that's how you can prioritize. And the only way you understand that is by running risk assessments, doing red team exercises, that sort of thing.

[00:10:45] Joe Colantonio Jason, you mentioned a few terms here. I just want to make sure people know what it is, especially as a developer.

[00:10:49] Jason Mar-Tang Sure.

[00:10:50] Joe Colantonio Just mentioned Blue Team.

[00:10:51] Jason Mar-Tang Sure.

[00:10:52] Joe Colantonio What is a blue team? What's a red team? Just set the stage for us. What did we mean by that?

[00:10:56] Jason Mar-Tang Yeah. Happy. So blue team refers to the defensive team. So we're talking to people on the security team. They may be working in the SoC the security operations center. And then, the SoCs, security operation center. Their main goal is to triage security events and security incidents and what happens accordingly. So it's all defending defending, defending, defending. The red team is actually attacking, attacking your own network and running these exercises with the lens of the attacker to validate whether or not there's risk and validate whether the controls and processes that are in place are actually working as expected. And the conjoined efforts of both blue teams and red teams. The offensive side and the defensive side is where this new term purple teaming comes up. Purple team is not a team. It's more referring to the efforts that both the blue and the red team when they come together. What you get when teams are working together because like I mentioned earlier, at the top of our conversation, security is a joint effort. It's not one person's responsibility. It's not like, hey, I'm developing this piece of the application and that's my job. No security ends up becoming because it's so complex and it touches so many things. You need a coordinated effort between folks. So the purple teaming mindset is defenders on the blue team, attackers on the red team working together to overall increase the security posture of the organization.

[00:12:20] Joe Colantonio Awesome. With that in mind, you did also mentioned you need to take into the mindset of the attacker. Should each different company then have a certain profile like why do people get attacked? I mean, I guess is it just malicious? Is it like if I'm an insurance company? I know they're trying to get this from a healthcare company. They're trying to get that. Is it just like general, here are the common types of attacks, or do I need to take into account what type of information my particular company has that may instigate an attack? I don't know if that makes sense.

[00:12:49] Jason Mar-Tang Yes. Right. So here's what I'll say. So it's multifaceted, right? And I hate the answer. It depends, but it really does. So for example, you're in healthcare. You're developing apps for a healthcare system. The nature of the business is going to be involved with personal identifiable information, PII, and the people and the patients that you serve. If you're in retail, you might be developing an app that is allowing you to sell your product online. If you're in manufacturing, it might be something else, right, related to actual creating something. Now, that being said, there's always information that we want to keep. Make sure that it's confidential so it's not being accessed by the wrong people that it's available, meaning that I can access the application. If things go offline, it's no longer available or that it's the integrity is kept the same. I joke about it. I always make this joke that you can't tell or I'm a short guy, I'm five four someone makes my file profiles six four. You're messing with the integrity of my persona, right? Now, you asked a question. Does it matter? It does matter. Just because information, the information might be critical to the business. So the common denominator throughout all of this is availability. This is where you see a lot of the ransomware attacks happening. Ransomware is indiscriminate to the industry. Doesn't matter if you're a casino. Does it matter if you're in manufacturing? Doesn't matter if you're in health care. If we lock out your systems and encrypt all your data, you cannot get anything done and you have to pay the money in order to get that back. And then they could do it again. So that's that's really damaging. Like that's probably like in my opinion, like one of the worst-case scenarios because it could just mean doom for your business. But also right when we look at supply chain attacks, look about what happened with SolarWinds. Now, you're developing an application and the application is used by thousands, millions of customers. You compromise the integrity of the application and the application gets rolled out. You've now compromised everyone downstream in your supply chain. It doesn't always necessarily have to do with your business. Well, it does matter with your business, but it doesn't necessarily mean for you. You need to think about. Who are you serving? Are you serving somebody? Who are your customers? Who are the customers of the business? And that needs to come into consideration too. And typically these conversations are being held by the security team. It's not necessarily the developers, but again, they are part of the overall program. And this is why when the security team comes to you and say, we need you to do x, y, z, we need to do this. It's this bigger-picture strategic vision of mitigating all this bad stuff that could happen is that's driving their conversation.

[00:15:30] Joe Colantonio Absolutely. So this might be another dumb question. And that is when you think of cyber attacks, you think of someone showing off or exposing someone. But I would think when I read things, a lot of times people didn't know they were hacked until like six months, a year after the fact, because someone has an opening in the somehow, I don't know, the harvesting information and in the background and then not being, how do you know if you're attacked? I guess the main question.

[00:15:53] Jason Mar-Tang Oh, man. Well, you're right that there's a lot of times you don't even know you're being hacked. We call that dwell time. Dwell time is how long are attackers hanging out in the network. And if I'm an attacker, I want to maximize that. I want to stay under the radar because I want to gather as much information, as much reconnaissance about the network as possible, because then I can-if I know that if I can map things out, I can plan a larger-scale attack. So, for example, if I cross the perimeter now I'm in, I do research and I see the developers have access to this. So I compromise a developer, I move things here, I can move my malware everywhere, push the little red button, boom, encrypt everything. And now, haha, payday for me. How do you know if you've been attacked? Well, that's one way of finding out. You turn on your machine and all your data is encrypted. By then it's way too late. This is where security teams try and continuously monitor. And now we're seeing a move into the industry to be proactive with security. This is exactly why it's continuous testing. Continuous security validation is becoming a new field and becoming so hot. Because if you can stop something before it even happens, you're being proactive about it. And if you know a gap, if you can identify the gap, it's better you find the gap than the attackers, because the attackers are not going to tell you. They're going to use the gap and they're going to continue to propagate. You can patch that hole a patch that, fill that gap sooner rather than later. I mean, you know what it boils down to, Joe? An ounce of prevention is worth a pound of cure.

[00:17:19] Joe Colantonio Absolutely.

[00:17:21] Jason Mar-Tang How do you know you're attacked? Bells and whistles. But we don't even want to get to that point. We don't want bells-Bells and whistles mean something's already happened. We're being reactive. Being reactive is tough. It's a losing game. You're never ahead. Being proactive is much better. But I'm not saying it's easy. It is hard.

[00:17:35] Joe Colantonio Yeah, absolutely. I guess, I'm just thinking out loud, how many companies are actually being proactive and how many of these attacks are, like completely avoidable because I think there are known vulnerabilities and certain software versions and they just need to upgrade and they're not being upgrade, like, what's the percentage of people if they just did? Like here are the known attacks. Have you just upgraded your software or whatever you would avoid 80% of this?

[00:17:59] Jason Mar-Tang That's hard to say. I mean, I can't give you statistics and I'll tell you why, because the things that you hear about in the news are just things that have been disclosed. I can't tell you how many times I've been involved with breaches or whatever, where it never makes the news. No one discloses. Unless they absolutely have to. And it's sometimes some type of regulatory requirement. PCI dictates if certain amount of accounts are compromised, you have to now let everybody know. And we're going to see more and more of that. So if you could repeat your question what was this? What was it specifically?

[00:18:30] Joe Colantonio How avoidable are some of these attacks? Just because I know there are known you go to OWASp top 10 known exploits, or there are known software versions that have known issues that you need to upgrade your software than to avoid it.

[00:18:43] Jason Mar-Tang Yeah. So it's interesting, right? Sometimes there's just gross negligence. You see a lot of that in the news. I'm not going to give examples. But sometimes it is close gross negligence where it's like, why didn't we just do basic security hygiene with things? And this could have been prevented. And that's what I mean. Like little things. If you gross negligence to me is little things led to big problems, if you fix the little things, you could have avoided a lot of issues. You mentioned OWASp, which I completely agree with. And that ends up when we look at the attack surface, is looking at that surface of applications, there's an element of that. You want to make sure again basic hygiene that you're not exploitable to those things. But we also need to be aware of other things, not necessarily CVEs common vulnerabilities and exposures. You hear of CVE blank blah, blah, blah, blah. That's referring to a specific point vulnerability that might or may not be exploitable in your network, but there are also environmental vulnerabilities. And what do I mean by that misconfigurations? That can be leveraged to, again, cross the perimeter and start attacks. So again, it's being aware, if you're developer being aware of these issues. I mean, if your listeners are of the mindset that, yeah, I want to do my part to keep the organization. That's great. Even that is going above and beyond because a lot of times folks don't think it's their responsibility. It's not my job. But you might have so much privilege and so much power. With great power comes great responsibility, right?

[00:20:19] Joe Colantonio Absolutely. Along those lines, then, because like you said, the attack surface could be everywhere. What tooling do you think people need to have in place at a high level? Is it like one tool that could take care of all this for you, or do you have to have certain tools for your infrastructure, certain tools, your developer, and certain tools for production? I don't know what the different types of.

[00:20:38] Jason Mar-Tang I wish, Joe, I wish there was one tool, but if that was the case, I wouldn't be in business, right? I mean, if you ever walked around the trade show floor, it's sensory overload. I mean, I go to a lot of security conferences, Blackhat, RSA, etc. and it's just like there are vendors everywhere. And then the reality is, is because systems are very complex. I mean, I'm sure the audience knows that it's very complex when you're in technology. There's never just one tool. Security is a program, and the program should align to the needs of the business. Like I said, if you're in healthcare, retail or whichever and it's protecting the business. Tip there are typical tools that I always see that security team is using. And it's not really so much. I tell you where again where it crosses over it crosses over into development with identity and access management. Again, the protection of those keys as well as the testing of the applications throughout the process. There are a lot of static applications security testing, dynamic application security testing. That's going to be an initiative. And there are tools to help with that to help speed up the process because doing it manually is always hard. But when you use a tool, the tools are meant as a force multiplier to the one to hopefully many more individuals on the security team to make sure that is happening in a quick amount. And remember time is of the essence.

[00:21:55] Joe Colantonio Right. So you probably get this all the time. Doesn't AI solve all this? I just have a large language model that knows cybersecurity, and I run into my system and it somehow knows all the vulnerabilities.

[00:22:07] Jason Mar-Tang Yeah. I mean, so it's interesting here at Pentera we leverage what we call orchestration or orchestrator, meaning it's our product will look at infrastructure and run penetration tests on the infrastructure. And it's dynamic meaning when a new clue comes in, they're like, hey, I found this sage key where I've access to now, all right, I compromised this identity. Where can I go now? This vulnerability on this server. What can I get? Remote code execution. And then can I do access? Now that's all of this automation can help. But you still it all it does is help. All it does is it again it's a force multiplier. It doesn't solve all the problems. Because who's going to make? Because at some point someone's going to have to make a decision. Are we going to do X or are we going to do Y? And those decisions require humans. So you can get to that crossroads quicker, but you're still there at that point. And then you have to decide, do I want to go this way? I want to go that way, and if I go this way or that way, what are the implications of that? AI can maybe tell you, and then you have to actually do, and then you get to the next crossroad, then you get to the next crossroad. So you're always hitting roadblocks and not a good term. Crossroads is a better term because you need to make decisions on risk. That's what security ultimately is. It's risk mitigation. AI will help you get to those decisions maybe a little bit faster. Automation will help you get to those decisions faster. It's great. But you still need teams to make decisions because think about it. If I need to do I need to go to this team. Maybe it's not black and white, maybe it's gray and there's always gray. There's always gray area in security and technology is always gray. So you need to talk about it. And we need to figure out okay what is the best case to move forward. And that's where again that balance comes. And the teams should hopefully be working with developers and the rest of the other teams to figure out what's the best case for the business. What's the best case for to mitigate risk?

[00:23:54] Joe Colantonio I don't know if you'll know the answer then if there is like an incident, like, do you know, like how to set up your team so they're able to respond effectively or quickly to a security breach? Or is it every culture is different? Every team is different on how they approach a security breach.

[00:24:09] Jason Mar-Tang Every culture and team is different. But usually, there are playbooks are like real mature organizations will have playbooks and a process that they follow. And this is where, again, it depends on them. Sometimes businesses will use third parties. They have a third party looking at all level-one incidents. And only if they can't solve that then they'll escalate to level two. But typically it follows a process. And that's where you see security operations centers. They're the ones that use your responding to these quote-unquote incidents that are happening when they come in like, oh, we saw this alert comes in what level? Level one analysts are coming. And so you'll have a 24/7 SoC and you have people working the day shift, people working the night shift. So you always have someone monitoring and looking and looking. And then if there's an incident things will then proceed and follow a procedure of when we get to this level, we have to escalate. With this level, we have to escalate. Or if it's like. Again, I hate using this, but it's true. Like we're locked out. Maybe all hands on deck at that point.

[00:25:06] Joe Colantonio Here's another random idea that came into my head. What happens if you have like, a Gunho developer and they download like Metasploit and they just run it against the systems? That could cause issues as well. I mean, do you see people are afraid to do security? It's like a pen-testing point of view because they get in trouble.

[00:25:24] Jason Mar-Tang Yeah. Big time. Yeah. Of course. Because again, the A in the CIA triad, the availability is always so important. So we get that question a lot because again we use automation when we run tests. And the question we get is how do we know you're not going to take anything offline? So I don't think I've been in any conversation when I've been here every three years. I think I've been in one conversation where that doesn't come up. And for us, our perspective and what makes our software and what we're very proud of is the ability to actually run tests safely. What does that mean? That means we spend a lot of time engineering our solution to be safe. We reverse engineer code and rebuild it in our system and the way we run exploits. We only include it if it's been tested and we know it's safe. So an example of this is developing exploits in user mode as opposed to Kernel mode. Kernel mode, you're going to cause kernel panics. We don't do that. If there's any chance of exploitation that will cause damage, we just don't include it in the tool. Now, as opposed to your use case, when you said, oh, I'm going to get Metasploit. Yeah, there can definitely be repercussions if you do the wrong thing for sure. And that is when we think of traditional penetration testing, traditional red teaming, that is definitely a concern and it's always been an issue and pushback. And for us, this is why, again, we're very proud of what we do and we try and work with security teams. Say, look, we can do this. You can use automation, but we've done it safely. And that's, again, what we push forward as a partner and this is what you get with us. But it's definitely a concern.

[00:26:53] Joe Colantonio Absolutely, awesome. It is kind of still near the new year. Do you have any trends or where you see the future of cybersecurity and DevOps going?

[00:27:01] Jason Mar-Tang Yeah, I think the AI trend is going to get even more this year. It's going to get even more. I mean, last year was a big buzz, and even when it started, we started to see reports of polymorphic malware, malware that actually was able to change based just on the AI. And that makes things very difficult for security teams because it just means that more attackers are going to be leveraging more speed and security teams are always, like I said, catching up and trying to catch up, and now they're moving even faster. So I think that's going to become a thing. We're going to see more AI-related attacks. I mean, it's an unfair bet to say we're going to see some major breaches because of course we are. And I wish that wasn't the case. But to answer your question, when it comes to development, I think that we'll see a bigger push this year of getting the developers in those teams involved, because as we move more towards a cloud, we always are stepping more towards a cloud, more towards a cloud, and that's where a lot of developers will play. We need to be more proactive with that. I think that this conversation is very timely, because I think that most of the people, or a lot of the people listening will at some point be involved with security, and hopefully they'll come back to this conversation and say, you know what? I do want to be involved with this because I can actually contribute.

[00:28:18] Joe Colantonio So, Jason, it sounds like you're doing a lot of cool things, especially with automated performance testing. And I think there's a phrase I saw on the website about continuous security testing. Can you talk a little bit more about automated security testing continuously, and how that fits into DevOps? What's that all about?

[00:28:34] Jason Mar-Tang Yeah, continuous security testing is really important because it allows the security team and the business just to be always be ready, always be ready. Are we ready for an attack? Are we ready? Because otherwise you're assuming and you don't want to assume you want to validate. So continuous testing is always like, I'm a martial arts practitioner, I'm going to drill and make sure I'm ready for a punch. I'm going to make sure I'm ready to be attacked by a tall person or small person, whichever. So if I'm always ready, I can be confident. And that's what we want. We want to instill confidence. We don't want to assume so, especially the continuous nature, whether it's within the DevOps pipeline or just within the infrastructure itself, allows the business to be confident and communicate clearly that our posture is in a good and ready situation. You asked earlier about the processes of responding to an attack. When you continuously security test your security team, whether it's a SoC security operations center, they're always ready and you know that they're going to follow the escalation procedure as it's expected. You you don't want to wait. You don't want to assume that's the value.

[00:29:38] Joe Colantonio Great advice. Okay, Jason, before we go, is there one piece of actionable advice you can give to someone to help them with the DevOps security efforts? And what's the best way to find contact you or even learn more about Pentera?

[00:29:49] Jason Mar-Tang I would say guard your identity with your life because again, your day will always go after you, even if it's just to get to the next step. Protecting your identity, making sure that you're not giving any information knowingly. We'll go a very long way. If you want to find me, I'm on LinkedIn, Jason Mar-Tang. I'd love to have a chat about security. I can talk about security forever. And if you want to learn about Pentera, you can find us at Pentera.io. Sounds like the band, but we're not the band. We're Pentera.

[00:30:23] Remember latency is the silent killer of your app. Don't rely on frustrated user feedback. You can know exactly what's happening and how to fix it with BugSnag from SmartBear. See it for yourself. Go to BugSnag.com and try it for free. No credit card required. And let me know what you think.

[00:30:44] For the links of everything of value we covered in this DevOps Toolchain Show. Head on over to testguild.com/p139. And while you're there make sure to click on the Smart Bear link to learn all about Smart Bear's awesome solutions to give you the visibility you need to deliver a great software that's Smartbear.com. So that's it for this episode of the DevOps Tool Show. I'm Joe, my mission is to help you succeed with creating end-to-end full-stack DevOps toolchain awesomeness. As always, test everything and keep the good. Cheers.

[00:31:14] Hey, thanks again for listening. If you're not already part of our awesome community of 27,000 of the smartest testers, DevOps, and automation professionals in the world, we'd love to have you join the FAM at Testguild.com and if you're in the DevOps automation software testing space or you're a test tool provider and want to offer real-world value that can improve the skills or solve a problem for the Guild community. I love to hear from you head on over to testguild.info And let's make it happen.