CISO Panel Service Mesh Day 2019

Transcript

Deepak Jeevan

Hi everybody. Thank you for spending lunchtime with us, humble CISOs. Uh, so we changed the analysts VC panel that’s in the printed sheet to a CISO panel. Thought it will be more interesting to, for all of you to hear from how chief security information officers, chief information security officers of different companies, uh, think about service mesh and they, the, the interaction between dev ops, IT and service mesh. So my name is Deepak Jeevankumar. I will be the moderator for the panel today. Uh, I’m currently a managing director at Dell Technologies Capital, a venture capital firm. Um, and uh, how humble investor in Tetrate as well. So, uh, let’s, uh, start by, so we’ll have about 30 minutes for the panel and we’ll have a break again before the session starts again at 1:30. And we will have a few, few minutes towards the end of the panel for questions from the audience. So let me, um, ask everybody to introduce themselves to just start with. Ody, do you want to go first?

Ody Lupescu

So we’re talking about introductions.

Deepak Jeevan

Yup. Quick quick intros yeah.

Ody Lupescu

Quick Intros. So I’m Ody Lupescu. I look after security and compliance at Earnest, a fintech looking, uh, basically, uh, providing consumer finance.

Deepak Jeevan

Okay.

Richard Seiersen

Richard Seiersen. I’m the CEO of Soluble and recovering CISO.

Deepak Jeevan

Uh, So Ody and Rich could you also talk about your CISO gigs right before this as well.

Richard Seiersen

Okay. All right. So, um, essentially 20 some odd years experience. Previous to my, in my previous role I was looking after security and compliance for a biotech. Uh, previous life I was in financial services, Wall Street, AIG, JP Morgan Chase, spend some time at Schwab. So been around the block a couple of times, spent some time in advisory services. So, um, yeah, long time.

Again, CEO Soluble previously CISO Lending Club, CISO Twillio, CISO GE Healthcare, et cetra et cetera, et cetera. Author and meme wrangler.

Deepak Jeevan

And a judge for the RSA innovation sandbox startup competition.

Richard Seiersen

Yes, I judged the RSA innovation sandbox.

Sandeep Poonen

Sandeep Poonen um, responsible cloud security at VM are. Um, before that I was at PWC and had a lot of SAP security and enterprise security responsibility.

Tom Baltis

Uh, Tom Baltis,Delta Dental Insurance Company. Um, we’re the country’s largest dental benefits carrier. If you’ve been to see your dentist sometime in the last 50 years, chances are you may have encountered our brand, um, CISO, uh, of, um, blue cross blue shield organization, several different ones prior to that, as well as a couple of CISO gigs at property and casualty insurance industry before that.

Deepak Jeevan

Firstly, thank you all for taking time and service meshes is an exciting area. There is a lot of hype. And today we heard from some of the creators of different projects of service mesh, Istio and Envoy. So, uh, I think the first question is, um, when did you all hear about service mesh, the Istio and Envoy projects and what context and what is your first reaction when you heard about his projects? Who wants to go first? Ody.

Ody Lupescu

I’ll go first. So it was actually before v1 and it was last year, about a year and a little more than a year ago where developers, our development team came and said, look where we’re having, uh, an aggravating experience with this, a microservice authentication, uh, that was implemented, so everyone had to build it in every micro service. And they said, look, there’s something out there that’s pretty cool. Why don’t we look at it? So we kind of looked at it and he said, wow, that’s definitely interesting. And he promptly went in the backlog and eventually resurfaced. But that was the first time. Developers actually came in, brought it to uh, to our attention.

Richard Seiersen

Sure. Most recently at lending club. We started looking at Istio. We were doing a lot with Kubes and we’re just starting to kick the tires.

Sandeep Poonen

Yeah. I mean I’m fortunate to work for VMware, so we’re obviously thinking a lot about cloud, we got a lot of innovation there. We have some folks [unrecognized name] and others, um, who are obviously building the NSX service mesh. Um, and then obviously, um, had the privilege of kind of meeting the Tetrate folks as well a while back.

Tom Baltis

Yeah. So first for us, I think the sort of, you know, coming into the realization that this is an interesting, um, uh, possible technology solution, uh, came from an effort that started a while ago in the enterprise, which is essentially focused on transforming and transitioning us into what we call a composable enterprise. And that term is, if you’ve heard it used by some vendors, a little bit different than how most people define it in that we really see the future, a model of our IT environment in the way we’re our own organization is nothing more than a, a, a single provider of SAAS services to our employees and contractors and other constituents among many, many, many other SAAS providers as well. And so that type of vision, um, you know, not to expand too much on it leads us down a path of, uh, identifying some very unique and interesting challenges for which we had been looking for solutions for some time before a, Istio, before service mesh as a general concept even became sort of recognizable and, and uh, uh, and addressable. And so happy to reflect on some of these challenges in the subsequent, uh, a conversation here. And also give you a sense for how perhaps Istio might be a solution or at least we hope might be a solution to them.

Deepak Jeevan

Yeah. So I’m going to, um, like ask three or four questions. They are all interrelated. And so feel free to slice and dice it however you want. So, um, yeah. In your organization, how should a service mesh adoption journey look like? When does the security team get involved? When is the CISO team involved, uh, and does service mesh actually complicate or simplify security and identity problems for you? And the final question is, do you really have a choice about service mesh? Do you have to adopt it, there’s no choice or can you fight it? You can start with the final question. Can you fight service mesh?

Richard Seiersen

I can jump in. Um, so, you know, what do we do? What do we security folks do? So in an organ, those you don’t know, we, um, we’re really accountable, right? We’re accountable when things get, yeah. How do you know that these, those accountable, they get fired, right? That’s probably how, you know you’re accountable or something. Um, so that’s a good boolean test there. So we’re, we are accountable for the implementation of the stuff of the things, right? And then, uh, operations, dev ops would have, have you, is responsible for execution. So our job is to be able to define what it means to be secure. And I think that what, um, Istio does in, in general, right. Um, it really makes it easy to do a lot of things that we want to do in the first place in terms of being able to govern the infrastructure really easy, you know, with sidecar capability, be able to have great visibility. Um, you know, in terms of, uh, a self termination or being able to say, you know, do TLS this way. I mean, just the dynamic nature of that makes it a lot easier, but just because it’s easy doesn’t reduce our accountability. I think that’s an important distinction. Um, in fact, because it’s easy, it’s easier to spin up a lot of stuff and a lot of regions, it’s easy to expose more value to more people through more channels at higher velocity. So while you’ve reduced the complexity of the stack, you made it much easier to, to expose more. And with that. So with that, you’re exposing a lot more value hopefully to your, to your customers. But from a, from an accountable perspective, that’s creating a lot more risk or risk surface might be the right term. So, uh, long story short, uh, we need to be very involved in that. We need to be a very involved in design process, but we need to be able to you to be involved in a way that’s ideally frictionless in terms of spinning things up and getting things out. That’s a lot of words.

Deepak Jeevan

So can I ask an add on question, which can be part of this whole, uh, uh, as a group of question, who pays for it? Is the budget coming from the CISO? So, or it comes to the CIO, VP of dev ops because there’s some security aspects of service mesh as well. Quite a few. If you’re going to hear later in the day about the next generation access control and service mesh. So how does that work?

Richard Seiersen

I’ll just pile on and then you guys can run with it. Um, if whoever’s responsible for, uh, again, responsible for execution, dev ops or dev operations, operations, typically if I have the budget, I’m effectively going to be transferring. I’ll govern its execution of that budget. Um, but I’ll be transferring it to them cause they’re gonna be doing the proof of concept. They’re gonna be the ones who are going to turning the wrenches. Right? So that’s how I’ve always operated. If I were to go advocate for the budget because I have an outcome that I need, I can then transfer that budget to the people who are gonna actually be responsible for execution. And that’s exactly how I operated at Lending Club.

Tom Baltis

So here’s my 2 cents. Um, I think it depends who’s interested in it in the first place. Now you’re not going to pay necessarily for the technology. The technology is open source, but you eventually may want to have a product thats supported. And I think with this, it, especially in the security space will, and this is, I don’t know how many of you have looked at it. There is a flurry of companies that have started up expanding what Istio does in the, this whole concept to micro segmentation, but normally to microservices, but they extended to the entire stack, the entire platform. So you can have EC2, the same functionality, the same governance. You can now extend it to uh, EC2 instances. So all of a sudden you can have a central policy across the organization. There’s companies like Octarine, uh, Banyan Ops and others, sprouting almost every other day. They take this to the next level. So that becomes a security solution. So I’ll be paying for that. So it’s interesting that now it started from a development team, but I’m actually championing this and saying, I’ll pay for it because I want sort of this zero trust, uh, I want to have, uh, to basically have the ability to introduce some level of control in the environment. So yeah, I think it depends who’s championing the idea that ultimately is who’s paying for it. And the involvement of the security folks will vary if, you know, if there are kind of brought in at some point or if they’re driving it.

Yeah, I mean, I think the way I look at it, a couple of thoughts is, um, the role I play is to enable the business. So at the end of the day, the business is generating their revenue and I’m trying to be in a position to help them generate the most revenue. One of the things that will not help them generate revenue is if we don’t produce, we don’t create secure products. Right? So I think I tried to resolve the paying question by, by looking at it from a business standpoint and seeing how, what you’re doing in delivering your products, not, is actually not hurting you in the wrong run long run because you’re not delivering it in a secure manner. So for example, I mean I think the way I look at it in our landscape is, okay, you’ve got a bunch of containers that are out there. How are we providing good security from it? That’s a little bit more of a tactical problem. But if I even kind of go up a little bit further than that, um, in this whole context of containers and things like that, at the end of the day I’ve got a bunch of services that are talking to one another. How am I going to mediate those services and these API calls and all of that? That’s, there’s a lot of security that’s related to that. How my credentials going to be, are they going to expire? They, they’re going to be rotated frequently enough. Are they going to live out there in the wild? Things like that. Now that’s again a bigger, a broader problem that has a lot of risk to it and even be, even more broader than that is how is my data, where’s my data? How’s my data being used, exchanged among services? And of course, I mean, you know, besides the security concerns of that, there’s the obvious compliance implications of that. GDPR and other things and all of that. So no matter where I’m skinning that cat, so to speak, whether we’re talking about actually just managing containers and the very technical way, or broadening it out to a compliance requirement and managing our data holistically. Um, my job is to try to explain to the BUs, the business owners - look here, overall from an enterprise, here’s the problems that we need to solve. Um, at the end of the day, it’s coming out of somebody’s pocket left or right, CEO or somebody out there. Right? So I think, look, I mean, I, I tried to present it that too and say, look, together we have to go. We have to build that culture of adoption together, saying this problem needs to be solved. There’s a compliance problem, there’s a overall data problems, and then now we can tactically solve it through a container issue, a specific way and try to solve it. Um, but the underlying issues that I think that what I’ve really loved about a service mesh is that they’re solving problems that microservices are creating. There is so much that out there. So whatever service mesh, uh, challenges there are, I know it’s kind of relatively new and there are pain points, but they’re solving a lot more problems than I have right now with all of my microservices just being out there, the redundancy and the lack of good security that’s out there.

Deepak Jeevan

So basically you’re saying there’s no choice but to adopt service mesh.

Sandeep Poonen

That’s I think from a philosophy standpoint, absolutely right. Now how you actually deploy it, that could be different technologies that we’re hearing about, different things, but ideal, from an ideology standpoint, I’m, I’m in, right.

Deepak Jeevan

Tom, are you in or are you out?

Tom Baltis

Well, I think resistance is not necessarily futile in this case, right? If you want to look at it from that point of view, I would echo the comments that some of my colleagues made with respect to different constituencies and levels of interest in adopting this technology, right. In our case, it will most likely, and that being driven by risk management and security folks because of the sort of concept that I mentioned to you guys from when we did introductions, which is this sort of notion of composable enterprise. Most of the problems that this technology we think have, has the possibility to solve are really about how we do risk management around our technology environments differently in that new world, world, versus how we do it today, right? And in particular, those have to do with, um, ideas such as, um, you know, the perimeter, if that’s even the right word, anymore being defined and managed around each individual workload as opposed to an operating system or a network segment. And being able to essentially control and enforce security decisions and policies regarding interactions of different workloads and users that may be invoking those workloads, uh, not just within the company’s environment, but also across the public cloud, hybrid cloud, internal on-prem environments and of course multiple perhaps, uh, cloud environments, public cloud environments as well, right? So that’s sort of a key challenges. Uh, you know, how do we actually establish the ability to create a perimeter and manage the perimeter around individual snippet of code, which is really what the appropriate unit of granularity seems to be moving forward. Uh, the second problem that, that we hope this will help us with, uh, really has to do with decoupling of security decisions from the underlying network fabric, the underlying operating system. And you know, dare I even say, uh, from the underlying container object, right? So it’s very important for us to be able to start defining security policies and attaching them to workloads, uh, in a way that does not depend on understanding of the identity or the inner workings of all the underlying layers of abstraction, right?

Whether it’s the operating system, the network infrastructure, whatever the case may be. And you know, really some of the early attempts in, in solving this problem, we’re still very much rooted in operating system level constructs like IP tables. And you know, perhaps, I know BPF was mentioned as an implementation choice earlier today, right? So trying to get away from that as much as we can because we expect these workloads to be, uh, fully unaware of the underlying infrastructure they’re running on.

And then the last thing, you know, from a developer point of view, I want to mention I think really important as ability to define and manage security policy as code, right? So we’ve sort of, uh, I think realizing that in order to cross into the threshold of, uh, of being sort of fully composable enterprise. So we have to have the ability to specify, um, test and deploy our security expectations, our security policies, with the same mechanisms, not just in parallel to, but using the same mechanisms that are currently used to create, um, integrate, deploy and manage code. And so that’s another opportunity where we feel that some of the concepts we see emerging in the service mesh space can truly, um, kind of help us get closer to, and hopefully, fully address.

Deepak Jeevan

So let’s focus a little bit, uh, on, uh, the key. And I would say it is the heart of service mesh, the Envoy proxy. And I, and we heard from Matt about why he started it and like, what is the, what’s coming up for Envoy? So how do you think the, uh, your developers think about this new generation of load balancers that are based on Envoy? I mean it’s like really the Envoy versus like the hardware route, but how do you see this transitioning from the old stack that was dominated by a few hardware and like very prescriptive software plays into more microservices friendly Envoy proxy. And do you think this happening in your organizations today? What is like the speed at which this happens?

Ody Lupescu

Well, so I think it, it happens for instance in the evolution has been you, you start in the cloud. We’re a cloud company. It’s cloud only. We have nothing on-premise. We start in the cloud, you go through load balancer, you gave your typical ELBs in Amazon. And that’s the entry point. And at some point it does become, especially if you are, if you’re not fully integrated in your development operations or your devops team, it becomes kind of a handoff between infrastructure and the folks that develop the code and it becomes, uh, and this handoff actually becomes friction. Um, the, the ability to abstract some of this and be able to create the, the load balancing in, in, in a service mesh, at least from our developer point of view, this is gonna make their life a lot easier.

Deepak Jeevan

And is that the first step for adoption of service mesh? Getting Envoy in?

It’s one of the steps. Again, you’ve got multiple, I think it’s a win win situation. I think you’ve heard from the my, my, um, a fellow practitioner that there’s a security benefit and no one’s gonna argue about that, but there’s an operational intelligence benefit and then there is an actual operational benefit itself. So I think there’s, there’s a multiple benefits. So that’s one of them. And yes, I think in our case, the being able to abstract a lot of that information, not building it into the, into the code and not depending on like multiple, multiple teams. It’s a big factor for us.

Richard Seiersen

Umm.

I forget who said this. Someone said, you know, if it can be written in Javascript, it will, um, let it, more generally, if it can be done in software, it will. So I don’t think it’s really a question of whether or not, um, you know, you have software defined load balancers is it, you know, it’s going to have to happen. At my previous, we were actually consuming data from load balancers, put them into a graph, in relationship to our microservices, and then using that to, to take software defined actions based on being able to look at dependencies. Right. Um, it would be a lot easier, more real time if that is all in software. So just, yeah, it’s going to happen. Um, you know, by the way, there was one other comment on perimeter. Um, you’ll hear this from security folks, the vendors will say, the perimeter’s gone. It’s actually not gone. It’s gotten much smaller and more ephemeral. Um, and that’s, that’s the reality. And so something like Istio, um, really, um, acknowledges that reality. It acknowledges the reality of the stuff that need to protect. It has a tendency to exist, right? I remember they said in physics subatomic particles, they’re, uh, they’re like particles or waves. They have, they have a tendency to exist. This is the thing that we’re dealing with. Um, so I would say this on the perimeter and Istio, it, it really, um, it really meshes with the actual underlying reality of ephemeral of things that need to protect it. They’re very small units and they have very small units of time typically. And so I just wanted to say, when you hear security folks say that premiter has gone, they are wrong. It’s smaller and more ephemeral.

Sandeep Poonen

I mean, one thing I was going to add also is, I mean, um, okay. Yeah, I keep trying to tell him myself to speak the language of the business. Right? I mean, so I think for example, and for developers, the concept of application load balancing is not necessarily something they’ve grown up with. Right? I mean, I didn’t grow up with it myself. So I think it’s a, it’s a shift in the way people are thinking from being lower down on the stack L4 L3, whatever it is now to L7. So I can understand that. But what I try to evangelize is what I’m after. And I think what the proxies give them, what they, Envoys, give them for me at least is consistency. I’m, what I’m after is consistent deployment of security and I feel like security, certain configurations rather than having them develop it in the code, abstracting it and making it a consistent configuration item is something they can get. Not only the, they don’t have to worry about it, because they’ve been used to probably coming, people coming at them from security and hitting them with a hammer. But if I can abstract it and say, hey, look, make this a configuration item rather than something that you have to code every time, then, then, made it easier and they get that automatic consistency is something that I hope they’re able to understand. That’s the reason for these Envoys to do. Now there are other things, obviously you can get through it, encryption from a security standpoint, identity and things like that. Auth-N, Auth-Z. Um, but those are the, some, that word consistency across all the different BUs, again some company like VMware. We had our on-prem shelf ware products and we’re obviously trying to transform. Um, we have to walk with the business through this now. So I think if you guys are cloud native companies, I think it’s a lot easier. I think that the conversation, but for a company like VMware, it’s um, it’s a journey

Deepak Jeevan

That’s the consistent application of security policies, right? And a configurational layer rather then in a code layer.

Tom Baltis

So I think that’s a really important actually point to underline in that, um, to me, you know, when you think about Envoy, um, or any other prior technology, those are from a developer point of view, deployment considerations and should for the most part be invisible to them right. Now that does not mean that they should not be aware of and thinking about the type of configurations or type of security policies that need to be developed and specified when they are designing and building the code. I think that is absolutely critical. Right? And as an industry, we still have an enormous amount of work to do, I think to partner closely enough, with the developers, so to them, so it becomes a sort of a natural aspect of thinking about their work as they’re doing it on a, on, on a daily basis. Right? But the notion of them worrying about whether that policy is going to be implemented using a very traditional F5 load balancer as it has been for many years, or you know, perhaps even more legacy firewall technology or something much, much newer, like an Envoy proxy that’s sitting in a sidecar next to the container where they’re running. I think for the most part should not be something that they would need to have to worry about. And I think to making that transparent is the job of us here as end users. But also, you know, a job of us as an industry when we talk about making service mesh accessible to a much broader set of end users than it is today.

Deepak Jeevan

Okay. So final question before we open up to the audience. I would say it’s not a, this, this question is not an, it’s not an obvious question, but I just wanted to okay. Think put the, the hype and the reality in context. So that’s why this question comes up. So is the interest, if you, if you compare some of the big waves and developer tools for the last three, four years, right? They had docker containers, Kubernetes, and now we have um, Envoy and Istio. How do you compare the increase in interest in Envoy and Istio compared to the prior two waves around the Kubernetes and docker, and docker? Is this more real, is this more faster?

Richard Seiersen

Yes.

Deepak Jeevan

Are you going to say more?

I think, I think for me, for a security guy, again, again, we’re dealing with things that have a tendency to exist, for dealing with fluid infrastructure, hybrid environments even. And if you’re going to say that I’m going to have a substrate that makes it easier for me to implement policy, um, that is faster. By the way they’d been. You know what happens when you do things faster, you make more of it, it makes more risks. Um, you know, I was talking to someone at a very, very, very large bank the other today. And we were talking about that difficulty in managing hybrid infrastructure, on-prem and cloud and his view as well, you know, isn’t that already all solved? I mean, now, now we’re all software defined. Isn’t that all solved? And I said, no, it’s never, it’s never solved when you, when, if you make it easier to go do things, you make it easier to go faster. Faster does not mean more safely. It actually means you’re exposing, exposing a lot more. So bottom line is this, I think something like Istio or uh, I guess Tetrate is, uh, you know, the host here, it will allow me to be able to help you go faster safely. You’re still gonna be exposing more risk. You’re always going to be going faster. It’s always going to be a problem. But it ties in faster safely. That’s what I meant by, yes.

Ody Lupescu

So it’s interesting. It’s a good point. Yes. You automate, and you can make a of or a lot more mistakes allow faster. So you call it a much bigger problem. So we on the, on that front you can totally mess things up. Um, but the, but the idea of about the adoption, which is very interesting because I was just talking to a number of folks as well. I used to be on the east coast and it’s the San Francisco bubble and then the rest of the country bubble or the world. So yes you do get the adoption here, but the rest of the, this is kind of the tip of the spear and you go, you kind of right there. So yes, the adoption is faster, but even in our environment where the adoption is faster, we’ve adapted everything. So as a five year old company, we, we didn’t spare too many things. Now many of them eventually didn’t find as much use and now they’re a technology debt. So the question is how, how can we make sure that this doesn’t become another piece of technology debt? And I think for, as I say from a, from a security perspective, the ability to extend it, not just to microservices, put to the entire technology stack. It’s, it’s very important. So I can have a single set of controls. I don’t have to have too many. The technology solution they live on top of, it are going to make it or break it because if you don’t have a good interface to set up all your policies and so forth, sure you can do things with it, but it’s going to be uh, is not going to be as easy to manage. So I think that’s, that’s what’s going to drive hopefully the adoption. The new products are coming on top of it and they’d been around and there, as I said, there’s a lot of them sprouting. I’m having a hard time finding them but I’m interested. But that’s my 2 cents.

Tom Baltis

So to, to kind of underscore that, but, but I think a slightly different perspective on speed, right? Um, I think the adoption is going to be slower, but the impact of it I think is going to be significantly more meaningful and more effective, at least from security and risk management point of view. And that I think has to do with the ability to deploy this in brown field type scenarios. Right. So when you look at Kubernetes and docker, uh, with the exception of certain geographies or certain industries as it was already mentioned, um, you know, and perhaps enterprises in a certain life cycle of their existence, those are very focused technology developments that don’t need to be or cannot even actually be adopted in a, you know, fully in a brownfield type IT environment, right? This solution I think has the potential to be adopted in a brown field environment. And that’s why it will have a significantly larger impact on our enterprises if we do it right. But that also comes with a lot of baggage that we need to solve for. And I think that, uh, you know, one of the things that is important in making sure that this does get adopted and embraced by large enterprises is positioning it properly with all the different constituencies that can benefit from it, right? So we have a significant sales job. I had, uh, you know, on all of our parts to convince our enterprises, and this is the right way to think about how to implement security in the company, not just for that 5% or 10% of the environment that is dockerized or that’s managed by Kubernetes, but perhaps for the 70% and 80% of the environment that includes a lot of legacy workloads, a lot of legacy operating systems, non cloud based deployments and so on.

Sandeep Poonen

Yeah, I was gonna say, I mean from my, I’ll just give a data point from my completely uninteresting career, which is I’ve never been on a panel talking about docker. I was never on a panel talking about containers. So I mean, but I’m in security, right? I ended up, obviously these are huge waves, but there’s a reason why I’m passionate about service mesh and Istio and things like that because there’s a real security advantage to it. Um, and obviously dockers, good reasons for it. But the developers were doing it themselves and I was scrambling off to them saying, how do I secure this? Same with containers. I was running off to them saying guys slow down. I don’t know how I’m going to secure these environments. With service mesh it’s different because I see clear advantages to it, so I’m almost being an advocate to it. So I think for those who are not in the security space, there’s a great advantage for you to engage your security professionals and say, guys, you need to come along with me because you can be part of the buying process. And I mean when security champions things, definitely if compliance comes on board with it too. There’s a lot much. It’s a, it’s a lot easier to get that funding. Right. So.

Deepak Jeevan

That’s a good point. Thank you. I’m going to open the floor to audience questions, so we’ll have like another five minutes or so. Please. Uh, please go ahead. I was wondering who was going to go I suppose. Yes, please.

Sorry. Can I ask you to tell your name and where you’re from?

audience member

Sure. Early on in the journey here, our driver on day one is step 3 which are the security benefits. Monitoring, telemetry, that’s all nice. Security is my big one. One thing that we’re finding to be interesting, so architecturally, the fact that, you separate these concerns out of code, you get a better distinction of your developers that just want to build a business value. Right? So architecturally fully agree. But what we’re finding to be interesting, I’m curious about your take on is dev ops has brought concerns that used to be some centralized group’s concern ,be that security, be that networking, closer to the teams, building those services. So on one hand architectually this separates the concerns in a nicely decoupled way. What we’re finding is it’s almost taking some of what dev ops has brought back to the team and saying who’s going to manage all the configuration of Kubernetes, of Istio? Does some of that back out to a central group? And I’m curious to see how you guys are seeing that pendulum swinging back and forth.

Deepak Jeevan

Thank you.

Ody Lupescu

So as I said, we have, we’re planning to, to uh, to move to service mesh sometime in, I want to say late Q2. So we haven’t got to that point yet. But I think that the, uh, it brought up an interesting collaboration because now we’re actually working, we’re moving more towards this sec devops kind of aspect. We’re, we’re involved, we’re working together. Um, we’re trying to define again who does what and for what purpose. So our, our goal is to define a, not necessarily to be the operational aspect, but we’re going to define some broader rules that hopefully can be followed by, uh, the folks that will do it. And those will be the devops team. So I don’t know if that answered your question, but our goal ultimately would be, look from a governance perspective, we can tell you certain things, um, and, and be involved in an advisory role and keep an eye on things. But we’re essentially creating sort of the acceptable, um, uh, the acceptable way to use the platform and allowing them to operate it. So that’s, and keeping an eye on it. If something doesn’t match, whatever we said this should be this way, then that’s where the data comes in. That’s a visibility that comes in. And then we see, well, this wasn’t done. Uh, this wasn’t done well, but uh, haven’t been, I haven’t figured out yet completely. We’re about to do it.

Sandeep Poonen

Yeah, I mean Patrick, I think, well said. I think that’s exactly some of the challenges that we’re facing with it, it’s a little bit. But I think I look at it as a very positive thing because we’re moving in the step in the right direction. We are giving, we’re enhancing the value proposition proposition of security by saying we’re taking things away from you, which is good because it’s a pain they don’t want to deal with because we come in later on and say you’re not compliant, this and that. So in a way we’re enabling those things and the way I look at it is I now just have to find a different reason to come and talk to you. But hopefully it’s a more pleasant conversation to talk about innovation and other things like that rather than the past having to come with some report saying it’s all reds. So I’ve looked at it as, yes, I can get out of your hair for all the things that what used to be negative. I can take that away from it, but it’s almost a platform of a good relationship building to say, now let’s do something more innovative in how I can enable your more.

Richard Seiersen

I think the definition of bureaucracy is the, you’re more bureaucratic where decisions are removed from execution. Right? That, so the more Kevin Bacons you have from that, the more bureaucratic you are. And I think what you were saying was does this create a new, a potential move into more bureaucracy? Is that what I said when you said the separation?

[unclear]

Yeah. Well I would say the success or winning is when you can put more power safely within the hands of people to get things done. This is winning. Um, and I would, if I were to see security, um, creating bureaucracy like where everyone’s always waiting on us. That’s not winning. Right. Um, so everything that we do increasingly as security should be software defined and should really work right in with that process. I don’t know if that helps or not.

Deepak Jeevan

Cool. Um, let me have time for one last question. Who wants to go next? Yes, Randy? Give me one second. I’ll get the mic.

For everybody’s benefit where you’re from, your name.

audience member: Randy Bias

Randy Bias. I currently work at Juniper Networks. Um, but I have a long history. Most people can figure that out. And so you were talking about the need for service meshes around brownfield apps, but earlier we had a panel of people who were actually deploying service meshes in production. Then he said, hey man, these things are complex. There are like hard run, hard to understand. Uh, don’t use one unless you need one. Well, I look at brownfield legacy applications. Anything from mainframes to, you know, kind of our virtualized silos in VMware land. There’s a lot of complexity there. I mean it doesn’t really feel like adding a service mesh is going to remove complexity. It feels like it’s going to add it, number one. Number two, and I haven’t seen those teams really willing to embrace new, so I don’t see how you’re going to explain a service mesh when they know they can just buy another Palo Alto networks firewall, oops, or juniper SRX, I’m in trouble. [inaudible], you know, they’re going to buy some kind of box and they’re very comfortable with buying a box. And if you’re comfortable with buying a box of solve your problem and throw it in the data center, you just keep doing that, right? Because you, you know, your job’s not risked. Implementing like service meshes between your brown field apps or your brown field and your greenfield apps seems like high complexity, high risk, very low value. And I get why people want to build businesses around the brownfield legacy stuff, but you know, all the velocity is elsewhere. So I’d just like to hear you make a really compelling case for the brownfield legacy apps because I just, I can’t connect it

Tom Baltis

Well. So part of it is that, you know, we may not necessarily have a lot of choice, right. And that the brown field apps, you know, where in the past and we’ve, I think seen and expected them to operate in isolated environments, you know, perhaps with whatever integrations exists,

audience member: Randy Bias

but there’s no such thing as an isolated environment.

Tom Baltis

Well, think 20 years ago, 30 years ago, right? Certainly not not the case anymore, but my point is that I think that we talked about, a couple of us mentioned the notion of shrinking perimeter, right? I think that perimeter has shrunken not just around new deployment models like containerization, but it’s also shrinking rapidly around the legacy apps in that a lot of the newer development that we’re doing, newer apps that we’re rolling are expecting to interact with all the legacy applications because in many cases they still run core lines of business or core functions for the business, right? And so the kind of architecture where you still keep your legacy apps isolated in some environment and apart from the newer development efforts is really not really not viable anymore. Right? And I think that’s what’s driving from a brownfield adoption point of view, the interest in seeing whether we can instrument some of these legacy environments. Now that doesn’t mean we’re gonna, you know, rip apart every app and containerize every app with a sidecar Envoy. That’s probably not going to happen, right? But we may in fact either deploy Envoys on individual instances of the operating systems of those Brownfield apps or if that is not possible because of legacy OSs, whatever the case may be, then at least create very tightly managed API gateway type perimeters that are specific to an application or a set of components of that application. Right? That’s requiring ..

audience member: Randy Bias

I get what you’re saying and okay. There hasn’t been a perimeter for a very long time. I don’t even, we should just remove that word from the lexicon because it’s disappeared, you know, 20 years ago by my counting. But it’s all good.

Tom Baltis

Not in, in some industries it’s still around, you know, Mike like ..

audience member: Randy Bias

There’s not a the perimeter, there’s a pretend perimeter. We pretend there’s a perimeter, but there’s not a perim eter.

Deepak Jeevan

It’s like pretend prophylactics.

audience member: Randy Bias

Yes.

I would actually argue that you put, you know, perimeters is a challenging work. This is important though. I think, you know, the reality is, trust is somewhat of a continuum, right? Um, where we have environments where you expect, you can come into this room. Some of you can come into this room, but you have to play nice. That means we trust you. We’ve authorized you with a certain amount of trust. Right? And what we’re seeing, when I talk about perimeter, what I’m just saying is this idea of what do you call a trusted zone where people are allowed to play nice is smaller. The reality is we have chaotic actors, they’re intelligent adversaries and they do things that we don’t expect. They will always be around and they’ve been around since..

audience member: Randy Bias

Let’s go with that term trust zone. I like it. Yeah. All right. So what we’ve gotten the in the, in the enterprise right now is a whole bunch of hub and spoke trust zones inside the hub, right? We put a firewall around it, right? And inside the hobbits, that’s a trust zone for for right now, just give it to me. Right? So I, so I get that that is broken but I also get that everybody loves it and is very comfortable with it, right? They don’t really want to move away from it. And then you’re talking about an API gateway model that just recreates the hub and spoke model. If, if we really want security to be fixed from what it is right now, then we would be taking an approach that was highly distributed, dynamic security based products that would actually move and you know, kind of ebb and flow with the environments recreating hub and spoke in software instead of in hardware using Envoy proxy, you know, for mainframes or legacy brownfield apps. I don’t see how that does anything except move you from a hardware based model to a software based model. It’s like virtualizing a box. You still have a box. It’s just a virtual box.

Ody Lupescu

I think so. I think the, the, the, the, here’s how, the way I would define the perimeter, identity, and they say that identity is a new perimeter. So every identity is a perimeter. You uh, I’m not going to trust the whole table, but you are a separate entity at the table. So that’s a perimeter. You are the perimeter and the way you interact with others needs to be managed in some ways. Yes, you can put them all at the same table and say we want at the same table is the same level of trust, but maybe I want to save any, if I’m at the same table, I don’t want to trust everyone else at the table. So I think what, this is my two cents. In Our world, yes, we’re going to start service mesh in the micro instances environment and we want to bring solution that will help us extend it. We have a monolith so we still have legacy, who you call the brownfield. We have that, we eventually need to get there because our remote access and everything will be based on zero trust. No one will trust anyone. If you need to get access to someone, it will be created on demand, the access to a particular application, for instance, for users coming remotely. Applications will talk to applications again based on identity and a set of policies and we want to do that across the board. It doesn’t make sense just to do it in the microservices and then have something totally different in another environment. So I think you’ll see that identity will be, the perimeter will eventually bleed into the brown field. It will take time. But if you start in the microservices, you have a better chance to get there and it doesn’t have to be hub and spoke. Okay. So that’s the thing.

Deepak Jeevan

So I would love to extend this to three hours, but when the next service mesh day we’re going to do it over three hours and, and I’m going to request Randy to be the moderator in the next service mesh day [unclear]. I don’t think I can be as controversial as you, but it is firstly, thank you all for making time. I know hundreds of vendors chase you and hundreds of millions of threats also chase you, so, um, it’s a, it’s really, really heartwarming to see that the CISO organizations as, are leaning in towards service mesh and not uh, okay, I’m not, I’m not, I’m not going to say the other words, but yeah, you’re leaning in. So thank you for that. Uh, and, uh, I hope in the next RSA innovation sandbox, there may be a few service mesh startups in the finalists, so Rich ..

Richard Seiersen

By the way, a little hint for those of you who are involved in think you might want to participate in either the RSA sandbox or other ones, it’s always good to meet with people who are like, I don’t know, like judges of that and show them your stuff. It really helps.

Yeah. I’m a judge. [inaudible]

Deepak Jeevan

Point noted. I mean, RSA innovation sandbox has determined some really big security winners in before so. So thank you everybody. And so we, uh, we went way over time, so we are going to go straight into the next, uh, uh, session 1:30 session and, uh, we will, uh, get going on that one. So, uh, it’s my pleasure to welcome Louis Ryan, the key creator of Istio at Google.

Back to Blog