DevOps Chat: DisruptOps: SecurityOps, Disrupted – RSAC Edition

They say if you live long enough … Few things give me greater pleasure than seeing my friends’ well-earned success. Rich Mogull and Mike Rothman (along with Adrian Lane, Jody Brazil and Brandy Peterson) have been chasing a dream for more than a few years now: How to make the SecOps person’s life easier while bringing security into the age of DevOps, automation, agile, CI/CD and beyond. Say hello to DisruptOps.

I first interviewed Mike about DisruptOps a few months ago, when the company was just emerging from stealth.

Although the company is still in preview, it was one of hundreds of companies throwing their hat into the ring for the prestigious RSAC Innovation Sandbox. I’m very proud to report that it was one of 10 finalists selected for this year’s program. If history is any guide, the fact DisruptOps made the final cut is a good indicator of success to come. And well it should, frankly; this founding team has some of the most dynamic, talented and smartest people I know in the business.

I had a chance to sit down with Rich Mogull and Mike Rothman to discuss what is driving DisruptOps and what the disruption is all about. Have a listen as we talk about it from the executive view, the security admin view and the market view.

Also be sure to check out DisruptOps at DevOps Connect: DevSecOps Days at RSAC, Monday, March 4.

Rich is also on a panel at the event, as well as several other sessions at RSAC this year.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation. Enjoy!

Transcript

Alan Shimel: Hey, everyone. It’s Alan Shimel, DevOps.com, Security Boulevard, and we’re here on another DevOps Chat. It’s a DevSecOps chat pre-RSA special edition. Happy to be joined by two of my oldest friends in the security business, the –

Mike Rothman: Are you saying we’re old?

Shimel: Yeah, I am. [Laughs]

Rothman: Okay.

Shimel: Rich Mogull and one of my best buddies Mike Rothman. Rich, Mike – welcome.

Rothman: What’s up!?

Rich Mogull: What’s up?

Rothman: It’s great to be here.

Shimel: So – and I should mention Rich and Mike are cofounders of a hot new cloud security DevSecOps company called DisruptOps, and they’ve just been announced as a finalist in the RSA 2019 Sandbox Innovation – or is it Innovation Sandbox?

Rothman: It’s Innovation Sandbox, yes, Innovation Sandbox.

Shimel: And you guys are one of ten companies in there and, you know, you look back – I think there’s about 12 or 14 years of Sandbox now – when you look back at some of the companies who’ve made the finals and who have eventually won as well, there’s some pretty impressive companies that have gone on to do some pretty amazing things.

Rothman: There are and, you know, first we would like to thank the Academy for this –

Shimel: Yeah. [Laughs]

Rothman: – you know, great honor. No, we – obviously it really is a great opportunity for DisruptOps. It really is flattering and such a validation of a lot of the work that we’ve been doing for a long time, and we’re really excited to kind of talk about innovation within the context of security operations, because the problem is a lot of the security business has always been driven on, you know, shiny new boxes and blinky lights and fancy algorithms, and what we’ve done is we’ve forgotten about the core aspects of optimizing the daily motions that security operations people have to go through, and it’s become just a huge, huge problem. So our innovation is really gonna be painted from the context of how do we scale up a lot of the security operational motions that you need as you move towards DevSecOps where you really can’t have carbon-based beings in your pipelines; how do you really leverage automation in a much more strategic and efficient manner in order to meet your goals?

Shimel: Okay –

Mogull: Yeah, our name is far from a mistake. I mean there’s a reason we’re calling ourselves DisruptOps.

Shimel: Yep. I mean in disruption – and disrupt is, you know, somewhat of an overused term today across – not just in security but across everything in business. Everybody wants to be the uber of this and the this of that and disrupt, disrupt, disrupt, but let’s take that, you know, path for a while, Rich, and when we talk about DisruptOps there’s multiple disruptions here. One disruption is, as Mike says, we’re gonna disrupt the way security ops folks have traditionally had to operate, which is let’s face it, their life sucked, you know? It’s not easy being a security operations guy whether you’re in the cloud or on the ground for the last 20, 25, 30 years. It’s a lot like shoveling sand against the tide, right? So we want to disrupt that. But secondly, you know, there’s also a bigger disruption there, and that is in just fundamentally how we’re going to do this security. Are we gonna take the carbon-based lifeforms out of it? I don’t know if we ever take them all out.

Mogull: No, I mean – yeah, the way we sort of view it as that there’s a couple of things that change is being forced upon the security profession and how we operate, and a lot of this is obviously driven by cloud and DevOps and the speed that those operate on, and so the goal isn’t just to disrupt for disruption sake and to break how people are doing things.

Shimel: Yeah.

Mogull: You know, the real goal is – I mean the problem we sat back to solve, you know, years ago when we first started thinking about this was, hey, how can we enable like this skillset of traditional security people and let them get their jobs done in this new reality without them having to go back to elementary school again? And that’s where started under – you know, realizing how can we better integrate security into a lot of these other process but also add value to Ops and at the same time be reducing friction for everyone? And I know those sound like generic terms but it’s – you know, we’ve actually narrowed this down to some specific operational models and how we could, you know, embed this and use the technology of automation to support it, where when really it’s not about automating everything away so that you don’t need security people. It’s about making security people more efficient and getting rid of all the stuff where they’re not using their security brain. So, letting them focus on what they are truly exceptional at as opposed to all the other garbage that they have to waste their time doing on a day-to-day basis.

Shimel: So, let me play devil’s advocate – Jane, you ignorant. You know, that’s always what we hear is, hey, don’t be afraid of this change, of this disruption because we’re gonna make your life better. We’re gonna free you up from doing the mundane so you could focus in on higher-level stuff that makes you more valuable to your –

Mogull: No, no, no, no, Alan. Yeah, you nailed it on that because we’re not saying now you get to be a policy wonk; you are still a technology professional, at least for the ones that are dealing with things at the technology level, but for example, I’ve been doing stuff in Amazon for 10 years at this point hands on. I can barely keep up with what they’re doing and having to translate, like, my skills over to Azure. I know what the processes are, I know what needs to be done, but knowing exactly which API calls and which boxes to click and all of those little pieces of it, that’s the stuff that slows me down and impedes my ability to get things done.

So we’re not – you kind of actually hit a pet peeve of mine there, which is where in security there’s a lot of, you know, people that want to fully extract themselves away and kind of focus more on the policy piece, and that’s fine if that’s the route you want to go, but I love technology and I think a lot of other people do and still want to be more involved. So how do we actually codify that and allow them to bring those skills across, again, without them just having to reeducate themselves at such a low level because of all the differences working in cloud?

Rothman: If they –

Mogull: That’s only one piece of what we’re doing.

Rothman: – want to. If they want to.

Shimel: You just –

Rothman: And I think that’s kind of the point that we’re trying to get to. ‘Cause again, we talk to a lot of different people, a lot of different skillsets, a lot of different weight points on their cloud journey, and there are a large group of folks that don’t want to learn the innards and the, you know, kind of lower level cloud vernaculars. Rich said he’s having a hard time keeping up with that stuff. What they really want is a way to abstract out that need and be able to just say, “I need to close down open access ports or I need to make sure that I don’t have stale identity keys sitting around or that I don’t have buckets that are open to the world, and I don’t really want to worry as much about how I do that in AWS.” Right? They know how to do that in their firewalls, they know how to configure, you know, again their VPNs; they don’t necessarily want to translate that stuff to AWS.

So again, that’s another key requirement of an automation platform that caters to this next generation of infrastructure in the cloud. It’s that if you want to get into those innards you certainly can do that but you don’t have to. And again, we get back to a scaling thing, right? Every discussion that we have, whether it’s when we’re doing a public talk, whether it’s when we’re working with a customer, it always comes back to the inability to get the skills that they need in order to meet the requirement. I mean Rich and I were on a call literally an hour ago and that’s what one of the things they brought up; where can I find people to do this?

Rich’s answer of, “Oh, well, you’re kind of screwed…” you know, they didn’t love that, [laughs] but they appreciated the fact that we were honest with them.

Shimel: Well, good that’s _____.

Mogull: Those were my exact words too, yeah. [Laughs]

Rothman: No, they were. Without a doubt those were his exact words.

Shimel: Now guys, you know what? It’s Friday today – we tape this on a Friday – I went to the gym this morning at 6:30 and I was working out with a gal who often come – it’s like a boot camp class. This woman’s a recruiter for one of the big guys, Booz Allen, one of them, and she’s looking – she’s just looking for Python Hadoop developers in San Jose. They want to pay $240,000 a year and she can’t find them. She can’t find them ’cause – oh, because they need to be a US citizen because it’s Booz and they’re doing government work.

Rothman: I have no comment.

Shimel: We’re not gonna get into the politics of this, but she can’t find – and Python with Hadoop, that’s not – it’s not security – but that’s not exactly top-of-the-line developers today, right?

Mogull: Well, you know –

Shimel: They’re fairly run of the mill.

Mogull: We have a – you know, security’s been short–staffed for a long time.

Shimel: Forever.

Mogull: I mean, yeah, we’ve been doing this 20 years and first it was because nobody paid enough attention to us and then it was because there weren’t enough of us, and there’s now a lot of security professionals who are just overwhelmed on a day-to-day basis with just the daily operational task that need to get done in their traditional environments. And then all of a sudden cloud and DevOps get thrown at these people, and it’s not that they’re not smart – okay, some of them aren’t smart – but it’s not that all of them aren’t smart [laughs] or most of them and it’s not that they lack interest; they just don’t have the time. And to learn the skills you need to actually implement what you know is the right thing to do – let me give you an example.

Amazon, there’s the Center for Internet Security Benchmarks. They’ve got them for Amazon, for Azure, for Google. And if I look at the Amazon ones alone – and that’s where we spend most of the time on AWS with our – when I’m actually doing assessment work, to manually implement that in an environment, like you need to know a lot. I mean you need to know a lot in terms of how Amazon’s wiring actually functions. A security person should be able to look at that and go, “I understand these requirements. I know – you know what? Maybe I don’t know how to exactly work a security group but I know what the rules should be.” They need something to translate that knowledge and get the job done for them.

But then the other piece of that, the other part of the disruption – it’s not just carrying the skills over and the knowledge over, ’cause there’s – that skills and knowledge are there and the security people get it, they just get hung up on actually how to implement it – there’s the speed that it all operates at that’s disrupted the way that we have done security for so long, because we’ve relied on kind of just natural inhibitors in – you know, we’ve got the opportunity – things don’t change so fast in traditional infrastructure. So, we’ve got the ability to block and tackle, and it’s not that we’re getting in the way of people. It’s that our job is to manage risk and to manage risk you need to understand the risks.

You need to have time to go through those cycles, and we just don’t have that same amount of time with cloud and DevOps, I mean the world that the three of us having been living in for the past years, and so that’s the other piece of this is how can we level up security, not just in terms of bringing the knowledge over and the skills at that technical level but giving them the ability to keep up and doing so in a way that doesn’t interfere with Ops? And there’s some, like, really cool things that we’ve done on the feature side to help enable that.

Shimel: We’ll be talking about that in a second. So guys, you know, I analogize this to QA, right? DevOps and Agile and the whole CICD pipeline thing has really turned QA on its head, right? And if the security folks were the redheaded stepchild of this whole process, the QA folks were like once removed, you know? And their game has changed, right? How much of QA today is automated testing, right? You know, the QA people spend more time writing their scripts to run automated QA tests than they do actually running the test.

You know, the tests are all automated as part of that pipeline and it gets dumped right in deployment. I see a similar future in security. It’s more about kind of knowing where to put the screw rather than actually screwing in the screw.

Rothman: Without a doubt. I mean you want the machines to do what the machines are good at, but one of the things that I think is a – and it’s not even a misconception, but it’s a point of confusion when you say the terms DevSecOps. Is that – what we really have are two separate practices, right? There’s DevSec, and that’s a lot of what, you know, kind of folks have focused on thus far.

Shimel: That’s the shift left.

Rothman: Right, shift left. You know, that number of folks that are – that will be competing with or against in the Sandbox, you know, focused on the DevSec side. What’s really underappreciated and has been under tooled has been that SecOps motion.

Shimel: Well Ops is always underappreciated and then under-tooled. Right?

Rothman: Well, not by security people.

Mogull: Yeah.

Rothman: It’s just – you know, that’s – but it’s because this is a common motion, because now it’s a common motion from Dev to Ops and security is trying to figure out where they –

Shimel: Now it is. It traditionally hasn’t been, Mike. Right? The Devs are the alpha predators in this food chain or have been.

Rothman: Right now they are.

Mogull: They are now but they haven’t always been. I mean when I first started it was the DBAs, database admins back in Gartner days.

Shimel: Well that’s – and look where they are now. But that’s a whole –

[Laughter]

Mogull: But this happens. There’s cycles.

Shimel: We can talk about that on a different podcast. Yes, it all comes round and round, you’re absolutely right. But, Mike, to your point about DevSecOps, let me tell you – and I’m a security folk like you are but I’ve been doing this DevOps things a while now. Here’s my honest take on that; the whole term’s full of shit. There’s no DevSecOps. There’s DevOps. Security people gotta get with the program and work with DevOps, right?

Putting Sec in – and I’m as guilty of it as anyone ’cause I’ve been doing it for five years in RSA – we put Sec in because too many security people say, “I have nothing to fucking do with that DevOps, I’ve been – security is more important.” But it’s all – we’ve gotta – it’s DevOps, and it’s not just DevOps in terms of Dev and Ops; it’s DevOps more is almost a Zen term, right, where things are flowing, things are automated, things are – I don’t want to go all Eastern on you here, but you know what I’m saying? And security is getting with that.

You want to call that DevSecOps, I don’t really – I don’t care. I don’t agree with it, right? I think security has to find its place in that DevOps world.

Mogull: Well, I said years ago – I did a thing on Twitter that there is no DevSecOps there is just DevOps, and I got a lot of pushback on that and kind of walked through and explained my meaning, and that is what I believe and I think that’s aligned with what you say. And in fact, a lot of this is things that we are trying to build a platform to support –

Shimel: Yep.

Mogull: – in terms of not those team separations. However, I do think we need to call it DevSecOps for now because the – we’ve got a mindshare thing that we are dealing with.

Rothman: Yes.

Mogull: And there’s the philosophy of DevOps, and you know what? If I see DevOps on a Dev, I know it. If I’m an Ops person I know it. I know I fit there. And security is on the outside because if you look at reporting structures security’s on the outside and they’re reporting somewhere else. So I think we do need that term. I don’t think it’s anything different but I think it’s a – gosh, I hate to get, like, inclusive and kumbaya, but it’s a term of inclusiveness.

Shimel: No, Rich, I – you know what? At RSA if you look over the last five years I started calling this thing rugged DevOps that I do on Monday there. I started by calling it rugged DevOps and then I didn’t really like that. It sounded kind of too low or west side at midnight.

Mogull: That’s because we were all listening to a particular – that person with a loud voice.

Rothman: Windbag.

Shimel: Yeah, but still, it was a nice name, and then we went to DevSecOps and DevSecOps days now, of course. I agree with you 100 percent, Rich. We need to keep it until things are a little bit more mature, let’s call it. Mike, I want to ask you a question though, and Rich, feel free to chime in. At some point though, and you both have touched on it, we need to more closely integrate our security teams and our security people with these DevOps teams. Not just the Ops teams, but the DevOps teams, because it all becomes sort of one pipeline and, you know, how software _____.

Rothman: And I think that a way to think about is, you know, going native, basically.

Shimel: Yeah.

Rothman: And that obviously has a lot of different [laughs] connotations. We talk about cloud native but this is really about going native into business IT and understanding what the business requirement is for the cloud stack that is being built and then designing the security controls that will protect that data – not all data, right, which is how we’ve always thought about it, a universal security service where everything fits in and is secured, which by the way has failed miserably, so what we try to do is shrink it down from the standpoint of what do we need in order to secure this specific environment? And again, that’s where the automation platform becomes so much more important because then you can set different politics for different pipelines in different projects, possibly even in different cloud providers using different technologies, but you’re able to enforce a consistent set of policies that adhere to the corporate environment but do it in a very micro perspective relative to what that application uniquely needs, and that’s something that we haven’t been able to do in traditional infrastructure, but the programmatic mechanisms that drive DevOps, and by proxy, you know, the security aspect of DevOps – and we can call that DevSecOps – but it really is a transition. And that’s one of these things that, again, is just a common misconception.

It’s the old writer’s creed, right? I would’ve made it shorter if I only had the time, right? I would’ve made it easier if I only had the time, and that’s really what we’re trying to do, that’s what we’re really – we think our key innovation is, is making a lot of these very difficult, very complicated security operational motions really as simple as clicking a button, and we’re pretty close. We’re very excited about that.

Shimel: Cool.

Mogull: Yeah, I mean it’s – you know, people make kind of these promises a lot, but then when what ends up happening is you got a, you know, write-your-own code or it’s not gonna fit your environment or it doesn’t keep up because a lot of security vendors – let’s be honest – their products can be kind of static and, you know, Mike and I, we view this as a content business in as much as anything else, where understanding the leading edge best practices and coding those and doing so in a way that allows the flexibility for teams to adopt those with minimum friction, without breaking things in their environment, I mean it is a huge challenge. I do not want to make that sound simple, but we think that that that’s, you know, really one of the core innovations that we’re bringing to the table on this.

Shimel: So guys, we’ve pontificated for 15 minutes, we’ve skirted the edges of what DisruptOps is, but we’re gonna have people listening to this who say, “Okay, I really want to know more about the product, though. How do I as a user, how do I as a security company harness this thing? What do I do? What do I need to know, how do I do it, what exactly –” give us a little bit – put us in the driver’s seat on this a little bit. We’re behind the UX now. What are we seeing? What’s happening?

Mogull: Yep. So the first thing is it’s really easy to get up and running with it. You go ahead, great an account on the console. We’re actually doing beta testing right now so people interested in that can reach out. We’re almost finished with beta and getting ready for general availability. When they go ahead and log in, we are today an Amazon-specific tool. We are adding capabilities for other cloud platforms. First thing you do is you need to connect up your account. That is literally I think, what, Mike, a three-click, maybe a four-click process –

Rothman: Yep.

Mogull: – to go ahead and add the accounts. They don’t need to, like, type anything, they don’t need copy-paste policies. We’ve got a really cool, really smooth provisioning process we use for that that gives us permission to do what we need to do. And I won’t go into it now, but for the security wonks out there, we actually have a very dynamic permissioning system so that we can always keep ourselves down to least privileged using all sorts of policy boundaries and things like that that are otherwise invisible to the user so they don’t have to manage that stuff.

You go in and you pick the automations you want, so we call these things Ops, everything from don’t let an SRE bucket become public to really much more complex ones like find any IAM roles or users or groups that are subject to privilege escalation or build out my entire monitoring system with a couple of default settings.

And you go ahead – you turn those things on and then in the background they’ll start analyzing your environment, they’ll figure out when things aren’t set the way that they’re supposed to be set, and you have the option; you can turn it on to automatically fix those or you can go ahead and choose to create an issue in the system and then you click on it and then you can manually trigger the same remediations. Now there’s a bunch more in it but that’s really the heart of what we think are the guardrails, where you get to configure these and you get to scope them down to conditions like only do it this way in this account if it has these tags or apply this to everything that I do. You can treat things like Dev production and testing environments differently than throwing one kind of generic set of policies out there. You can turn on and off what you want or you can just turn on all the defaults and we do all the hard work for you.

Shimel: So, Rich, you used the magic word there. We don’t have to _____, but you said guardrails.

Mogull: Yep.

Shimel: I’ve heard the term, you know, security guardrails before. Mike, I’m sure that that term didn’t go out with your approval. I know you long enough.

Mogull: No, we came up with it, Alan. The problem is we started using it internally before – like 6 to 12 months ago when it became a big deal. That was kind of internally, but if you want I can give you an example of what a guardrail looks like as opposed to a blocker.

Shimel: Okay, let’s talk about that.

Mogull: So, here’s an example. Suppose you have a rule that you should never have an administrative server or a database server with _____ exposed to the internet. Well, as a guardrail we’ll do a few things. First of all we’ll let you know is it fully public or is it exposed to part of the internet or maybe it’s got a security group rule that allows access from anywhere but it turns out it’s on a private subnet so it’s not actually exposed. So we figure that out and create different kinds of issues based on those. And then being a guardrail, the options are not just knock that thing off the internet, but you can actually set rules that it would automatically – or again, if you want to be the human in the link you can go ahead and click the button to go instead – to restrict it to known IP addresses that you load up into our system.

So you’ve got your corporate approved IP addresses. The scenario for this is a developer may spin up a jump box because they’re at Starbucks and they’re trying to get their job done and they’re supposed to be in the VPN but they got lazy and they opened it up from where they were. This would go ahead and actually detect that and lock it down to corporate IP addresses, so they’re not, like, kicked off; they’re just gonna make sure they’re on the VPN and then they can still go ahead and access that system. To make it even better, you can put a delay on that action.

So if you say, “Ooh, somebody for – spun up an asset with the wrong tags, we want to get rid of that,” well, we can have that so it won’t get rid of it for a week. It’ll create an issue, it’ll send out notifications so somebody’s got time to fix it, and then at the week it would automatically take that action or whatever arbitrary deadline you put into place there. So it actually allows security and operations to kind of work together without fighting each other off, so that’s what we consider a guardrail. We’ve got the rails on the side, kind of keeps you in the middle, but it gives you the ability to kind of adjust your flexibility to have the softest landing possible without actually creating more security risk.

Shimel: Fantastic. Alright, Rich. You’ve been talking too much. We need Mike to talk a bit. So, Mike, go to market here. What does this thing look like? Is it a SaaS? Would you call it SaaS? Is it…?

Rothman: Yeah, it’s absolutely a SaaS. So as Rich said, I mean, you know, our provisioning process and deployment process is, you know, a couple of clicks. You know, we connect to a customer account, we do the initial set of assessments, you know, and then we start putting some of those and enforcing some of those policies in place as guardrails, so it really is a tried-to-buy type of thing, which we think that fits into the cloud and DevOps motion a lot better, which is use it in your environment, get value, then we talk about, you know, some type of economic transaction. But, you know, right now it’s – we’ve got a signup sheet to get access to our early access program up on our website and that would be the way to start the process, but over time it is going to be a, you know again, connected into your system, hands off, lots of educational videos. Use it, get value, and then, you know, when it’s time do a transaction.

Shimel: Good stuff. So guys, I would be remiss if I didn’t ask. What about Securosis?

Mogull: We are still moving along because we gotta pay the bills. [Laughs] So it turns out when you found a company – nobody puts this in the books, but you’re not, like, allowed to take a salary, and so we are basically –

Shimel: You’re hanging out with the wrong people, Rich.

Mogull: Yeah.

Shimel: [Laughs] 

Mogull: Yeah, I guess so.

Shimel: Mike, did you tell him that?

Rothman:[Laughs] No comment.

[Laughter]

Mogull: So yeah, we’re doubled up on jobs right now but – people get worried when they hear that. We actually have – there’s 15 people in DisruptOps. We have half the executive team is full time and not splitting time like we are, although to be honest I’m working full time on both at this point. So, you know, with our CEO, our CTO are fully dedicated over in the DisruptOps side. The development team’s everything else. We’re not wearing – none of them are wearing two hats. It just happens to be the two guys on your phone right now are the ones that have to wear two hats.

But yeah, we’re cruising along. We’re doing with Securosis, we’re with the Cloud Security Alliance, training programs, assessments, and what’s really interesting is we’ll probably always do some of that because it is about – well I’m VP of product on the DisruptOps side and I get to see more with the work that I’m doing on Securosis. It’s like a dream for any product manager in terms of going into real environments, doing real assessments, and actually seeing how these organizations are working day to day.

Shimel: Excellent. You know, it’s funny I picked the two of you because we had never really done a podcast before. [Laughs] We’ve been doing podcasts actually before Mike – there was a Securosis, right?

Rothman: That’s right, that’s right.

Mogull: Yep.

Shimel: Security Insight.

Rothman: That’s pretty old school.

Shimel: It has been a trip. But guys, listen, we’re on over a half hour and we probably need to wrap up. First of all, congratulations on the RSA Innovations Sandbox finalist. Whether – you know what they say – whether you win, just getting it to this level is quite an accomplishment, but sure it would be nice to see you two guys win.

Rothman: We’d like to win.

Mogull: Yeah, we’re okay winning.

Rothman: Yeah. So, come see us at the Innovation Sandbox. That’s Monday afternoon at the Marriott Marquis in the Yerba Buena Ballroom. But also, we are going to be at your event, Alan. Why don’t, you know –

Shimel: Yeah, I know –

Rothman: [Inaudible comment] 

Shimel: Yeah, so all day Monday is DevSecOps day, and on DevSecOps days we are also in the Moscone South, I think. If it’s north, I apologize. But we’re in one of the bigger Moscone ones right near Cloud Security Alliance. They’re usually not far from us. We’ve got a really nice big room there and we’ll usually get 1,000 to 1,500 people coming in during the day, but we have an outstanding lineup of speakers this year; some old, some new faces, you know, to the community. Rich, I think you’re on a panel there, right?

Mogull: Yep. Yeah, I think I’m on the closing panel.

Shimel: Yep. It’s a pretty deep – I mean there are some good names speaking there. I mean the one thing – I can make fun of the word DevSecOps all I want. The community that is congealing around it is first rate. I mean there are some really smart people and that’s always good. And then also, guys, you know, I’ll be on Broadcast Row all week, and I know I have some time scheduled with the both of you and we’ll be doing a nice 30-minute video, so come dressed nice, [laughs] and that’ll be up shortly thereafter. So – and then Rich, are you speaking at any other RSA sessions this year?

Mogull: I am. I’m doing one “Don’t Lift and – Lift and Shift Versus Lift and Pray,” so it’s about migrating your existing workloads up into cloud and different lift and shift strategies.

Shimel: Mike, how about you?

Rothman: I am not doing any other speaking engagements. I will be at the America’s Growth Capital conference on Monday morning, moderating a panel, but I’m not doing any other speaking. You know, too many people to see, babies to kiss, you know, all that kind of fun stuff.

Shimel: I know where you’ll be hanging out.

Mogull: The disaster recovery breakfast?

Rothman: Yeah.

Shimel: On Thursday morning!

Rothman: Thursday morning.

Shimel: You know, someone tried to invite me to another breakfast Thursday morning. I said I have a previous engagement. But anyway, yes, America’s Growth Capital Conference is another kind of staple of the RSA. Maria Lewis Kussmaul and team puts on an amazing day of sessions. Anyway, but guys, seriously thank you so much for being our guest. Best of luck with DisruptOps. We’re looking forward to really following your success here. Alright?

Rothman: Thank you, Alan. You bet.

Mogull: Thanks a lot, Alan.

Shimel: Hey, Rich Mogull, Mike Rothman, cofounders at Disrupt Ops, a RSA Innovation Sandbox finalist this year, 2019, and just all-around great security folks. This is Alan Shimel. You’ve just listened to another DevOps Chat. Have a great day, everyone.