devopsy.kinsta.cloud

Tag: TechStrongTV

Adapting Security with Menlo Security

Cloud data security is top of mind for CISOs. User data is moving across clouds, platforms and applications, and if we don’t shift to a data-centric approach, we won’t be able to protect that data.

Jack Miller, head of professional services at Menlo Security and former CISO of over 16 years, addresses the balance of data, security and end-user convenience. Locating security close to users, close to data, and both are essential strategies for adapting security to the expanding presence of data.

The video is immediately below, followed by the transcript of the conversation. Enjoy!

Transcript

Mitch Ashley: Well, I have the great pleasure of being joined by Jack Miller. Jack is Had of Professional Services, and also a former CISO at a different company, and he’s with Menlo Security. Jack, great to be joined by you today.

Jack Miller: Thanks, Mitch, it’s great to be here. Yeah, before joining Menlo, I spent most of my career on the other side of the table as a practitioner. I was actually CISO at four different multi-billion dollar organizations over a span of 16 years. Been in the trenches for a long time, fought a lot of the battles—won some, lost a lot, and here I am today.

Ashley: Such is the career in security, right?

Miller: Yes, it is.

Ashley: [Laughter] No doubt, no doubt. It’s a great pleasure to be talking with you. So, there’s a lot of things, of course, we could talk about, Menlo’s a great company, got some fantastic offerings.

What I’d like to really spend some time on is data. You know, we think about—I like to say there’s three reasons any application development team outside of IT is gonna come to IT. Security is one, and access to data and integration with systems.

Miller: Mm-hmm.

Ashley: So, let’s talk about data in the cloud, or what are some things we should consider maybe that we didn’t have to worry about in terms of securing data, but also not getting in the way with security for end user usability in the cloud.

Miller: Yeah. I mean, look, I think the last point you touched on I wanna kinda drill into a little bit, because I think it’s so significant, right? That, you know, no matter how vested in security an organization is, right, how high they prioritize it at the very top, how much money they’re willing to spend, right? At the end of the day, it comes down to a battle between security and potential impact to your users and your business operations and business processes, right?

And when you think about it, I mean, companies and organizations don’t exist to be secure, right? They exist to make money, they exist to provide a needed service, right? So, at the end of the day, that’s what’s really most important. And so, you know, as the user data starts to move everywhere and it becomes in different places and now, we have the users moving everywhere.

So, we went from a really nice little model in the past where we had our users and our data in the same place most of the time, and now we’re in a model where our users are everywhere and our data is everywhere. And if we don’t shift our approach from a data center approach that we used to have to a data-centric approach, then there’s no way that we’re gonna be able to properly protect the data and do it in a way that’s not gonna be extremely, a difficult situation for the users to access the data, right? We need to make it fast and streamlined and accessible and once there’s a hiccup in their way, they complain and then we have to start turning our controls off, right?

So, it’s a fine dance that we have to walk, and unfortunately, the legacy tools that we have and fitting into that data-centric approach just don’t really seem to work well in this new model.

Ashley: That’s always the struggle with security is the convenience factor. Don’t get in the way of my job, but make sure that it’s secure. Don’t get me in trouble for having a breach or something happening.

So, what are some approaches? Why do we have to think about this where we really can secure the data, wherever it is, and we’re creating more and more of it all the time, right? It’s a huge asset, but growing faster and faster. How do we do that where we can provide end users a level of convenience and security?

Miller: Yeah, I mean, fortunately, today, we have the cloud, and for all the, as a security professional, for all the heartache that the cloud’s brought me over the years and all the challenges that it does introduce, it dos create this new opportunity now where I can, instead of having to have physical controls located somewhere, I can have virtual controls that are logically located all over the world, right? So, now, I can make sure those controls are close to the users or close to the data or close to both, whatever happens to make sense for any given business us case that we’re dealing with.

Ashley: Yeah, that makes a lot of sense, too. And also, I don’t know if automation is the right word, but the manual processes we’ve had in the past of providing access control, whether it be for applications or end users, it’s not realistic with how far and wide we’ve spread data and where it’s all located.

Miller: Yeah, and everything’s so dynamic that even if we could get our hands around it today, by tomorrow, we’re gonna be playing catch up again, right? You know, the cloud has made it really easy for things like shadow IT to flourish, right? So, now, business units can go out and they can add new apps.

So, we spent years in the enterprise putting in robust two-factor authentication solutions to protect our data. Now, suddenly, even if we go out and we do an analysis and we find all of our SaaS apps today and we protect them, what happens tomorrow when another business unit just happens to go out and start using a new SaaS app and they don’t tell you about it?

So, it is a struggle, right? But like I said, there’s a silver lining to it in that the same thing that’s making it difficult for us does give us an advantage to be a little bit more ubiquitous, I think, maybe would be a good word and where and how we can apply security.

Ashley: Mm-hmm. How do you think—and I know, you know, Menlo Security, obviously, being a security product company, but if you thought more generally, more broadly, has the market kept up with the uses and the needs of securing data in the cloud in particular, or we still have a pretty big gap to meet?

Miller: So, I think there’s kinda two parts to that, right? I think from a capabilities perspective, I think that we’re closing the gap, and I think significantly more capabilities exist today than existed a couple years ago to be able to do that, and we’re making, I think, huge strides and great progress there.

From an adoption perspective of getting these new capabilities and technologies out there and adopted with companies, right, that’s where we have the gap today. It’s always hard to get people to embrace new technologies and accept new technologies. And we’ve been talking about digital transformation for years and years, and it’s been very, very slow, the transition. And a lot of what we were seeing pre-COVID was being done to really save costs associated with remote locations, right, and eliminate those expensive MPLS circuits, eliminate redundant hardware and that type of stuff.

You know, now you throw COVID on top where you have, suddenly, all these remote users being remote that were never remote before. So, now, looking at using the cloud and direct access and things like that to kinda solve that same problem but coming at it from a different direction, right?

So, I think what I find interesting right now is that you hear a lot of people talk that this is the new normal, that we’ve proved that remote work can work and everybody’s gonna keep working remotely. And I don’t think this, today, is the new normal. I think that many companies are gonna have their employees come back to the office, for a number of reasons. But I think it’s gonna be very different than it was in the past.

I think now, those areas in the organization that weren’t allowed to work from home a couple days a week are gonna be allowed to, that weren’t allowed to be able to travel and be able to work are gonna be allowed to.

So, I think, you know, we kinda went from this everybody was in the office to now everybody’s at home, and I think now we’re gonna go back to, it’s almost a—who knows where everybody is, because they can do their work from wherever they wanna be.

Ashley: You’ve sort of disproven whatever maybe-ness, maybe partial truths that, you know, “You can’t do this work remotely.” Well, we had to, we did.

Miller: Right.

Ashley: You know, what’s interesting, I think a lot of folks are thinking of a hybrid model, even people that have employees come back to the office is, “Yes, but maybe one or two days of work, they can very easily work remotely.” So, maybe that’s a closer step in the new normal that we’re, at least for the next couple of years gonna be experiencing, and who knows what happens after that? [Laughter]

Miller: Yeah, exactly, exactly. No, I think that’s where we’ll land. I think it makes perfect sense. I think, from a productivity perspective, that’s probably the best path forward. And I think it’s a path we can secure, as long as we’re adapting our approach, right, and we’re focusing on where the data is and securing the data as opposed to, again, not being focused in the traditional of where the office is or where the data center is.

Ashley: Now, I’m curious your thoughts about this. I’m sure others are thinking about it, I just haven’t heard it a lot in the kinda open press or writings. With so many people mobile—of course, if you would’ve had time to plan it, you might have done some things differently, but thinking forward, if we are gonna live in this hybrid world, there’s probably information, some data that you want to, telemetry information you wanna track about how people are using your applications, where they’re using them from. Maybe the same, of course, applies to customers, if they’re more mobile, also, and yet more data that we’re generating and creating to target this, you know, broad ecosystem of data that we’re trying to collect.

And now, so much of that data is going back into how do we create a better experience for employees, how do we create a better experience, better services for our customers? So, all of that data is just as important as the credit card transaction that goes through—well, maybe that’s a little more important, but it’s all important that we can share that. So, the challenge, to me, seems like it’s getting bigger, not smaller.

Miller: Yeah, I think it’s getting bigger, and I think we’re seeing—it’s been a while in progress, right, but I think we’re seeing a shift to more of the ransomware type of attacks. I think that it’s easier for the bad guys to quickly monetize their code with a ransomware attack with less chance of getting caught. And plus, one might argue that, you know, we talk about herd immunity for COVID and things like that. From a data privacy perspective, maybe we’ve reached herd immunity because so many people’s data’s already gotten stolen, right?

So, at some point, there’s so much personal information out there that the data itself starts to become devalued, right? But hey, just like the battle we fight as security professionals that I can’t impact my users, I can’t impact my business operations, right, the bad guys are teeing in onto that, saying, “Look, that’s the most critical thing. If we can get in there and threaten to be able to impact those, then that’s a very viable path for them that they keep following right now.”

Ashley: Yeah, it’s the whole business continuity, right? That’s what the ransom is about.

Miller: Exactly, exactly.

Ashley: Using your data for some other purposes, which can happen, also, as well. I’m really curious, just in your personal story as a former CISO, both organizations large corporations—what are some of the things that you were bringing into the role in Menlo Security that you’re hoping to help? I’m sure you have that list of things, “If I could’ve had a product that did this” or some of those problems that you’d love to help Menlo and the broader community solve.

Miller: Yeah, I mean—so, look, let me kinda break that into two parts, right? Because there was a process that I went through when I decided to switch teams, if you will, right, and go from being a CISO to working the vendor space. And a lot of people ask me that question all the time, “Why did you leave being a CISO?” Right? That’s the role everyone wants to get to today—‘til they get there for a while, and then they wanna leave. But, you know, there are a number of—

Ashley: ____ future that you wish for. [Laughter]

Miller: Exactly. But, you know, one of the big drivers was that, you know, what becomes very clear to me over the years was that most security companies, the vendors, they don’t have a lot of people there that have worked on the customer side before as the practitioners. And so, they don’t really understand the real world in which a company lives and operates, right?

And so, you know, they don’t understand this balance between security and impacting your users. And what that means for you as a CISO, with how far back it can set you—I mean, a story. I’d implemented a large scanning, vulnerability scanning system, a huge vulnerability scanning system. And somebody did a scan one night and his server that was running an old, vulnerable version of WebSphere, and it knocked the server offline. You know, we didn’t get medals because we found these vulnerability before the bad guys did; instead, we had to stop all scanning and we had to redevelop our process so that we could ensure that if we ever took a system down scanning that it wouldn’t impact production. I’m not gonna say that we shouldn’t have done that in the first place and that’s not the right way to do it, but again, it just kinda highlights this one step forward, two steps back, right?

Another example where you see this gap is, ask any security practitioner, right, about IDS/IPS, and they’ll say IDS. Ask any security vendor out there, and they’re all IPS, IPS, IPS, right? But the practitioners know I’m not gonna turn on prevention mode, because the collateral damage to me and my program and what I’m trying to accomplish is too great, right?

So, that was really kind of one of the big things I wanted to bring here. And I feel like heading up professional services is an opportunity for me to do that, because that’s when we’re really working with the customers and we’re trying to get them deployed. And by having that empathy and showing the customers we understand what’s really important to you and we’re not just trying to force a level of security down you, we’re trying to help you be secure but be successful at the same time, I think there’s value there. And that was one of the big reasons why I ended up coming here and what I’m trying to do with Menlo.

You know, the other part of the answer would be from a technology perspective. I think from a technology perspective—and I don’t wanna make this sound like a company pitch here, right, but isolation can provide such a level of value that really, at the end of the day, nothing else can. And I think I’ve always been a big fan of isolation, going back to the very beginning when there were some companies that maybe tried to bite off too much and isolate too many things and that didn’t really work well, right? So, by narrowing down the surface and focusing on what really matters, which is web traffic, isolation can, for whatever connections you can isolate, you can virtually remove your risk, which is unheard of in the security field.

But, you know, it’s hard, it’s not easy. There’s a hurdle to get there during deployment, and if we’re not understanding those challenges for the customers, then, you know, as a vendor, we can start pushing them too hard and we can push them into trouble without intentionally wanting to do that.

Ashley: Yeah, your experience, you and I have that shared experience, because I’ve been both on the practitioner and the CTO profit company side of it as well. It seems like one of the things that I would guess you would bring to this is, you know what it’s like to try to use products maybe similar, maybe the same as what you’re working with, with Menlo. And you’re immediately gonna have a very good feel for what’s gonna work well for the customer, what’s gonna work and what’s not, because you can very quickly assess where they are and what they’re going through, maybe some similar things, maybe different, but you’ve been in very similar shoes.

So, you can help bring something to the table to them that is much more compatible. You know the balance of security versus user experiences versus available versus available versus whatever, you know, reporting to the board—all that stuff, all those issues. And you can’t teach that to someone, so that’s a unique skill—unique value, I should say, that you bring.

Miller: Yeah, well, and, you know, given the options, right? So, interacting with someone like you and being able to—you know, again, a lot of companies want to kinda sugarcoat things. And, you know, as a CTO, right, I’m sure you would agree any day of the week, you’d rather have someone tell it to you straight so you can properly prepare than have someone kinda just make things sound like they’re easier than they are, right? And—

Ashley: The worst problem is the one you don’t know about.

Miller: Right. And so, you know, being straightforward with people and being—you know, oversharing the information and giving them options, right? I mean, at the end of the day, we’re the experts in our technology. So, it wouldn’t make sense for us to ask you, “Well, how do you want this done?” but for us to be able to come to you and say, “Look, you know, here’s a few different options and here’s the pros and cons, right? We don’t totally know all the intricacies of your unique situation, but you know, maybe it kinda fits in with one of these, and what do you think makes sense for you to proceed forward?”

Ashley: Can you tell us a little bit about some of the professional services that you do offer through Menlo?

Miller: Well, I mean, largely, it’s deployment services, right? So, we have a deployment service process we call our QuickStart Deployment service. You know, one of the main tenets is really, we gotta help customers be successful, and a lot of customers, they get a little bit too excited, they try to run before they can walk.

And so, by putting together, really, a defined process that slowly walks you through it allows you to get your users onboarded, start getting some level of value and security from it so that when you start moving into the harder areas, where you might start impacting some people, you’ve got some good ammunition of value to be able to offset the conversation. Whereas, you know, a lot of customers just wanna run right out the gate and turn everything on full bore. And some of them won’t even do that and start with doing it with their executives, right? So, a lot of—[Laughter] I know how crazy that sounds.

Ashley: Good luck with that. [Laughter]

Miller: Right, so, a lot of what it’s doing is trying to save the customers from themselves, right? They get excited, they see what it can do for them, pull the back into reality, let them know—look, here’s the pitfalls, here’s one you’re not gonna be able to avoid, but here’s how we can minimize it, right, the time to resolution, and here’s others that maybe you can avoid if we take some proper steps up front.

Ashley: Good. I’m sure it’ll be very valuable to Menlo’s customers. And folks can find out more about professional services on MenloSecurity.com, I assume, correct?

Miller: Yep, definitely.

Ashley: Great. Well, it’s been a pleasure talking with you, Jack. I wish you the best, and I’m sure it’ll be a lot of fun working with customers in your role there at Menlo, so thanks for joining me today.

Miller: Well, thank you very much, Mitch, I enjoyed it a lot.

Ashley: You bet.

May 25, 2021
Application Security and Continuous Observability with DeepFactor

Today’s modern applications are becoming increasingly complex and released more frequently than ever before, therefore increasing security, privacy and compliance risks. How do you identify the security and compliance risks hidden in your application before you deploy it to production?

Continuous observability enables DevSecOps teams to observe millions of application telemetry events and find runtime security, compliance and privacy risks within the DevOps pipeline, while providing AppSec teams the ability to set guardrails and have continuous visibility with every build.

In this TechStrong TV interview with DeepFactor Founder and CEO Kiran Kamity, we discuss the concept of observability and how to apply it for security and compliance. We also talk about the increasingly important role of AppSec and DeepFactor’s new Observability-as-Code API, which enables DevSecOps engineers to leverage observability functionality in their CI pipeline and gate builds.

The video of the conversation is below, followed by the transcript. Enjoy!

Transcript

Mitch Ashley: I have the pleasure of being joined by Kiran Kamity, who is founder and CEO with DeepFactor. Welcome, Kiran.

Kiran Kamity: Thank you, Mitch.

Ashley: Great to have you. We’re gonna be talking about observability, super-hot topic, but before we get there, tell us a little bit about yourself, a little bit about your background, and then a little bit about DeepFactor.

Kamity: Awesome, yeah. I came to the Bay Area about 20 years ago. I did my undergrad at the Indian Institute of Technology in India in Chennai, and then I came here to Stanford for my grad program. Once I came to the Bay Area, you get addicted to the entrepreneurial spirit, you never leave, this becomes your home. Happened to most people—happened to me as well.

So, the Bay Area is my home, and I’ve had a mix of enterprise and infrastructure cloud computing, virtualization, and DevOps/AppSec kind of background over the last 20 years. I’ve done two companies as a Founder, which were acquired by other companies like Citrix and Cisco. My first company, RingCube Technologies, was acquired by Citrix. We built a container run time for the Windows Operating System before the Docker days. This was acquired by Citrix in 2011, so I was responsible for some of the product teams at Citrix after the acquisition.

Then the bug bit me again, and I started ContainerX, which was a turnkey containers in a box type company, which was acquired by Cisco, and it’s now called Cisco Container Platform. While at Cisco, I was Head of Product for the Cisco Cloud Business Unit, which included container—container networking, OpenStack, and some of the other initiatives that they had.

During that time, as I was looking at what to do next and analyzing the market, a lot of the learnings came to the following. There’s a lot of momentum that has happened so far in cloud native architectures, DevOps, et cetera. And the learnings were that the next wave of innovation is going to be as DevOps becomes DevSecOps. And that’s why I started DeepFactor, and we believe that the next wave of innovation in the world of DevSecOps is observability.

Ashley: That’s something I both relate to and also am just fascinated by other entrepreneurs is that story of, you’re working on what you’re doing now and you’re still kinda looking at, “Well, what’s the next thing coming up, and what might I go do next?” and then you go off and solve the next problem.

Kamity: Yeah, absolutely.

Ashley: Start another company to do that—like you said, you get the bug, it’s kind of a fever. [Laughter] It definitely is.

Well, cool. We’re talking about observability, and it does seem to be the hot topic of kinda late 2020, early 2021. So, let’s first start with kinda how did we get there—get here? How did we get to this place where suddenly observability is a thing and not only a thing, but important to a lot of people?

Kamity: Yeah. Just to qualify it a little bit, our focus at DeepFactor is applying the concepts of observability for security and compliance, which is truly novel, and there’s very few companies that are trying to do that.

Ashley: True. Observability can mean just sort of the next elevated monitoring, right?

Kamity: Exactly.

Ashley: So, you’re [Crosstalk] around security.

Kamity: So far, a lot of the observability plays have been in the logs metrics tracing. Applying the concepts of observability, truly as the next generation of evolution of APM. But at DeepFactor, we’re leveraging the concepts of observability for identifying security and compliance risks in your applications before they go to production.

So, to answer your question about how did we get here, let’s take a step back and analyze what has happened over the last few years, with respect to application development, right? Apps have become a lot more complex than they have ever been today. I mean, think about it—a common application is made of a bunch of different languages. You have a Java service, you have a Node.js service, and you have Angular in the front end, you have lots of different pieces, you have a database, et cetera.

You have a lot of third parties—third party libraries that are baked into your services, third party components that are not built by you such as Nginx and MySQL and MongoDB, et cetera, that become part of your application.

Ashley: A lot of open source, right, in that stack.

Kamity: A lot of open source. Applications are now also being deployed in a bunch of different ways. You have applications that are not containerized, still mainstream. You have containerized applications, you have full on Kubernetes applications, and you have land applications as well, so the deployment of applications has become complex as well.

So, in this world of applications becoming a lot more complex than they’ve been, what essentially happened from a security perspective is that the attack surface area of your application has significantly increased. It is the highest it’s ever been so are, and it’s only gonna go that way.

Let’s take a look at a few other trends that have bene happening in industry. The velocity of releases—that has gone up as well due to DevOps. You’re no longer building or releasing an application once at three months, once at six months. You’re releasing that multiple times a week with DevOps, and different companies are different aspects of that spectrum, there.

Now, when things are more complex and they’re being released at such a rapid pace, there is no way humanly possible for your AppSec teams to find all of the security risks and compliance risks that lie in your application before they deploy to production. At the same time, the risk of these issues being in production is higher than it’s ever been. If you think about it, the sophistication of the bad actors has increased significantly as well over the last few years, and therefore, the nature of the breaches, the size of the breaches, and the damage that they can cause has increased as well. Coupled with that, privacy concerns have increased, resulting in standards like GDPR and CCPA and all of those things emerging as well.

Now, in such a landscape, you’ve got to automate identifying the security and compliance risks that are hidden in your application before you deploy your application to production. And that is where the current tools of just code scanning or identifying issues based on signatures or just DAST scanning your application, et cetera, don’t cut it. You need something that watches your application while the application is actually running in both pre-production environments as well as in a canary deployment of minimal production deployment before you release it to your broader production deployment.

And in that environment, you’ve got to be able to watch the millions of events that are happening inside your application, take that data, analyze and find the needles in the haystack, and therefore determine where the security and compliance risks are and pass on all of this information with rich evidence such as stack traces, metrics, and whatever it takes to fix these issues back to the developers. And a lot of this has to happen in a seamless manner that is nicely tied into your DevOps kinda pipeline, and that’s where observability applied to security and compliance comes in, and that’s exactly what we call continuous observability at DeepFactor.

Ashley: Interesting. I know, talking with you previously and kinda hearing about DeepFactor, you all talk about start left, not shift left—this idea that, really, it starts from the beginning, not, “Let’s kinda push it as far left as we can.”

Kamity: Yeah, absolutely. If you think about it, we’ve had operator specific tools emerged in the last five years with respect to security. So, you’ve had container security tools that identify issues in your Kubernetes configuration or your Docker configuration or vulnerability scanners that identify issues in your host operating system if you’re deploying your app in a VM.

Now, those are all the types of insights. Are there any misconfigurations that could lead to security issues that are very relevant for the Ops people? And those tools are coming up with the idea of shifting left, because you need to find these configuration issues before you go to production so that the Ops people can deploy these applications properly.

But when it comes to developers, their agenda is not securely deploy your application. They don’t care, honestly, about how you’re Docker or Kubernetes is configured, for the most part. They care about what is in their application, securing at the source. And when the agenda for Dev teams is to secure at the source, then all you care about is—what is my application doing, whether it’s my application or some third party that I brought in, or just my interpreter itself when it is running? And can I identify the risks involved and understand my attack surface within the application ahead of time? And that’s why we call it start left.

So, we think that operators care about shifting left. Developers should truly care about starting left.

Ashley: Yeah, it’s interesting, because your point about code scanning and DAST approaches to security is, from a code standpoint, you do wanna be writing a secure code, so it’s a valid thing, of course, to be doing. But you mentioned Lambda, you mentioned, of course, infrastructure as code, essentially, where all this is dynamic, right, in our environments today, and more so, not less, every day, right?

Kamity: Yes.

Ashley: Every day, it gets to be more dynamic. Now, you’re really talking about the whole context of the environment with the application. Kind of, if you thought about it in the network, you’d say all seven layers, right? If you think about it in the security stack of software, it’s application plus all of the other things, right?

Kamity: Yes.

Ashley: It’s interesting what—how do you find people are accepting this idea of run time information being provided with context, you know, this rich information you were talking about, is that something new to developers or like, “Oh, my gosh, I’ve been waiting for this forever” or, “Well, this is really cool. Look at—let me see what I can do with it”? What’s more the experience that developers have?

Kamity: Yeah, so, I think different organizations react differently to something like this. The old way of thinking is—oh, developers don’t care about security or compliance.

Ashley: I’ve never met a develop that wants to write insecure code or unsecure code. [Laughter]

Kamity: Exactly, right? That is exactly what’s happening now where, given the consequences of shipping insecure applications and given the need to be more and more secure at the source, I think developers—and just simply because it’s just not humanly possible for your AppSec teams to identify all these things. Given the talent shortage of the AppSec skill set as well, it is, the responsibility if identifying these risks has to be borne by the developers. Because at the end of the day, the developers are the ones that are writing the code and you’ve got to make sure that you’ve shipped secure code.

Engineering leadership and AppSec teams in various organizations that we’ve been working with have been fully accepted. In fact, they’re fully aware. In fact, a lot of them want this kind of concept, it’s just the lack of tooling today. Because if you think about the current tools that are available, they’re doing the best they can with the existing set of tools.

I mean, they’re scanning the code, they’re trying to scan the application from time to time—but those tools don’t lend themselves well, nicely into seamless integration into your CI pipeline, and therefore, giving developers the insight about, “Hey, here’s where we saw your application did this.” That can only happen with observability tools like what we’re building, because we watch every thread of every process of every service in your application when it is running in test and even canary deployment in your part of production before you deploy that thing widely to a larger section of production. And that is the kind of insight developers do care about.

What we have gotten repeated feedback as we have been building this product with a few development partner type enterprises so far is that, the insights that we have needs to be enriched with richer evidence information so that developers can actually take that evidence information and directly go fix the problem. So, we’ve augmented our insights with stack traces wherever appropriate. You know, obviously, the good old things like CVE numbers and things like that, we have that.

But what we focus more on is not just giving you a list of CVEs, but complementing the insights that your software composition tools give you by giving you run time usage information of that CVE. For example, we can tell you if a tool like Snyk will tell you there are 250 vulnerabilities in your application, DeepFactor will tell you, “Hey, there are 250 vulnerabilities according to what Snyk is telling you. Fifteen of those things have been used by your application at this time, when your application was executing here, ad here is the function, here is the call stack.”

So, that will make it easy for a developer to go, “Okay, now I don’t have to get overwhelmed with fixing all of the 250 things or adding that to my backlog, I can actually prioritize which ones to fix first, because that’s what my application is actually doing.” It’s not about the whole thing that has been checked into your source code, it is what your application’s actually doing that will help you catch the more important things. It’ll help you also reduce the number of alerts that can inundate you.

Now, with all of these changes, the rich evidence, reducing the number of alerts, and to the point, alerts based on what your app is actually doing, developers are finding it more and more meaningful, our insights. And as we grow the company, that’s gonna be our primary focus.

Ashley: That’s always been the challenge with vulnerability scanners and code scanners is, yes, I get all of those results. What of those are real? Yes, they’re all theoretically possible. I may not be using it in a way that actually exposes me to that CVE, that vulnerability.

But what you’re saying is, you’ve actually detected the use in the application or the software stack of something around that CVE that’s worth looking at. Hopefully, you’re cutting down on the number of things that are actually, they go look at. You can ignore the rest, if you will, or at least know that they’re much less likely to be an issue.

Kamity: Yeah. We do not give you too many alerts. We give you the alerts that are relevant for your application because we watch the millions of events that are happening in your application in every part of your application, across various layers of the stack—like, system caller interface, library calls that your application has made, network behavior, web and API, all of that.

And based on that data, we treat it as a data problem. So, we take that data and then we try to identify anomalies and detect that these are the risks that lie in your application from a security perspective, and this is how it maps into compliance. So, we will tell you that these are the security risks in your application and in our next module of the product, we’re gonna tell you that this can hurt your PCIDSS, and here’s the number, basically.

Ashley: Mm-hmm. It definitely is gonna improve your relationship with the security and compliance team, right? If you’re solving these problems before it gets to them, they have to ask, “Well, did you do anything about this? Are we susceptible?”

Kamity: Yeah.

Ashley: Talk a little bit about—so, where in the tool chain and the workflow pipeline, where do you fit? Where does DeepFactor play?

Kamity: Yeah. The best way to think of us is, if you take a step back, if you are thinking about your DevSecOps initiative in total, you want to plug in into a bunch of different points from a security perspective into your CI pipeline. Your developers write code. The next step should be you try to find risks in your code. That’s where the SaaS tools come in, they find the risks that are there in your code.

Then you create your build artifacts—let’s say, your executables, your container images, and whatnot. Then you try to find risks that lie in your build artifacts. That includes your code, any third parties that you’ve compiled together and created your services. It’s still static, though. You’re not running them yet. Tools that allow you to identify risks in your build artifacts could be container scanning tools, like image scanning tools that scan your container images and find issues or software composition analysis tools like Snyk and Black Dock and tools like that. These tools find vulnerabilities that exist in your components after they’ve been built.

Then you run your application, you’re testing your application. Either you’re testing it in a test environment or you’ve deployed and you’re testing it in a minimal configuration of your—like, a canary deployment in your production. During that time, you’ve flicked DeepFactor on. DeepFactor doesn’t require any changes to the code of your application; you’re simply running your application.

And that’s where we’ve built a significant amount of IP. You know, my Co-founder, Mike Larkin, he’s the CTO, he’s the father of the OpenBSD hypervisor. And our senior engineering leadership members came from Qualys and FireEye, having been in the area for 20 plus years working on security products, each.

So, we’ve created something that involves zero touch, pretty much. You don’t have to touch your application at all, you simply run a command called DFCTL, just like KubeCTL, we came up with DFCTL. So, you do DFCTL, run your app; or DCFTL, run your container; or you drop it into Kubernetes. We have a webhook admission controller that you simply drop into Kubernetes, and then any pod that you want to be monitored, you simply can specify a config file and that pod gets monitored automatically with DeepFactor.

Now, the way DeepFactor inserts itself is completely behind the scenes. It’s language agnostic. You don’t have to worry about, is it Java, is it Node.js—DeepFactor figures out that it’s Java or Node.js and does some specific things and finds out more information.

So, you simply run this, your application is running in your test environment or your minimal production environment, DeepFactor observes everything that it’s doing. When the tests are done, it tells you—you throw your automated tests at it while your application is running, just like normal. And then when it’s done, DeepFactor gives you all of that information about what insights have been found and what’s the evidence information that’s pointing to the insight. Is the issue or the risk presenting the attack factor lying in the code that you wrote? Is it lying in a third party that you brought in, or is it at the interpreter level itself? All of them are risks as far as the attacker is concerned that could be exploited, so you need to be aware of where your risks are.

Ashley: Now, are developers putting in some library calls or DeepFactor code into their application stack as well, then? Is that how you’re getting into the software, knowing what’s happening inside as well as outside?

Kamity: Actually, that’s the beauty of our IP, and we’ve filed a few patents in that area. Developers do not need to write any code to change, or change anything in their application. You simply enter DFCTL and run your app and DeepFactor inserts itself into the application at your run time, completely seamless to the developer, and when it’s done, it unplugs itself and your application and gives you all the insights.

Ashley: Wow. That sounds pretty cool. I can imagine that’s a big plus for developers. [Laughter] Yet something ls they don’t have to debug, right?

Kamity: Exactly, yeah. That’s the significant part of our IP.

Ashley: You know, it’s interesting you mentioned your team comes from a number of other security companies that have been around for a while—you know, you mentioned Qualys and others starting in the scanning, the vulnerability management space some time ago; that’s about when I got into security, too.

What do you think we’ve learned from those types of companies and those experiences that we’ve sort of changed our perspective about where we are today, just given—yes, we have much more complexity in software, much more porous security issues, but what have we learned from all of that security scanning that’s helping us?

Kamity: Yeah, no, I think there have been numerous, numerous learnings, and the learnings have evolved over time as the landscape of application development has changed as well. You know, you’ve had tools in the past that were designed based on the applications of the past. But tools of today and tools of tomorrow are different, because the applications of today or the applications of tomorrow are definitely trending in a different direction.

One example of the thought process itself is that, you know, when things are in single digits or a lesser number, it’s okay to have manual scanning, manual testing, once in a while test it and then find information, which is kinda the old kind of scan once in a while, identify it, or bring in a pen tester once in three months, you know, check some boxes and get it done kind of thing.

Those are all great and they’re still relevant even now. What has become even more important is why you do those once in a while scans and checks. You’ve got to make sure that you get in the habit of securing at the source. You can no longer imagine that your infrastructure or the perimeter is gonna secure your application properly. You’ve got to make sure that you build your application securely to start. And that fundamentally has changed the kind of tools that we need to build in order to equip the developers who build applications to secure at the source.

At the same time, I think the role of AppSec has become even more important than it has ever been. Because, you know, sometimes I keep getting asked, “Oh, are you saying that developers should use these security tools? That means the AppSec teams are no longer relevant?” That is totally wrong, because AppSec teams, their job is increasingly more relevant. Because if you take a step back and you look at the number of attack vectors that are there in your application, we just talked about how your pipeline should be architected—secure at the source, making sure that you scan your code, scan your builds, test your running applications, and identify risks in all of these areas—who ties them together? Who comes up with this overall strategy? Who comes up with that triaging process and passing the evidence back to the developers, identifying which ones are important and which ones are not?

All of that should come from the AppSec person in the team—AppSec or if AppSec is assimilated into your DevOps and we call it the DevSecOps person, that’s the role of this person is to make sure that he or she is the shepherd of your CI pipeline from a continuous security perspective and then feeds all of that information back to the relevant parties. Some of that could be your developers, some of that could be to your engineering leadership, and some of that could be to your security leadership.

Ashley: Mm-hmm.

Kamity: That is how I see the organizations of tomorrow shaping up, learning from what has happened over the last 15 years to 20 years of innovation in this area.

Ashley: I think that makes a lot of sense. Otherwise, (a) we’re just throwing tools at it, everybody’s doing whatever and who knows whether that’s helping us improve and improve security. And you mentioned the data coming out of it, right? That can also be used for continuous improvement, continuous learning, what are trends that are happening in our application?

Suddenly we’re seeing much more of this technique or this architecture or this environment being deployed that, you know, not always do the security people have exposure to that early on in the process. So, it’s a good way just to know what the heck is goin’ on and then also, you have an idea about how all of your security tools, developer or non-developer, fit into an architecture that makes sense.

Kamity: Yeah, exactly. I mean, imagine flipping a switch and identifying, “okay, these are all the touch points that my application has and these are the millions of things that it’s doing” and condensed very well to, “these are the red dots in that whole story, and this is where your risks lie.” That’s powerful, and I think it’s the AppSec person’s job to set all of that up and make sure that a framework is created and then say, any time something that comes up, you know, make sur that you pass it on to the developer with the appropriate evidence and work with the engineering team to decide.

Because when you have so many different services and so many different languages, the AppSec people, especially because they’re already short staffed, cannot possibly know everything about the business logic of the application, resulting in those decisions that could have been made to bring in component X and component Y and whatnot.

Ashley: Mm-hmm. You know, Kiran, one of the things that I’ve said over time is that security people need to get a greater understanding of software architecture. They don’t need to have to be developers, right, that’s not what their skill set is, nor necessary their desire. But you can’t treat security as this hard outer shell, you know, we just keep making it smaller and smaller. And now all you’ve got is thousands or hundreds of thousands of small outer shells and now you’re not securing anything, any more.

It seems like the AppSec team can play a really important part of helping bridge that gap of what are we doing specifically, what are the architectures that we’re using, what might be some of the security risks that maybe a security engineer is just not fully up to speed on or trying to keep up to speed on as it’s changing?

Kamity: Yeah, absolutely. Imagine the power of flipping the observability switch and the AppSec person going and saying, “Hey, Dev team, we noticed that in this particular piece of your code, you’re using an API that has been deprecated by the operating system” or, “In this particular piece of code, you’re invoking memory improperly, because this tool is showing me exactly what was done when this particular area of memory was allocated with the wrong permissions. Or, “This is an area of code where your interpreter is doing something wrong. Is it possible for us to go change the version of the interpreter that we’re using, maybe upgrade it to the latest version or put a patch?” Or, “Do we need to, in order to mitigate this thing, assuming that there’s no fix in the interpreter, do we need to go put something in our WA in our infrastructure to block the particular attack from happening?” Or, “Should we report this problem upstream to Java itself, the Java community itself, so they can go fix the problem in there?”

So, lots of different things that could be done once the AppSec team is empowered with this much rich information about what’s happening in the application.

Ashley: You know, something I don’t know that we talked enough about, we talked about how rapidly and how quickly we’re delivering software applications now. The environment of the software, the API calls we’re using, the libraries, the services, interpreters—all of that is changing in parallel very quickly. Sometimes you don’t feel like you have time to keep up with it, or that’s all you do is spend your time keeping up with that, not kinda delivering business value.

I think folks that are maybe not involved too deeply in the software creation process really realize not only the complexity but how much change there is to deal with. There’s a lot that goes into that. We talk about technical debt or backlog or whatever—it’s a lot more than that, there’s much more to it. [Laughter]

Kamity: Absolutely, there’s a lot more than that, and I think having an informed security team as well as, you know, coupled with a structure and the right tools baked into your pipeline, which results in informed Dev team, can result in goodness overall. You’ll end up identifying security and compliance risks earlier in your Dev cycle. You’ll end up fixing those things earlier, and therefore, you will end up shipping a much more secure application, and it’s a cycle. Every time more developers check in code, you know, this kind of identification happens automatically, and you end up identifying more and more risks and fixing more and more things, resulting in more and more secure applications into prod.

Ashley: Mm-hmm. Awesome. Well, what are some things folks might have access to you can help them get started? Obviously, they can download HIV testing product or get involved that way. Do you have some other tools or things that they might be able to use to make it approachable to get into this kind of an approach?

Kamity: Yeah, they can go to DeepFactor.io to check out the product, understand more about the product. And if they want to get started, they can either download the community edition that is now free for 10 user teams or less. If you need any help with setting up the product, you can reach out to our Customer Success person.

We’re also giving away a free DevSecOps Risk Assessment to companies that are working with us as we expand our organization more. This will help any engineering team or any security team to get a free assessment of what DeepFactor can find in their applications so that they will be able to identify, “Okay, these are the kinds of things DeepFactor finds, and it’s useful for me and here’s where I need to go next” kind of thing.

So, that DevSecOps Risk Assessment is completely free. Contact us, hello@deepfactor.io or just go to the website to learn more.

Ashley: Awesome, great. I know you’re also speaking at the Cybersecurity 2021, I think you have a couple of sessions there, right? The dates are March 4th and 5th for that event.

Kamity: Yeah. We have a couple of speaking sessions at Cybersecurity ’21. We have a virtual booth there as well, so do check us out. There is a—you know, our team can answer any questions or even try to explain to you or help you understand what DeepFactor can do and identify in your application.

Also, today, we’re launching Observability-as-Code. It’s a new module that we’ve created, and a product that allows people to bake in observability into their CI pipeline, similar to how Infrastructure-as-Code enables DevOps and DevSecOps folks to spin up, spin down infrastructure in their CI pipeline itself and other related scripts. You can do, now, the same thing with observability for security and compliance with DeepFactor. So, you can use our API, we have a Swagger doc ready, you can use our API to invoke DeepFactor as part of your CI pipeline, get the results, triage the results, use that results to block, if there’s any P1s you want to block the _____, you can do that. You can do things like that with the Observability-as-Code API that we just announced.

Ashley: Excellent. Well, I hope folks will check you out. I think it’s a great path to be going down, and I’m sure developers appreciate writing more secure code, but completing an application that’s more secure that they’re involved in developing.

So, Kiran Kamity, great to have you here, CEO and founder, co-founder—I guess founder [Laughter] of DeepFactor.io. And be sure and check out the speakers that you all have at Cybersecurity 2021. It’s a great conference and we look forward to hearing more from you, there. Thanks for joining me today. Great to talk with you.

Kamity: Thank you much. Appreciate the opportunity.

Ashley: You bet.

Kamity: Bye.

February 25, 2021
Open Source and the Mainframe with Rocket Software

Open source enables developers to quickly create and deploy containers and business services across public and private infrastructures. Open source tools allow DevOps teams to harness the power of the mainframe.

In this TechStrong TV interview, Tim Willging, chief architect and strategist, and Peter Fandel, mainframe open source evangelist at Rocket Software, join Mitch Ashley to discuss advancements in the use of open source software with mainframe apps and tools. Tim and Peter challenge some long-held beliefs around mainframes, open source software and the increasing role open source is playing today.

Rocket Software is a global software development firm that offers enterprise products and services.

The video interview is immediately below, followed by the transcript of the conversation. Enjoy!

Transcript

Mitch Ashley: Hi everyone, I’m very pleased to be joined by a couple of great gentlemen here to talk about some interesting open source, security, mainframe, DevOps, all kinds of good things. So I’m pleased to be joined by Tim Willging who is chief architect and strategist for the mainframe business unit with Rocket Software and Peter Fandel, senior director of product manager mainframe open source. Welcome, guys.

Tim Willging: Hello, thank you.

Peter Fandel: Hello.

Ashley: I think I might have said your name incorrectly, Tim. Is it Willging? I don’t know if I said that right.

Willging: That’s correct. That’s fine.

Ashley: Okay, good. Would you start? I’ll have you both introduce yourselves. Maybe you can also introduce the company, Tim, and then we’ll have Peter do the same?

Willging: Sure. Yeah, I’m Tim Willging. As Mitch mentioned, I’m the chief architect and strategist for the mainframe business unit at Rocket. I’ve been with Rocket about 15 years and spent the majority of my career developing commercial solutions for the mainframe and mostly around database tools, DB2 tools. Rocket Software has been in existence for 25-plus years and is a privately held company and specifically we do software that’s not just on the mainframe but let me talk mostly about the mainframe software.

Rocket has a development partnership with IBM and many of the solutions we develop are IBM branded; but we also have many things we’re doing Rocket direct; and open source, particularly the subject of this call, is one of those things that we also sell direct or partnership with companies direct to provide that open source. So Rocket has a long history with the mainframe and we believe in its future and in its sort of importance in the computing divisions across many of the largest companies of the world.

Ashley: Excellent. Great. Peter, if you would introduce yourself.

Fandel: Sure. Peter Fandel, again. I’ve been at Rocket for 19 years. The great majority of those years in engineering management, and I took over management of the open source porting team about, four or five years ago and transitioned to product management about a year ago. And I manage both the open source porting portfolio as well as the Zowe portfolio, and both of those portfolios are critical components to the modernization story for the mainframe in large part because of the huge amounts of open source that are out there that you can _____ can get them running well on the OS as well as attracting talent, the next generation of developers. So that’s really our focus area for open source.

Ashley: Excellent. You know, maybe you ought to start – and I started my career in the mainframe, too, and so I understand, kind of get where you’re all coming from in the market. There’s a lot of built up beliefs about mainframes and applications and whether you should think about porting or not or, you know, replatform them, leave them alone. Probably like you, I’ve learned it’s very costly and also fraught with danger to just go rebuilding applications, you know, because you think you want them on a different platform. You have to have a really good reason. But open source is actually a really important part of the mainframe ecosystem. I think maybe folks don’t really realize how important it is. How would you guys kind of set that up to give people an idea for the role that open source is playing in the mainframe environment today?

Willging: Well, I’d start off by saying open source is incredibly important part of IT computing. I mean it’s something early career professionals are learning. It’s a huge way companies are running their business today and rather than writing things from scratch, many are starting with open source and then augmenting or augmenting existing systems with open source to modernize that open source because of its collaborative nature, how different companies and individuals contribute to that open source based on the needs of the industry. You really can’t separate the needs of our organizations that are running mainframes from that open source. Open source is a critical component of running your compute division. So without it, I think the mainframe would be, you know, would have a big missing part in what companies need to run their business today.

Fandel: I think also there’s a huge cost savings associated with that because you take any recent graduate and even not-so-recent graduate of any comp sci program and you ask them to start developing applications, they’re going to expect to build those applications on open source building blocks. And if they’re not there, your cost goes way, way up. As well, another area where open source is a must have is DevOps where if you want to – do you want to have a different DevOps tool chain for the mainframe than the rest of your organization or do you want to unify that? And if you’re going to unify it, it’s got to be open source based.

Ashley: It’s a massive source of innovation and I don’t know if we’re here yet, but if we aren’t, we’re quickly reaching a point where you can’t operate a company, a software team without open source software. And if you aren’t using it, I can promise you your competitors are. So take advantage of it, right? Well, let’s talk a little bit about I know Zowe is of course a big important part of your strategy. Break it down for us. Go into a little bit more detail about where the places, roles that open source does play a role in the software development process and operational systems of mainframes, kind of paint that picture for our folks, our listeners.

Willging: I think there are a lot of different ways it plugs in, but the one that I hear most of the companies I talk to is precisely what Peter just said. You know, the mainframe through many years of existence has been very waterfall-ish I’ve heard some companies because of the reliability. It’s the security, the maintainability of the mainframe that there’s a process which changes are rolled out in large batches. As companies modernize the mainframe and they start to add components to those mainframe applications that are off the mainframe, like in the hybrid cloud or have a web frontend or a mobile app frontend to a backend service or application that’s running on the mainframe, they want to be able to build, test, deploy the components of that application that go across the mainframe and those different computing platforms in the same manner.

And to have tools, pipeline building tools, pipeline organization tools that have tools that build these environments, run the tests, destroy these environments, they need those open source tools to run on the mainframe to be able to drive those processes in a unified manner across all the different components of that application. So many companies today are just starting – you know, mainframe companies are starting on this journey. Many of them are hand rolling over the years have hand rolled sort of tools to try to have them plugged in, but that can get expensive as we’re talking about. So to get that open source running on the mainframe it’s important for them to be able to deploy those DevOps principles and practices in that application management lifecycle process.

Fandel: I would –

Ashley: Very much so. Of course there’s also more with that too. Go ahead. I’m sorry, go ahead, Peter.

Fandel: I was going to build on what Tim said by introducing a really important distinction and that is that there is three very different ways you can get open source onto the mainframe. Most of the open source we’re talking about is units based. And you can do it by a Linux on Z, you can do it by a zCX Docker container or you can do it by UNIX System Services. And it used to be that the low cost way of doing that was Linux on Z and now more recently zCX because the porting is not much work to do because it’s all automated just port to the hardware which is done by compiles on those systems.

But doing it on UNIX System Services is a lot more time consuming if you do it manually. But the advantage if you do port well on UNIX System Services is you’re close to the data. I mean if you’re running open source on Linux on Z or on zCX, it’s akin to running it on another machine on the network. You don’t have direct access to the data. Everything has to pass through TCP/IP. But UNIX System Services is part of z/OS and so you have direct access to all of the important data in your organization that MVS data. And that’s a key distinction. Where Rocket plays is open source on UNIX System Services on z/OS. So we are close to where the data is and we have solved the problem of high cost of porting through this GCC/GLIBC technology where we essentially automate the port of open source by simply compiling and linking in GCC and it injects the z/OS specific changes directly into the binary output of the build.

Ashley: Talk about that process. Is that something that you’ve been doing a while? Of course going and changing binaries, most folks probably don’t do that as a natural first thought. But it does sound like a pretty straightforward way of minimizing the steps that you have to go through to get to begin using this. You can actually do it ____.

Fandel: Yeah, it’s just we’ve been working on this GCC/GLIBC port in this manner for over two years, and it’s just coming to fruition now where in first quarter we will be releasing new versions of several of our ports that are not ported by hand. They are ported simply by building them with GCC, and we hope to have transitioned our entire portfolio by the end of 2021 to be built in this manner. And that means we no longer have to modify the source code because upstreaming is no longer a question, an issue. It means that we can turn around security vulnerability fixes much, much faster than we could otherwise.

Ashley: I don’t mean this in a hyperbolic way or kind of playing up to you in any way, but that kind of an approach can be a pretty big game changer because you’re really asking people, it’s a low lift instead of a heavy lift to port if you will.

Fandel: Yeah.

Willging: I’ve talked to many through the z/OS community who believe that due to the effort of going through these ports in the past, they felt that a better strategy was to run your open source close the mainframe – I say close with parentheses – or on a partition on the mainframe that’s running zLinux because the porting effort to get open source running on zLinux is minimal. And so they felt that the version currency, the security fix as Peter said, and the breadth of the packages available, open source source packages available on z/OS proper would always be behind. So they felt that was a better strategy to run it on zLinux.

We don’t believe that at Rocket. We believe, as Peter said, that there are technical advantages to running that open source both from a DevOps standpoint but even more so from somebody who is looking to augment a legacy application say via some Python library that they’re looking to deploy where they’ve found some open source with a particular function. Running that Python on z/OS and accessing the data directly in concert with the legacy application that’s running or via some subfunction in that modernization effort is vastly different than running that Python in zLinux or on a machine off-platform and reaching into the data. The latency of what you can do, trying to embed that open source sort of in transaction, in the code in transaction becomes much more difficult to do. So we feel that Z customers as they’re looking to modernize will benefit greatly from opensource running on Z proper.

Ashley: And as I understand, I think as you were describing it Peter, really you are talking about that compile process, right? That’s where you’re introducing GCC/GLIBC libraries. So that’s where this process is happening, changing things in a binary to adapt it to be able to use open source. Is that pretty much it or what else do you have to do to verify or test it or what are folks going to want to go through as they start to introduce this into the process?

Fandel: Once we build it, we obviously have to run it through the test suites and we have two forms of testing. We have the built-in test suites that most open source products come with. I mean if you go to Git or Python and you download the source code from the community, it will be the product plus a huge volume of test code, self-test code. And so we execute that test code to make sure that it performs with the same results as on a test UNIX System. I think we used Ubuntu as the comparison and we compare the results. And if there’s any divergence on z/OS, then we inspect those divergences.

And then in addition to that, we have a series of tests that test the z/OS specific capabilities that you want in open source. That’s mostly relating to the ASCII/EBCDIC conversion because z/OS and including UNIX System Service assumes EBCDIC is the default. Most of the data that you’re dealing with is in EBCDIC. And so our philosophy in porting on UNIX System Services, ASCII is the default internally. We compile with ASCII. Communication between open source packages and programs is in ASCII. But when you reach to the operating system, that’s where the conversion has to take place. So we have extra test suites for all of our ports that make sure the ASCII/EBCDIC conversion is taking place correctly both in file IO and pipes. So that adds to our testing process. So it’s not just build it and ship it. We do thoroughly test as well.

Ashley: That’s great. I’m glad you explained that too because there certainly are some fundamental differences in the operating system and environments down to the characters that –

Fandel: Sure.

Ashley: – that we’re using. How about are there any kinds of applications that are more easier to port this way? That’s not the right way to say it. It’s not porting it but, you know, understand starting to use open source this way or others that maybe are a little more challenging, you might want to wait to take on that kind of an app? How would you recommend people get started?

Fandel: Well, I mean we found that the porting a language is the most challenging because it just dips into every aspect of the operating system. So our conversion of the Python and Perl ports will be the last ones we release at the end of 2021. Our Python and Perl today are still, the ones we’re releasing are based on manual porting efforts.

Ashley: Okay, good. Any thoughts on that, too, Tim?

Willging: I thought your question originally was like talking about a customer application they were looking to augment and add open source to what might be easier.

Ashley: I would like to go there, too. That actually was my – but I’m glad you answered it the way you did, Peter. I’m curious from a customer perspective data intensive, things that are ultra-high security, high volume, lots of parameters can go into deciding what kind of an application you might use first to go down this path. Any thoughts on what you’d recommend to look at, to pick what app you might try this with?

Willging: I mean there are a lot of mainframe applications that leverage CICS for online transaction processing and CICS is a great environment to deploy opensource. It’s been very forward thinking in its development to take and say a CICS application that’s written in COBOL and say you wanted to augment that via some modules that are written in open source language. That’s very possible and to make that communication really between the first thing you think about is there a runtime environment that’s involved, how do I want to lower that runtime environment so it doesn’t load every time that transaction is moving or it’s moving from the legacy code to the modern language?

If there’s not, if it’s just a binary without a runtime environment, then you don’t have those types of concerns. So thinking about that and thinking through how you’re laying that out from an architectural standpoint and making sure you think through that. The speed of transition between legacy and open source language environments, that’s probably the biggest concern depending on what you’d like to do. But many companies have successfully done this and gone off and said, okay, we don’t want to necessarily go and rewrite my 30 million lines of COBOL.

Ashley: In a billing system probably not where I would start.

Willging: But there’s a new function we would like to add that potentially goes and augments via reaching to another system where customer data is available that you certainly can do that and many companies have done that successfully. Again, leveraging more modern languages and having that available for that augmentation is much cheaper, much less risk than is involved in a total rewrite and a re-platform which is again even then much of your language that you’ve written or much of what you’ve written won’t even necessarily run on a new system in the cloud. So replatforming is also very expensive or very risky depending on, again, the number of lines of code.

Anyway, I probably went too far there but that’s sort of how I think about it from an online transaction standpoint. But a batch, different again, that you might just have some data that you want to reprocess and write a new output from that batch and augmenting there with open source is much easier because, again depending on the language can it run in batch, does it require to be hosted within a web server? But even then you can still have a batch process that alerts a web server to now go read this files so you can embed your open source within a say WebSphere Liberty or some web server that can go and even augment batch processes that way. It’s really getting the right architecture down first to say how you want to do that.

Fandel: Another area is data science and machine learning. You have for the past 20 years or so you’ve had academics and scientists and corporate engineers developing machine learning extensions, data science extensions, and they haven’t been writing those extensions in COBOL. They’ve been writing it in Python. And so that’s the go-to language for data science.

Ashley: It does give you access to a lot of new innovation just because of the language as well as the platform –

Fandel: Exactly.

Ashley: – and software stack differences. Two other areas I’d like to explore in our kind of time remaining, you mentioned DevOps and the role that open source plays in this. How does it help facilitate moving a mainframe application or developing a mainframe application now into more of a DevOps fashion? Are there some things inherent about because it is, you know, libraries that have a compile time process and there’s other tools? There’s Zowe and things like that can help you with interfaces and tool chains, workflows, things like that. What are your thoughts on that topic?

Willging: Go ahead, Peter, you start.

Fandel: Well, I was just going to say that Git, since we release Git I think it’s three years now for z/OS, I think it was our number one download within 30 days of release. Everybody in the world is using Git now –

Ashley: It starts with Git, doesn’t it?

Fandel: – or Source Code Control. And so it, like I said before, just enables you to have a unified DevOps pipeline and that’s just huge.

Willging: Yeah. I mean to add to that, to have all of your source code in Git and then kick off a build process but then thinking of the mainframe and some of its legacy components like the parts of an application that help that make up the database. You know DB2 is very big on the mainframe. DB2 for Z. So to say that you can take those parts of the application touch the tables or smooth the tables in DB2 and extract those and then store those in a source code management repository because in DevOps you really want to store everything as code and represent everything in code so changes can be tracked over time. So taking open sourced, taking some even commercial tooling, taking some open source scripting languages, opensource to allow you to interact with a DevOps pipeline that’s running off the mainframe that’s driving the build and reaching in. You know, DevOps is really, again, not a product. It’s a culture and it’s a –

Ashley: It’s a process. It’s a way of creating software, right?

Willging: And so to build that DevOps pipeline using those tools but then have the tools – the DevOps tooling and scripting and running on the mainframe to be able to interact with the mainframe sometimes is a combination of open source, purchased tooling, and then hand rolling the pieces in between to fit your company’s needs. That’s really not possible. Again having a Git client for the mainframe and a lot of the other tools there are really important for that process.

Ashley: I’m curious about the security side of this. You know, a lot of application of air gap requirements things like that or the frequency or timeliness of security fixes. I don’t know if there’s a lot of difference between mainframe environments versus open source. That tends to happen of course more transparently. Maybe what are some of the advantages, pros and cons from a security standpoint of taking this approach?

Fandel: Yeah, I’m glad you mentioned that because that’s one of the major changes that we have put in place this year with the introduction of the Rocket Open AppDev for Z Solution Bundle. We have switched from sort of old style, one at a time download of tarball and FTP it and then run through ten steps to set environment bevels and get it installed for each source tool or language. And as an example, GIT, which has four dependencies meant four or five downloads. Then you FTPed them over, and then you do the 10 steps four or five times. It’s like _____ way. We’ve switched to conda as the system for downloading, installing, and deploying open source on z/OS. That has made a huge difference in terms of the user experience and the ownership experience.

So it’s now once you have conda installed on your mainframe, that takes about 30 minutes including the download and the setup, then it’s a single command to install Git and all of its dependency from the command line; and further, conda has this concept of a channel which is their word for a software repository or repository of software you download from. Conda supports something called a file channel as well as internet channels.

So in addition to this, we have set up two internet channels at Rocket, one public one at anaconda.org that anybody in the world can use to download from and a secure channel server on our network that is authenticated for our customers on support. And then additionally you can set up a file channel which is on your premise which is ideal for air gap systems. So if you have an air gap mainframe, you don’t want it to have a connection to the internet, you can set up a file channel, populate it with the full contents of our bundle and then all of the developers within your organization can download at will from your on premise channels. That’s a big advantage in the area of security.

Ashley: Those some really big ones, big changes.

Willging: It is a big change. I mean there are a lot of companies that have said that the only delivery mechanism for software to my mainframe is through IBM Shopz. So you know, I have some feelings on that. I think that’s old school thinking as far as I’m concerned, but there’s still a culture amongst many mainframe customers that that’s it. I think that is changing and to make it simple, to guarantee that it’s secure and to provide options is what Peter just went through I think is important to help increase adoption of open source on the mainframe. And so Rocket is really leading in that area to help make that possible.

Ashley: It is culture. It is sort of tried and true. You know, if it’s not broken don’t fix it. But on the other hand, when you start to demonstrate new capabilities, new benefits, speed improvements, more security, whatever it might be, access to innovation, suddenly that becomes maybe a compelling reason to start to break down some of those traditions or barriers or kind of think about adding this as a capability. You’re not talking about changing everything, right? We’re talking about adding capability to how you create software in a mainframe and expanded environment, correct?

Willging: Yep, exactly.

Fandel: Sure.

Ashley: Good, good. Well, where can folks learn more about this? I don’t know if you have any trials or free downloads or you’ve been in beta on some things that are GA or coming out in GA. What’s the best way for folks that want to engage with you and find out more and kind of give this some –

Fandel: I think you can Google z/OS Miniconda. You can Google Rocket Open AppDev for Z which is the product release from September and that will lead you to our product pages, our download page, documentation on how to install z/OS Miniconda which is the bootstrap to get you started. There is a couple of published videos. If you look at the Open Mainframe Projects Summit from September and look for, under the video there, “Demonstrating a Secure System for Downloading and Installing Software on z/OS,” you’ll find a video there that shows how it’s used.

Willging: The only thing I’d add to that is go check out zowe.org.

Fandel: Thank you, Tim, yes, absolutely, zowe.org.

Ashley: Don’t want to look past that, of course.

Willging: It completes everything else Peter said.

Ashley: Very important.

Willging: Important stuff. We haven’t really talked much about Zowe, but yeah.

Ashley: We’ll have a chance to do that. Would love to have you back and we can delve into that. I really would like to explore some more about this delivery of software into production and how do we start to evolve and expand helping more organizations consider how they might do that so there will be some great areas to explore further. So look forward to doing that with you. It’s been a lot of fun talking. Any parting thoughts before we wrap things up here?

Willging: Just real quick, I’d encourage those mainframe z/OS shops, if you don’t have a policy for downloading, consuming open source, I encourage you to get your thought leaders together, you know think about the advantages that open source will provide in your modernization efforts. Check out zowe.org but create a policy to not only to consume but contribute. Get involved in the projects. It’s a way to expand your employees’ interest in the mainframe to make that open source there available. So if you haven’t done it, you really should do that.

Ashley: Access to more talent I think as Peter was mentioning earlier. It really is opening up new pathways as opposed to replatforming and a lot of not very attractive options sometimes that you now have because of open source. So folks definitely should consider this, look at it, get into it, get involved. Great. Well, gentlemen, it’s been great talking with you, both Tim Willging and Peter Fandel from Rocket Software. Take care, gentlemen, we will see you next time.

Willging: Thank you.

Fandel: All right, thank you. Take care. Bye-bye.

Willging: Bye.

January 28, 2021
TechStrong TV: How to Build and Refine Your DevOps Skills with OpsCompass

The role of DevOps is constantly evolving as new technologies and trends keep emerging and reshaping the business. It is critical for DevOps engineers to continuously learn about the latest tools, best practices and technology, and be able to adapt to change.

There are many ways for DevOps teams to refine their skills in order to become high performers. In this TechStrong TV interview, OpsCompass Co-Founder and CTO John Grange and Engineer Amy Wall join Mitch Ashley to discuss upskilling and how to build and maintain your software, development, cloud and technology skills in the fast-paced world of cloud. John provides a look into the future and where our skills need to move next, while Amy graciously shares her journey into software development and some valuable lessons learned along the way.

OpsCompass is a leader in Cloud Security Posture Management (CSPM) offering an enterprise SaaS product that provides security and compliance management in cloud platforms.

The video interview is immediately below, followed by the transcript of the conversation. Enjoy!

Transcript

Mitch Ashley: I have the pleasure of being joined by two really interesting folks. We’re gonna have a great conversation, I’m looking forward to this today—Amy Wall, who is an engineer with OpsCompass, and then John Grange, CTO with OpsCompass. Welcome to you both. Good to be chatting today.

Amy Wall: Thanks. It’s great to be here.

John Grange: Yeah, thanks for having us, Mitch.

Ashley: Absolutely. You bet. Let’s do this—how about if we have you both introduce yourselves. Maybe, John, if you go first, introduce yourself—tell us a little bit about OpsCompass and what the company does, too, and then hand it over to Amy and you can tell a little bit of your background.

Grange: Excellent. Again, I’m John Grange, I’m co-founder and CTO of OpsCompass. OpsCompass is a really powerful SaaS product that does security and compliance management in the cloud. And what that really means is, you know, we’re really helping DevOps teams, CloudOps teams get the visibility, have the intelligence and the control they need to run a successful cloud operation.

You know, my background really plays a lot into what OpsCompass does and kind of the cloud security space. I’m a career entrepreneur. I’ve co-founded a number of companies, from top five global Microsoft ASP.NET hosting provider to a health and wellness SaaS product. So, I have a lot of experience, and our team has a lot of experience in kind of the infrastructure security compliance space. The cloud, obviously, was a big game changer, because a lot of the things that we used to deliver through a variety of different software products or hosted solutions inside data centers, we can now build software to easily do it in the cloud.

Ashley: Mm-hmm.

Grange: So, that’s kinda how I got into the business through kind of that hosting and infrastructure space, and now here we have OpsCompass, which is leading the charge with helping customers with their security posture, their compliance—all these different aspects of running or having a well-run cloud.

Ashley: Sure is a fun and interesting space to be in and I think we’ll get into that, too. Amy, how about you? Just a little bit of introduction, and I think we’re gonna get into more of your story, too.

Wall: Sure, yeah. I’m Amy Wall, I’m a DevOps engineer at OpsCompass. I have the pleasure of working with John Grange, working under John Grange, and kind of forming this exciting new product, OpsCompass. And so, I’m kind of—where I’m at in my career and on my cloud journey is really in a space where I’ve kind of come to it from a software engineering perspective. I’ve been a software engineer for years now, and you know, been going through the steps and kind of getting the skills under my tool belt, upskilling on the cloud path so that I can become a full DevOps engineer for OpsCompass. So, really been learning with OpsCompass and growing with OpsCompass as they sort of kind of figure out and carve out their space in the cloud infrastructure.

Ashley: Mm-hmm. Isn’t that nice when you work with, you find a company that’s really compatible with what your goals are and what you wanna learn with where you are in your career? That’s awesome.

Wall: Huge. Absolutely.

Ashley: Well, that’s a little bit of what we’re gonna talk about, the upskilling is kind of a general, I guess, tag, label for it. We’re gonna explore a little bit, and you volunteered to share your story of how you got into software and how you’ve evolved into software in the cloud and DevOps, and then maybe take a look forward, you know? We’re here in December thinking about getting through the holidays and everything else going on and thinking about the new year. Maybe John can share with us some ideas on that, too, and we’ll explore some of those things about how do we prepare ourselves for the next things that are coming.

So, let’s start with your story. I’ll let you tell it however you’d like, but you know, maybe how did you get into software?

Wall: Sure, yeah. I always like to joke that if I told my 12-year-old or 14-year-old self that I was a software engineer or DevOps engineer, I would not believe it, at that age.

Ashley: [Laughter]

Wall: But yeah, I really didn’t have a super traditional path. You know, I was a Humanities major in college. I left college and I became a content editor and then later a project manager in the marketing space. And I really enjoyed it, but kind of along the way, I got exposure to various technologies, I got a little exposure to programming, I got some exposure to IT, and over a few years, I realized that I just loved it, and that’s what I really wanted to do. And my favorite days at work were the days where I was able to kinda solve, you know, software problems or technology problems, whatever.

So, I did, like, a total career 180 about five years ago and took a U-turn, learned how to code, and my first job after that was at OpsCompass or a subsidiary of OpsCompass that OpsCompass then later purchased. And so, I’ve been working in software ever since as a software engineer. And it wasn’t until OpsCompass a couple of years ago, I think two or three years ago, when I was able to join that amazing team of engineers where I started to really ramp up my cloud journey. You know, I had become pretty strong in the fundamentals of software engineering, and you know, I’d become really used to kind of the experience of learning on the job. You know, that’s kinda the nature of software engineering itself, and it’s the nature of DevOps, and it’s really the nature, I think, of cloud, because there’s new technologies coming out all the time and everybody’s kind of learning a way to navigate the space a little bit better all the time.

And so, yeah, I just kind of figured out how to learn on the job and continued learning on the job, and now I’m surrounded by world class cloud engineers and John Grange, our CTO, who have excellent mastery in this space, and it’s been a blast to kind of learn together with them and figure out how this entire ecosystem works.

Ashley: Wow, very complimentary of the company. Be careful, John, she may have an ask.

Wall: [Laughter]

Grange: Yeah, I know. This is—this is great. No, but in all seriousness, you know, just from our perspective, even, having somebody who’s a rock star at this point, like Amy, it’s hard to find cloud expertise. And you have to be able to find people that are interested in growing, willing to grow, have that interest—like, it sparks that fire, so that then you can enable that and you can grow a lot of your own expertise, and it’s a really powerful thing, but I think it’s something that a lot of companies, particularly like us, have to do today to stay around.

Ashley: Mm-hmm. You really do have to invest in people and give them the right, whatever ways that they learn, the right opportunities. You know, there’s also the person side of it, too. One of the best things I learned in college from a Computer Sci professor was, he said, “Everything you know now is gonna be obsolete in a year, so you need to keep learning. You have to have a thirst, just a hunt, a desire for learning just to keep—keep going.”

And it seems like that’s consistent with what your journey’s been, Amy. Maybe talk about what the evolution from some of the technologies you started developing software in to getting into cloud—what kind of things are you doing today?

Wall: Sure, yeah. So, I started where I think a lot of new coders start is, I started on Ruby on Rails, and I used it for years, and I actually still use it a lot of the time. But yeah, I started there, and then I worked in the consulting space for a few years where I was able to kind of bring to life a lot of customers’ ideas, clients’ ideas, and I loved that, that was really exciting.

And so, from there, I kind of have just begun dipping my toe a little bit in all the cloud has to offer. I still have a ton to learn. But our infrastructure has a number of different resources in various clouds. You know, I get to work with AWS, I get to work with Azure, I get to work with Google Cloud Platform. So, you know, any given day, I could be working on any one of those technologies. I could be spinning up Lambda, I could be debugging something in Typescript or JavaScript, whatever it is.

But yeah, it was definitely a journey along the process, but we have a team, like I was kinda mentioning before, we have a team that we all, I think, feel that we’re in it together a little bit. And so, there’s a great energy where I think we kind of all learn together, even the master practitioners will continue to kind of get new certifications as they come out, will continue to offer advice, and will continue to learn.

And so, I’ve never really felt like I was the baby in the room, so to speak, [Laughter] or that I was less skilled than anybody else, per se. I kinda just felt like—okay, we’re all making ourselves better, sharpening our skills, getting better all the time, so.

Ashley: Especially, it can be an advantage in a technology area that’s relatively new, because everybody’s learning it, right? Nobody’s been doing it for 20 years or whatever makes you an expert.

I’m curious, too, did you find mentoring, kind of learning from peers, things like that were helpful, since everybody’s learning at such an accelerated pace moving into the cloud, whether it’s on the UI side or on the software infrastructure side?

Wall: Hugely, absolutely, yeah. Our lead architect, Nick Allmaker, is an excellent mentor for us. You know, his knowledge never ceases to amaze me, and he’s really, really helpful. He’ll always—he’s always willing to take some time out of his day to spend a couple extra minutes on a pull request or help you figure something out.

But, you know, even earlier on in my software engineering education, I remember having a teacher who told me, “Always T.S., try it and see.” [Laughter] And I think I mentioned this in a blog recently, but that’s been hugely helpful to me as I’ve moved into this space, because you know, for me at least, in learning cloud and in understanding the ecosystem, tutorials online can really only take you so far. Sometimes, you just have to, you know, go in there and spin up a Lambda, you know, spin up an EC2, and figure out what’s going on, play with it, move it around a little bit.

And so, I definitely—that’s a big insight that I’ve learned is that just get in there, try it. A lot of the clouds, I think all of them, in fact, have a free trial where they give you a little bit of free canister to play with at the beginning. I used that for all of them, absolutely, and you just, you know, spin up resources.

And I think in addition to that, having a third party like OpsCompass where you have kind of that visibility into every single resource that you have going on in every single cloud can be super helpful to someone. Obviously, helpful for experts and helpful for people who are in the cloud security posture management space, but also helpful for people like me who are learning and who don’t really understand or who are kind of putting the pieces together of what changes do what and what resources are like others, how similar is an Azure function to an AWS Lambda, and having that kind of visibility into all of your clouds and all of your resources can be hugely helpful.

So, you know, I kind of had that advantage at OpsCompass where, you know, I’ve definitely had a leg up, for sure, in being able to kinda learn this stuff.

Ashley: Mm-hmm. Opportunity is everything. Sometimes it’s self-created, and sometimes it’s the situational company, et cetera. I’m curious, John, what’s your perspective on, because you’ve, you know, you’re obviously probably in a little different place in your career, but as yourself and folks you’ve worked with, what are some of the mentoring and kinda helping others advance in their careers have you seen to be really successful—either for yourself or people you’ve worked with.

Grange: Sure. Well, you know, there’s a couple things that come to mind, and one of them Amy just mentioned, being able to go and mess with something, being able to go out into the cloud and play with the resource and have kind of both the curiosity, the time, the capability to be able to go do that is a really powerful thing. And in the cloud, when all of these services are changing and being—you know, there’s a couple hundred different ones on AWS—there’s literally something new every day.

Ashley: Mm-hmm.

Grange: So, I think that that’s a big part of it. The other thing that I learned early on from mentors of mine that I also try and share with the team is that when there’s these big trends—you know, cloud is an example, but then also, you know, some of what you see with big data and AI, et cetera, there’s the sort of application top layer trend that’s all of the robust sort of user applications for those technologies.

But for those to actually come to fruition and for that trend to really be powerful, there’s gotta be all this plumbing underneath that isn’t as—it’s not as glamorous and not everybody thinks about it, but as those spaces burgeon, it’s not just the mobile app that’s using AI to really change kind of directions in navigation, it’s the whole industry of sort of the infrastructure beneath that needs to serve those sorts of trends and applications. And those end up being great places to go and learn about. And there’s tons and tons of opportunities, sort of, in the wake of those big trends and the leading kind of applications and companies.

So, I always like to, even in our product, you see a little bit of that, but I even try and tell, you know, folks on our team that we need to be looking at things that way, as these trends are big. What kind of plumbing do the customers need? What are the dots that need to be connected? What’s the kinda unglamorous thing underneath that everybody’s gonna need that we can learn a lot about and solve the problems around?

Ashley: I’m curious, Amy, have you seen that? Has that been consistent with your experience, too?

Wall: Absolutely, yeah. I think—yeah, per what John was saying, I do really think that there is kind of an ecosystem to cloud and we’re trying to always stay on top of it, in front of it, you know, figure out what’s going on with it and view it from kind of like that 30,000 foot view, so we can really understand it as a whole picture.

So, yeah, I think there’s a great knowledge share, for sure, and I think that’s hugely important to figure out where is this going, what is going to be happening in 5 years, in 10 years? Where do we need to start working now so that we’ll still be relevant, we’ll still be making sense at that time? And it’s not always easy to guess, but definitely, there’s a lot out there in the industry that you can kind of get a feel for that.

Ashley: I think we’re in violent agreement. [Laughter] The best developers I’ve worked with really knew it from the operating system, the whole software stack, the network—you know, not an expert in every piece of it, but knew how it all fit together and how to make it all work and kinda hum and get to the performance that you need or make the right decisions on how you want to, the architecture you want to use and what parts you do and don’t want to use.

You know, another thought—you may have mentioned this in your article, too, Amy, and I’ll put a link to the article in the description—open source is another fantastic resource. You talked about getting free time on cloud services and using sampling software—it’s a great place to watch how software’s built, in a little bit different way, in an open way, open community, but using that as well can be super fantastic. And by the way, everybody’s using open source in their products and their IT systems, their applications. And so, the more you know about it, the more you can leverage it, right?

Wall: Absolutely, yeah. I love—I just, I love the idea of open source. You know, I think it’s—I love the ideology of it. I think it’s fantastic, and certainly, we do use it. And I think open source is the place where a lot of people kind of go to exchange ideas in the cloud space right now. You know, we have a lot of—Twitter, for example, Tech Cloud Twitter is always really exciting and people…yeah, I think people are making some really interesting things right now with open source, and it’s an exciting place to be.

Ashley: So, let’s kinda turn the lens from, you were talking a little bit about your background, John sharing a little bit of his as well—turn the lens to kinda thinking forward, right? Things have changed. It’s a different world in the last nine months, for sure, and a lot of organizations have accelerated digital transformation projects. We’ve got data in my analyst firm to back this up very strongly.

The move to the cloud is accelerated, and you know, not stopping. It’s gonna continue to move even quicker. And I know you think about a lot where you’re going as a CTO with your company and your product and your technology, John. What thoughts do you have as you think over the next 6, 12, 24 months kinda into the where we’re going and how that might influence what people might learn or maybe how they learn?

Grange: Mm-hmm. I actually—that’s a great question, and I’d actually go back to the comment I made before about some of the different trends. And, you know, just like we’ve had the DevOps trend over the last handful of years, there’s a whole number of kind of portmanteaus, right, the CloudOps and DataOps and AIOps.

And I think that as some of these, you know, Fortune 1000, Fortune 2000s start to become more cloud mature, you’re gonna start to see more of the need for, okay, not just general DevOps where you really understand the cloud platform and orchestrating and automating workloads and things of that nature, but you understand the details of AIOps, for instance, which is a much different challenge, it has lots of other issues with data issues and labeling and things of that nature. Similar issues with sort of DataOps engineering—lots of new problems, really important business solutions to be built there for organizations that are already pivoting their organizations to prioritize these things, particularly after the pandemic.

DevOps is all about efficiency, and now what companies are saying is, “Hey, you know, coming out of the pandemic, we’re gonna prioritize our most innovative projects higher and we’ve got to push to be more efficient. We can’t have the cloud spending overages, we can’t have these big breaches that are costly reputationally and financially. We’ve gotta get more efficient.

So, I think that those are the big things that, coming out of the pandemic, I’d be thinking about. If I were kind of a DevOps practitioner out in the field but also what I’m thinking about at OpsCompass is we’re, you know, looking out, we’re looking into how can we provide more value to our users for some of these really specific use cases that are driving very significant value for companies that are implementing them.

Ashley: Mm-hmm. I’m curious, too, then, without getting into customer details, but as you’ve worked with your customers through the pandemic, through economic challenges, recovery, that kind of thing—what changes are you seeing in the market with the customers that you’re working with? Are they emphasizing different things, stepping back and taking new directions or trying to get better at just the core things? What’s happening?

Grange: Yeah. You know what? It’s interesting. From my perspective, it’s very much almost no new phenomenon. It’s almost all just an acceleration of things that we were already seeing.

Ashley: Mm-hmm.

Grange: So, in other words, a lot of our kinda strategic plans that we thought were maybe a year out all of a sudden became, you know, “We need them, like, yesterday.” So, I think that a lot of those trends around remote work were already in place. I think a lot of—you know, many of the projects that we’re seeing companies, you know, prioritize, put a higher priority on, those projects already existed. Now, they’ve just become more important.

Unfortunately, a lot of these IT teams and cloud teams shrunk during the pandemic. So, they now have the requirement that they’re more efficient and everything else, but they have, in many situations, fewer resources to work with.

Ashley: Mm-hmm. Well, though that’s hard, it’s almost always that growth comes through investing again, so at some point, that starts to rebuild on that efficiency.

Grange: It’s the story of IT, right? The story of IT—being understaffed and overly important.

Ashley: Yeah, I don’t think I’ve met an IT team that said, “You know, we just have too many people. I’m not sure what we do with all these folks.” [Laughter]

Grange: Yeah.

Ashley: You know, it’s interesting—I agree with you about, it’s very much accelerating. Another trend I would share—let me see if you concur with this—is, you know, you have the fortunate, if you wanna think of it that way, situation of being in a company where your software is your product, right? So, you can connect the dots between work that Amy’s doing or someone’s doing a test or someone’s doing customer service or architecture or what you’re doing in your role, John. You can connect that to the business and why you want to invest in AI and machine learning or whatever the next thing is.

That can be really hard to do when you’re in a bank or an insurance company or something else where there’s a lot of distance between what I’m doing in my job—especially in a Fortune 1000 company or above. With that acceleration, though, and I think because of DevOps and AsteriskOps being adopted across different functions, a lot of that is about driving that connect the dots to why we’re going and where we’re going there, and how to accelerate, right? So, the efficiency can be for financial purposes, but recovery can also require agility, very fast response. You know, markets change, our supply chain is gone. We gotta rebuild that in a totally different way—so, guess what? Software is critical. It’s not just a back office thing. Thoughts?

Grange: Hey, I think that’s exactly right. And, you know, using the financials as an example, you know, many of these financial companies were spending an extraordinary amount of money on reducing their risk, their technology risk, their physical security data centers, really expensive software to secure it all. And you’re exactly right, one of the accelerating trends is that efficiency. That’s not efficient at all. Capital One now has moved—they’ve shut down, now, all of their data centers around the world. They’re completely in the cloud.

Ashley: Mm-hmm.

Grange: That’s kind of an outlier example now, they’re like, the only one. But they’re all—I can tell you, just on experience with our own customer base, the mid-market is moving very quickly that way, too. Because they just realized that—hey, we don’t have to, we now don’t have to build data centers, we don’t have to have these huge capital budgets. We can be more efficient, we can be more operational. We can—to your point, the agility that’s required with how quickly this technology’s changing, you almost don’t have a hope unless you’re in the cloud. You know, you can stand up your own container stack in your data center and set up a rack and buy hardware and do all that, or you can go turn on, you know, Amazon’s Elastic Container Service and go with it. I mean, it’s just, it’s a whole different ballgame. And, yeah, I think that that’s a good example, Mitch.

Ashley: Excellent. I’m curious, Amy, your perspective on it, too. Will you—in your role when, kinda, you think about your career and where you’re moving as well as the company, how is the current situation influencing how you’re thinking about what you do next, what you learn, and how you can maybe help others accelerate their learning?

Wall: Hmm. Yeah, I agree with both of you, that I think the pandemic has had a real—there’s a renewed sense of urgency because of it. And so, I think a lot of us have had a moment to kind of take a step back and think a little bit from a broader perspective about what our company is, what our company is doing, what we are doing, where our careers are going—all those kinds of things.

And yeah, I think people are having an opportunity to figure out—like John was kind of saying, John mentioned the infrastructure for working remotely was largely in place before the pandemic, but that wasn’t always true, and that wasn’t true for every company. And so, I think there’s a lot of catching up that’s happening right now, and yeah, there’s definitely this added urgency behind all of it because of the state that the world is in right now.

Ashley: Yeah, it’s interesting. I was running IT for a while at a prior job, and we were at this beginning of—stopped thinking about it as we were working remotely or working remote and think of it as work anywhere.

And it seems like that’s totally apropos now, that’s—you know, if you think about forward, it’s not like we’re all gonna show up back in the office after we vet the vaccine or whatever, even if things are in good shape, you know, public health wise, there’s a lot of things that, you know, we’ve been doing this for a year, two years or whatever the time’s gonna be. People are gonna build on it and leverage that, at least I think. I don’t know if you all agree, but I think this is the work anywhere that we’re in now.

Grange: Well, CFOs got a little taste of really, really small travel and entertainment budgets, and I think that, as those start to come up, I don’t think that the tolerance levels will be quite where they were before the pandemic.

Ashley: Yeah, we’ve proven, right, what we can do.

Grange: Yeah.

Ashley: Also interesting, you know, folks have talked about, we’ve made decisions a lot faster, too, in some cases. You know, we were debating—do we use Team or Slack or whatever, you know, for a year and suddenly in a week, two days, we decided it. Like, why can’t we do that all the time? Well, maybe not always you do that, but we’ve shown we can accelerate a lot of things.

Grange: Well, I think that another thing that happened is, I think that American companies in particular, I can’t comment as much internationally, but American companies, I think, got very good in this, in the 21st Century at buying software—maybe even before that.

But I don’t think that companies are very good at actually adopting and using software, and I think one of the things that the pandemic did is, like, everybody bought teams and bought all this stuff from these, you know, the big tech companies, and nobody really fully adopted it, fully implemented it. It was always just kind of another thing on the shelf, and I think that that’s another thing that’s happening right now.

Ashley: Mm-hmm. Getting greater adoption.

Grange: Lots of the collaboration technology, lots of the things that we all kinda use are now becoming highly mission critical business processes that we care about. So, we’re, like, fully adopting them.

Ashley: Just the essential tools in the toolkit versus, “Yeah, I’ll use it if I have to talk to that team” or something, [Laughter] that group. As you’re thinking about the technology stack, Amy, you know, John was talking about adopting software. I remember a time in my career where folks felt like they had to write all of it, right? I mean, yeah, they used a database system, or—you like to build software, so build as much of it as you can.

Today—yeah, you write software, but you want to, is there a better container management system than Kubernetes? Well, let me go check it out. You know, I don’t necessarily want to write my own. Maybe I do wanna do it as an open source, but you’re really a software integrator, software builder as part of the whole process, not just a software developer. Is that how you view things?

Wall: Absolutely, yeah. Yeah, I’m a big proponent—totally, yeah. I always say, “If you can avoid it, don’t reinvent the wheel.” And everyone says that, but not everyone always takes that to heart.

Ashley: Mm-hmm.

Wall: And I think a lot of the times, especially when you’re in a software team, you’re in a development team and you’ve kind of got your head down and you’re really working hard on code, I think it’s really easy to kind of lose sight of the broader picture.

And, you know, just last week for example, we had this problem we were trying to solve where some customers weren’t—you know, there was a miscommunication between our software and some customers. And, you know, I kind of just was able to take a step back and—

Wall: – you know, customers weren’t, you know, there was miscommunication between our software and some customers, and you know, I kind of just was able to take a step back and say, “You know, if we just think about this and maybe document it, write about it, you know, find some documentation online, you know, find a good article, perhaps, that we could recommend, I think we could solve this problem without writing any code at all.” And we did. And I think those kinds of solutions are happening a lot, for sure.

I mean, and you mentioned open source earlier as well, and I think that plays into it to a huge degree as well.

Grange: That’s what I was about to say Amy, is that that goes right back to what you were saying, Mitch, with the open source. And I think that’s why open source sort of is kind of supreme right now. Go find a library, go find a package that already does this, go find a service that we can just integrate APIs with, you know—let’s not reinvent the wheel.

Ashley: I remember being on some panels of, you know, “Should you use open source?” and my answer was, “I can guarantee you your competitors are.” Talk about a source of innovation that you can get for little or no cost—I mean, yeah, there’s a cost with it, but you better leverage it, you know, [Laughter] in the right way for your company as well.

Let’s talk a little bit about OpsCompass. I’d love to hear, maybe, some of the future directions you’re heading. You’re not announcing anything here today, but what are the kind of things you’re thinking about since we’ve talked about this evolution of where the cloud and technology and skills need to go? What’s happening at OpsCompass as you evolve and change and play a leadership role in the industry?

Grange: Sure. Well, for us, the way we like to think about the product and the product strategy is, what’s going on in the cloud space, what are customers doing, and then how can we provide kind of visibility and intelligence across those different dimensions?

So, I talked a little bit about kind of some different AI products and services that we were starting to see companies use more containers. We obviously—that’s kind of a number one use case for our customers today. So, we’re fairly strong there, but we’re gonna get much, much stronger.

But another big part of it for us is the DevOps pipeline. We provide visibility into what the pipelines are doing today, but it’s becoming so much more critical to the full cloud processing companies. They’re becoming more DevOps mature that we are going to, you know, kind of completely blow out that kind of set of functionality in our product over the next year. So, we’re excited about that. And you know, our customers are really looking—you know, you can parse through a lot of the technical explanations for problems, but what they’re really trying to do is get control, and the definition of control is a little bit different than it was in the data center. And there’s some more subtleties and things to it, it’s got a little bit more texture, I like to say.

And so, it requires a different approach and when we can combine, you know, the deep visibility into what they have with the intelligence and context around, you know, what’s happening and the state of things, that’s kinda how you end up getting control. And there’s processes and people involved and everything else, but kind of everything we do—and we kind of, you know, eat, breathe, and sleep that kind of mantra, and we’re constantly poking and prodding at the clouds, working with the clouds. We work with all three at the corporate partnership level. So, we’re just really—we’re having a lot of fun, and it’s sort of the key problem of the age right now is just the different teams, all these different people, different resources, different services. It’s just sort of the impact of this sort of scale and kinda chaos a little bit. So, there’s just so many great problems to solve around making sense of it all.

Ashley: Mm-hmm. Excellent. Amy, anything from your perspective you would like to add or talk about?

Wall: Yeah, I think John is just spot on. And I also think, from an internal company perspective, you know, what’s happening within OpsCompass is being mirrored by companies across the globe right now, which is that we are really kind of getting a feel for how to operate as a totally distributed team, like you were mentioning earlier. We have employees now all across the United States and internationally. We also work with customers and _____ abroad.

So, we have this—I think we’re kind of learning along with our customers how to kind of interact with a more global ecosystem than we had before and how to kind of bring all of these, all of the water cooler conversations or all of the idea sessions or brainstorming sessions and whatever onto Slack, onto Teams online so that we can all engage.

So, that’s definitely a change that I’m seeing internally and that I’m not, I don’t see going away when the pandemic is over, and I see it becoming something that goes on to the future.

Ashley: Yeah, that’s very wise. I think it’s very sticky kinds of behavior changes and work patterns that will be with us for a long time to come.

Well, I’ve really enjoyed, this has been a fun conversation talking with you both and it’s just—it’s so much fun to share real experiences that we’re having in our jobs and our careers and also doing it in a way that hopefully this conversation can benefit some other folks, you know, along the way who may have similar or maybe different experiences that they might pick up from what we’ve talked about.

So, before we wrap up, to check out things at OpsCompass, John—OpsCompass.com, is that correct?

Grange: Yep, you can go to OpsCompass.com, check out more about us. We have a free trial, really encourage people to go jump in, check out the product. Again, it’s built by a bunch of DevOps engineer cloud nerds for our sort of brethren, if you will. So, love getting feedback and let us know if there’s any, if there’s anything that we can help you with.

Ashley: Built by DevOps people, for DevOps people, right? [Laughter]

Wall: Exactly.

Ashley: Exactly. Well, Amy Wall, it’s been fantastic talking with you. Thanks for sharing your story and your insights.

Wall: My pleasure.

Ashley: And John Grange—similarly, your insights as well as kinda where we’re headed and a fun conversation with you. Both the best, have a great holiday, and we’ll see you into the new year.

Wall: Thanks a lot, Mitch.

Grange: Thank you, Mitch. Be safe.

Ashley: You, too.

January 25, 2021
Data Security in the Cloud with Imperva

Database security startup jSonar, founded by Ron Bennatan, was recently acquired by Imperva, a leading cybersecurity company focused on data and application protection.

In this episode of TechStrong TV, Ron Bennatan, general manager of data security at Imperva, joins us to discuss the plethora of data security challenges across cloud environments. They also talk about the significant increase in data usage and creation as a result of COVID-19.

The video is immediately below, followed by the transcript of the conversation. Enjoy!

Transcript

Mitch Ashley: I have the pleasure of being joined today by Ron Bennatan, who is GM of Imperva Data Security. Welcome, Ron.

Ron Bennatan: Thanks. Glad to be here.

Ashley: Good to be talking with you. I’m excited to chat a little bit about data security. Let’s start out with, just introduce yourself, a little bit of your background. I know you had a recent event with your company, Imperva, and tell us a little bit about what Imperva does.

Bennatan: Okay, yeah. I’ll just start with what Imperva does. So, we’re a cyber security leader, we have over 6,000 global customers and we’re just focused on helping them protect data and all paths to it. And kind of what that means is, we have both application security products and data security products, both of them leading in those spaces.

But kind of the, our view is that, in order to do a good job around data security, you really have to look at this as a whole thing, otherwise it becomes, like, a blanket thing, right? You pull it to one direction and you expose yourself on the other side. Because data is—yeah, it’s very complex. And securing all data and all ways that people access data is a difficult thing.

So, like, for example, I could be—I could be really good at securing access to data from privileged insiders, but then you also get access through the applications. And the way that the data tier looks at things, it doesn’t see enough when it’s accessed through the application, so that’s a problem. And then if you do a good job on the application side, you know, maybe on bots and APIs, but maybe you also have insiders, and maybe insiders are different when they access it directly or they’re admins of the data tier or they’re admins of the application tier.

So, really, our view is, in order to do a good job, you really need to look at the whole access and all the paths to it.

Ashley: Excellent.

Bennatan: How did I get here? So, I’m a 30-year data-slash-security guy, so I’ve been both, kind of working on the data side, whether it’s a DBA or application side, but also on the security side.

So, I started my career in the military. I then worked on Wall Street for a while, areas around Sybase and Sybase security, Oracle and Oracle security. Then I was one of the founders of Guardium back in the early 2000s, built this database security business, got acquired by IBM, was the CTO of data security at IBM for a while. Last, founded jSonar, also in the data security space, and then a month ago got acquired by Imperva, so I now lead the data security setup there.

Ashley: You just keep getting acquired. I need to hang out with you a little bit more.

Bennatan: [Laughter]

Ashley: [Laughter] Going back to Sybase—wow. Yeah, I was a Sybase customer. [Cross talk]

Bennatan: [Laughter] You know, it’s still being used all over the place.

Ashley: Isn’t it amazing? Technology never goes away.

Bennatan: It never goes away.

Ashley: We just don’t talk about it as much as we used to. [Laughter] Well, you know, data security is such a fascinating topic. And I don’t mean this in a pejorative way, but it’s a bit like whack-a-mole, right? It’s everywhere and as soon as you think you’ve kinda gotten control over it, it pops up over here, sorta like that balloon that squeezes between your fingers, [Laughter] you think you’ve got your hands around it. And plus, it’s not a static thing, it’s growing and it’s evolving, it’s being used by different applications in different ways.

It’s a huge challenge. I mean, how do you even begin to tackle that from a data security company?

Bennatan: Yeah, so, I mean, first of all, you’re absolutely right. And, you know, we’re all security professionals, so to us, it looks like a bad thing, but before we go down that route, it’s actually a good thing, right?

I mean, the fact that it is so complex, it is because it’s just hyper efficient, right? The people who are building data architectures are amazing. They’re doing an amazing job. Because if you look at data architectures 20 years ago or even 10 years ago compared to what they are today, it’s just—it’s like, it’s like an immature baby compared to what’s happening now.

Ashley: Mm-hmm.

Bennatan: And it’s a good thing, because these are highly optimized systems, very diverse types of workloads, very diverse technologies, right? A database today is not even close to what it was 20 years ago. A data lake today is an amazing thing, okay? You know, it’s hard to even put your finger on exactly what it is, a data lake, when you look at, say, an AWS data lake or an Azure data lake or a GCP data lake. They’re amazing.

So, these are good things, right? Our applications are getting better, they’re getting faster. We can do, like, crazy things with machine learning algorithms doing analysis, telling us how to improve our lives, okay?

Now, as security people, we’re always playing catch up, okay? We’re always—these people are creating these things, and security is never exactly baked into that stack, although it is getting a little better or we’re trying to get it a little better. So, we are playing catch up, and it does create a lot of challenges on what it means to secure it well.

So, you know, the fundamentals have never really changed, right? There’s authentication, there’s authorization, there’s audit, there’s the notion of finding where the data is, classifying the—that stuff doesn’t change. What does change is the complexity of doing each one of those tasks.

So, if you look at—you know, even the first thing you kind of need to start looking at is, you know, find all your sensitive data and make a catalogue of it and know the lineage and—you know, 40 years, we’re doing the same thing. And it just gets harder and harder, because you look at one of these data lakes, you know, I think 10 years ago, when we were building a data lake or thinking of a data lake, we would think of, “Okay, we’re probably doing some kind of a Hadoop project,” okay?

Ashley: Mm-hmm.

Bennatan: Which, in itself, was complex enough as it is, because you’ve got, like, eight or nine different services running, each one doing something a little different.

Ashley: It wasn’t that long ago. I mean—

Bennatan: It wasn’t that long ago, but it’s dead, right? It’s [Laughter]—that part’s dead. Now, we’re building something which is infinitely more complicated. Because—like, I’ll give you an example. A lot of my customers are building things on AWS.

So, you’ve got this—it’s not like the data lives in one place, okay? You’ve got S3 buckets, and then you’ve got access sometimes from Athena, sometimes through Spectrum, sometimes from both. And then you have some DynamoDB or DocumentDB databases for doing transient things, and then you shove it into Redshift so your Tableau can access it. And then you have AWS Glue moving things around, and maybe you even have a Hadoop stack inside EMR for the landing area.

Ashley: You have data in databases inside containerized—

Bennatan: Yeah, everywhere. And then you say, “Well, how do I secure one of these beasts?” And so, yeah, it’s complicated, it’s risky, and we just need to keep up with these guys who are doing a good job with making very innovative architectures. And, you know, it would be great, by the way, if we could’ve baked this into the stack before they even started, okay?

Ashley: Mm-hmm.

Bennatan: But, like, I’m too old to believe in fairytales.

Ashley: You stopped chasing that rainbow, right? [Laughter]

Bennatan: Yeah. And we just do need to keep up with them. We need to keep up with them, we need—you know, because a lot of my customers are larger, and if they’re larger, then sometimes they’re regulated, somehow, or they need to adhere to something.

Ashley: Mm-hmm.

Bennatan: And certainly, these days, they’re all also troubled by all kinds of privacy compliance issues. So, we need to give them controls that they’re used to getting, you know, on the stuff that they’ve been building for the last 30 years on prem. And it gets to a point that the application team wants—you know, they’re ready. They finished everything, they’re migrating it up, and even simple things, not even complex things like cloud. They have an application using SQL on prem and they want to move it to SQL on Azure—simple enough, right?

Not really, because on prem, they know what their tooling looks like, they know what their controls are, they know what they’re doing with privileged access, they know how to scan, they know how to create the policy for defining access. They know how to manage—they know how to do change management around that policy. Now, they all move it to the cloud. Sometimes, those controls are there; more often, they’re not there.

And, you know, so, for example, one of the things that we view as being fundamentally important for us is to make that transition seamless, okay? Same controls. Different methods, different tools, different policy orchestration, but to them, it should look the same. If it looks the same, then when the app team wants to move it over, security stops being this bad guy that says, “Nope, stop. Okay, tell me what you did, here.”

I mean, we can’t be the bad guys, okay? We have to—

Ashley: Can’t be the cops, can’t be the roadblock.

Bennatan: Yeah, yeah. We need to help. We can’t keep stopping things. It’s just a bad, bad—bad dynamic.

Ashley: So, let me ask you. There’s so many dimensions to this and usages of data. So, is that one, instead of, like, getting ahead of all of it and designing it up front, which we wish we always could and doesn’t happen—is that the right approach?

I’m thinking about how do we do security right—is that creating the, whether it’s the tooling or the framework or the structure of how we secure data, making that consistent so, no matter the environment, we now know how to do it, and we can do it in a reasonably consistent way and know that it’s been done as opposed to, you know, n+1 for every environment that we’re in, it’s all different and it’s all complex and nobody can keep track of any of it, more or less secure it. Is that sort of getting our hands around this problem?

Bennatan: Yes, that is absolutely the one sentence summary is exactly that.

Ashley: A lump sentence, but [Laughter]—

Bennatan: A lump sentence. [Laughter] Yeah, yeah, because we need to—we need to abstract things out and hide the complexity, right?

Ashley: Mm-hmm.

Bennatan: We need—the fact that the data environment is so complex, it doesn’t change that if you go high enough, the problem statement or the what you need to do statement is the same, okay? The problem is that when you translate it to, “Okay, what actually happens?” then it tends to be different here, different here, different here.

But at a high enough level, it’s exactly the same thing. So, you know, what—if the environments are getting more sophisticated and the architectures are getting more complex in a good way, if securing them also gets more complex, then we’ve lost. So, what we need to do is make it maintain a single abstraction layer, and then do the magic that translates it into the individual changes.

So, it’s absolutely what we need to do. Now, some of this is a heterogeneous question. Okay, some of it is a heterogeneous thing where, you know, you have different silos and you know, historically, people have always looked at data as a bunch of silos.

Ashley: Mm-hmm.

Bennatan: Okay, there’s like the database silos, the big data silos, the file silo. That stuff gets blurred (a) because in the cloud, it’s very blurry, okay? Like, you can definitely say that S3 is a file system, okay? It’s an object store, it’s kind of like a file system, but then you slap a FINA on top of it, and that gives you SQL queries on top of that file store. So, is it now a file system, or is it a SQL database? What is that thing? It’s—

Ashley: And DynamoDB and now you’ve got a whole bunch of different ways of accessing and using that data.

Bennatan: Yes. So, that’s one piece of it. The other piece of it, which is almost the same sentence that you said, but semantically, it has a different meaning, okay? If you look at kind of the concept of data governance, okay, from—in the last 20 years, it’s always been, like, at the top, there’s things like policy and things like, you know, what are the business requirements? And at the bottom, there’s the tooling. And always, whenever you talk to anybody in this space, they always say, “Don’t start here, don’t start at the bottom by just implementing tooling, start here and then do this.” Well, I’ve yet to meet a single company that has started here. You always start here.

Ashley: When do you get the luxury, right?

Bennatan: Yeah! Look, part of it is just us people, okay? We’re—us people are problematic, okay? [Laughter] People can understand very concrete things very well, and therefore, we can go do a project that does this and we can do a project that does—and the vendor landscape has never helped, because products are like this and like this, so… And you go to the analysts, and the analysts say, “Oh, you need to pick one of these and one of these and one of these.”

So, you know, for many years, it’s been one of these, “Okay, nobody started here, everybody started here.” And then projects have operationalization problems. It’s not that, you know, tools have problems, it’s the fact that, even if a tool does everything it was supposed to be doing, it gets hard to operationalize things. And then you start looking at it and you say, “Okay, within these silos, there’s actually no difference to operationalize things.” It’s the same thing, okay? You need the same processes, you need the same decisions, you need the same policy push down.

So, why are we doing it six times? Why are we not doing it one time? Well, we’re not doing it one time because we didn’t start here. And so, over time, you know, I kind of gave up on people starting here and assumed people would always start here. The question is, that abstraction—can you now take work that you’ve done within any one of those silos and leverage that in order to create that kind of in the middle, like a single control layer, okay?

Ashley: Mm-hmm.

Bennatan: I mean, a single control layer that then uses those tools, but creates something that is, you know, consistent. And if you start creating something that is consistent, then you’re not, you know, you’re not balled into these silos. And then when you’re—when you get some of these more kind of advanced architectures, you know, you’re not screwed, because you didn’t create something just for this silo and this silo and this silo.

Ashley: And then you know that all the bases are covered, too, you’re not having to do a unique process or solution for all the checkmarks you’ve got to put in place, and who knows if those work reliably in every environment, whatever way you figured out to secure the data or do access control or manage data integrity, whatever that is.

Bennatan: Yeah.

Ashley: Let me ask you. I think, maybe other than you getting acquired by Imperva, most of us want to put a checkbox on 2020, kinda wrap it up and, you know, in cellophane, put it into a bucket of cement and drop it in the river, you know? [Laughter] Kinda, let’s get past this year and move on to 2021.

So, as you think forward in getting security right, we’re in this COVID era, right? And, you know, that light switch isn’t gonna turn off any day soon. We’re gonna be some evolution of this for, you know, whether there’s vaccines or not, right? But that has rapidly, I mean, seriously accelerated digital transformation projects, and changed some things fundamentally about assumptions we make. We’ve kinda, we can go to shed some of that evolution and we’re there, in many cases.

How has that affected your thinking around data security in this era? Because we’re in it, we’re not heading towards being transformed, we’re living it right now.

Bennatan: Yeah. You know, I think this is actually one of the few positive side effects of COVID, you know? I can’t tell you how sick I am of being here. I need to go somewhere. I really need to go somewhere, I’m like, sick, but—

Ashley: I know. What day is it, anyway? I can’t figure it out.

Bennatan: Yeah. I just, I just can’t even tell you. [Laughter] But the acceleration that this has given to cloud projects is one of the side effects that I think is very positive. Because, for years, you know, I’m a technology guy, and you know, if it were up to me, everything would be on cloud, bar none. Nothing, nothing—there would be scorched earth everything else. And, you know, I keep hearing people saying, “Yeah, but you know, it’s more expensive.” You know, it’s more expensive only if you look at it at the actual numbers of the cost you pay the cloud providers. But if you look at how much more effective it is and how much easier, it’s like buying super-duper IT, okay?

Ashley: Mm-hmm.

Bennatan: That’s really what it’s about. It’s not about anything else, it’s about finding people who know exactly what they’re doing and that you never get to a point that you always have when you build your own stuff where you’ve got people finger pointing, you know? “No, it’s a storage problem,” “No, it’s a host problem”—it just works, okay?

So, I think it’s great. I think it does create a lot of challenges or security, just because it’s very new, okay? It’s very new and it’s very, very fast. And new doesn’t mean it’s, like, six months old. But even if it’s six years old, it’s all new. It’s like, somebody built everything that anybody built around data centers from scratch, really, okay? Or it looks different or it’s called different.

And then the problem—again, going back to people, the problem is always people. So—so, a lot of companies, what they’ve done in order to accelerate this very, very quickly is, they’ve built a separate security architecture for the cloud group to parallel the cloud architecture group, which is different from the old guys, okay?

So, now you get people who understand data security pretty well, because they’ve done it for many, many years. You have people who understand data very well. And then you have people who understand cloud very well, but they’re not the same people, okay?

Ashley: Mm-hmm.

Bennatan: So, now, you get a skills issue and almost like a language issue, okay? It’s like Babel again in some respects. It’s like, how do you call this? What is this? Is it the same? You know, what’s a VPC, how many different ways do you have to connect things into a VPC? What does that impact my data architecture, and what are the flows?

And so, I do look at 2021 as a great, great year, because, you know, if people have been going at a certain pace into the cloud, it’s all accelerated. It’s—

Ashley: You know, I think that is a really important point, because when you’ve been disrupted—and we’ve all been disrupted in our personal lives, but when you accelerate something that fast, you know, the saying, “necessity is the mother of invention”? Well, necessity with urgency is, like, the mother of invention right now.

Bennatan: Yeah.

Ashley: And it’s almost like you can’t do things the way you’ve been doing, you can’t go along in parallel paths, because suddenly we’re all now here. We’re all in the cloud together or in a place that’s much different than we were.

Do you think that that is enough of an accelerant to get sort of those silos of people across cloud security and on prem security and those start to work together of thinking how we manage? Because so much more of it now has moved to the cloud—or is that a good assumption? I mean, tell me what your thoughts are.

Bennatan: Eh, you know, it’s—because it’s people—

Ashley: [Laughter]

Bennatan: – [Laughter] I, I don’t know how to answer that, you know? We’re getting into the realms of psychology more than anything. But I can tell you that, you know, it’s gotta happen, and we’re gonna make mistakes, right? As an industry, we’re gonna do this, it’s good that we’re doing it. And we’re gonna make more mistakes, because it’s less known, because we don’t always have the right skills.

Ashley: Mm-hmm.

Bennatan: And I think it’s our job, you know, our job in the industry is to try to reduce those mistakes. Because mistakes lead to things that we don’t want to happen, and we do have the ability to avoid mistakes, okay? We just need to be very clear—we can’t be, like, super techies about it, okay? We have to do things that are practical. Because what you asked is about human behavior. So, really, it’s not enough we create technology, we need to create technology that is accessible to people and that people can consume very easily.

It’s one of the things that, kind of, in security, I think we never—I think we’re doing a much better job now, and my entire focus is really on this, on making things practical and usable very often more important than a certain feature function, okay?

Ashley: Mm-hmm, mm-hmm. I totally agree with that, yeah. Well, you know, what I was thinking about is that, when you have that disruption, think about choosing productivity tools. How many organizations were debating, “We’re gonna go to Teams, we’re gonna go to Slack, let’s study it for a year” and it turns into two years and you final make a decision. All of a sudden, that decision gets made in two weeks or a week or a day—a couple days.

Bennatan: Yes.

Ashley: Like, how could—you just have to. You’re forced to make some decisions and make some changes.

What I’m wondering is, if you accelerate to the cloud and you have, you know, a framework, an architecture, something like an Imperva that—okay, we’ve solved some of those issues, let’s just solve them for other folks and help each other save some time, right? You don’t have to—sure, check me out, validate it, you think this is all the right thing to do. But if you’ve got to do something quick, we’ve got a good bit of that problem solved. It seems like you’re in a good position from that standpoint.

Bennatan: Yeah, and I do believe so. I think that we started very early with the cloud and how do you do this well, and so we are in a good position.

I also really [Laughter]—you know, you said something about this productivity tools making the decision in two weeks, and it’s one of my, you know, one of my pet peeves for my entire life has been something—I don’t see it changing, by the way, yet, but I really wish it would change, okay? Is this concept of a POC, okay? Where you—you know, you need something, like, go back to your two years versus two weeks. What does that mean? It means, somebody picked without doing a POC, right? [Laughter]

Ashley: Make a bet and if it’s wrong, we’ll change it.

Bennatan: Okay, make a bet, and make a bet based on what? You made a bet based on, you know—

Ashley: Best [Cross talk].

Bennatan: – either something that’s more usable or very usable, [Cross talk] or something that everybody else is using.

Ashley: [Cross talk] at the result. I think that’s what it comes down to, right? What is gonna get us the quickest understanding? Nothing’s gonna be perfect, we’re gonna have issues with whatever we choose already, of course.

Bennatan: Yeah, yeah, and this entire industry forever has been, “Okay, I can’t pick anything until I do a POC, but when I do a POC, I’m actually not even checking what’s important, because I can’t reproduce my production environment. I can’t reproduce the load, so I’m just gonna test something, okay? I’ll test, like, really simple things—can you do this, can you do that?”—which has absolutely no bearing on whether you’ll succeed or not.

And what I’m starting to see, especially on the cloud, because it’s much easier to just look at things, much easier to talk to people, much easier to see what your colleagues are doing, what your peers are doing is, I’m hoping that that accelerates things. Because if we need to do something tomorrow, we’re just not gonna wait. We’re not gonna wait nine months.

Ashley: So, here’s what might start to change that behavior. I’m not gonna proclaim that it’s changed that behavior, but through this COVID experience, using that productivity tool example—guess what? Executives, the non-techies of the company, look at us and say, “How come we can make a decision in two days when we were gonna take two years to do it? If we can make that decision in two days, I want us to make the other decisions quickly. Maybe it’s not always two days, but we’ve proven we can make some good decisions under some very difficult conditions and rapidly. Let’s exercise and build up that muscle and do that more often than the thing that we debate about forever.”

Bennatan: Yeah.

Ashley: So, I think there may be some pressure from the business, who’s also, by the way, very disruptive, they’re having to adjust, they’re having to go into defense or offensive mode in the business climate, and they want to be able to experiment very quickly—that’s part of what digital transformation is about, right? Try some things, experiment, and market, go after—you know, learn quickly, much like we do in kinda continuous improvement.

So, that might be the thing that nudges us off of the comfortable stool of, “Let’s take nine months-slash-two years to study it and make a decision or run it—you know, do an RFP for everything.” I hate RFPs, but—

Bennatan: Yeah.

Ashley: – just like POCs for you. [Laughter]

Bennatan: Yeah.

Ashley: But maybe that’s the thing that tilts it a little bit. I mean, I’m not gonna declare success yet, but…

Bennatan: I agree, I agree. I think it’s—you know, I’ve been in startups all of my life, okay? So, one of the things that is really fundamental when you look at a VC that’s investing in a company, they’re investing in the people, not in the company.

Ashley: Exactly.

Bennatan: I mean, this technology, they don’t know yet, okay?

Ashley: They know you don’t have it figured out, otherwise somebody else would’ve done it.

Bennatan: Yeah, yeah.

Ashley: Right? So, your job is to figure it out, but get the right people that can do it.

Bennatan: But they invest a lot of money very quickly, okay? They don’t take nine months, right? So, I believe that, you know, when people look at their partners, who they’re gonna partner with, they need to look at, you know, what are the founding principles of the company? How much is the company gonna care about me? What is it gonna do for me? Are they gonna be there when I need them?

And I’m not saying technology’s not important, because product is everything, but it’s product and the people that stand behind it, and the decisions need to be made, also, from the business level.

Ashley: So, we’re kinda running up against our time, here. I’m gonna point out this irony and hopefully you’ll come back and talk about it. So, you were just talking about investing in people, which is what VCs do, I totally agree with that. And earlier we were talking about—well, the problem we were talking about is human behavior and people, right? So, [Laughter] there are conditions of which will drive different behaviors, and hopefully that’s something we can explore about data and data security some more. We’ll have you back again soon.

Bennatan: Yeah. Okay, I’d love that.

Ashley: Good. Well, Ron, it’s been a pleasure. I wish you all the best. Congratulations on the acquisition and hopefully, you’ll be able to get out of your four brick wall cell there at some point and get out and enjoy the world again. [Laughter]

Bennatan: [Laughter]

Ashley: All of us will, but I wish you the best. It’s been great talking with you.

Bennatan: Hopefully. Thanks, Mitch.

Ashley: Great. Thanks for joining us today, folks. We’ll talk to you soon.

December 10, 2020
TechStrong TV: strongDM With Betterment

Betterment is a goal-based financial advisory company that provides robo-advising services to help customers make the most of their money, taking away all the complexities of investing and saving.

In this interview for TechStrong TV, strongDM co-founder and CEO Elizabeth Zalman and Chris Becker, SRE manager at Betterment, joined us to discuss how strongDM helps make things faster, automated and easy at Betterment by tracking and auditing all changes on their system.

Chris was the project lead for implementing strongDM at Betterment. During this segment, Chris shared his journey of becoming manager of the SRE team at Betterment and the reasons why they chose strongDM to secure access to their data.

Check out the interview below and follow along with the transcript to find out more.

Transcript

Alan Shimel: Hey, everyone. We’re back here at TechStrong TV, and for our next segment. For this segment, we have one of our semi-regulars back here, Liz Zalman of strongDM. Hi, Liz—how are you?

Elizabeth Zalman: Hi, Alan. I’m well, thank you.

Shimel: Good, thanks for joining us. And joining Liz and I today is Christopher Becker, SRE with Betterment. Is that correct, Chris?

Chris Becker: Yep, SRE manager at Betterment.

Shimel: Very cool. So, Chris, you know, I got a little background on Betterment before we started recording today, but why don’t you share with our audience—what’s Betterment? What do you guys do?

Becker: So, yeah, the elevator pitch for us is that we’re a robo-advising platform that helps you make the most of your money. So, the idea with us is, we take away all the complexities of investing and saving and we’ve turned it into a goal based platform that lets you invest your money, save for what you’re going for, and try and make the most on top of the market and everything like that.

So, we—yeah, we try and take all the trouble of saving and all that, we dynamically balance portfolios and things like that for you and, as Liz said, it kinda removes all the distracting stuff with money.

Shimel: Very cool. And, you know, what’d kinda unique about it is, it’s very goal based, right? So, you gotta tell Betterment what are your goals, what are you saving for, here? I wanna buy a house, I wanna buy a car, I wanna put money away for retirement.

Becker: Mm-hmm.

Shimel: I wanna go on—I wanna take 180 days off and cruise around the world. That would be mine, but anyway. [Laughter]

Zalman: [Laughter]

Shimel: You know, so, it’s a pretty unique kind of thing like that, and it’s—I guess it’s kinda uniquely situated for, I’m gonna assume, a lot of your customer base is sorta Millennial, Gen Z kinda folks, or do you get, you know, old people like me?

Becker: [Laughter] We have everyone, all over the gamut. I think—yeah, like, you mentioned the goal based investing, and that’s what’s super important to us. And it helps us sort of like—it helps us make the calculations about how we balance everything.

Me, for instance, I have a goal that’s like saving for a house, and that’s a much different trajectory than something like retirement for me, based on my age and my income and everything like that. And what Betterment helps you do is just save in the best way to hit those goals. So, if you’re trying to get X amount of dollars by Y date, there’s sort of a formula that does that, and if you’re saving for retirement, there’s a different formula that works with that. It’s all kind of within our platform.

Shimel: Cool. So—and, of course, the website, let’s get that out of the way, B-E-T-T-E-R-M-E-N-T dot com?

Becker: You got it.

Shimel: Okay.

Zalman: And there’s a mobile app.

Becker: And there’s a mobile app. [Laughter]

Shimel: [Laughter] There’s an app. And we should also—hey, full disclosure, Liz has told me not only is Betterment a customer of strongDM but Liz is a customer of Betterment, so.

Becker: [Laughter] Exactly.

Zalman: It’s a great product. [Laughter]

Shimel: Take it with a grain of salt—take it with a grain of salt. [Laughter] Anyway, Chris, let’s talk a little bit about your background, though, now. So, you are manager SRE there, and our audience is very, very familiar with SRE and SREs in general. But how does one become a manager of the SRE team?

Becker: Absolutely. My background is particularly interesting. I guess, rewinding the clock a little bit, I was—I got into sort of computers and computer management and server stuff, like, way back in high school. I come from a pretty, I guess you could say, classical IT background. I actually have, like, a Microsoft MCP, if you can believe that, like, from back in the day.

Shimel: I do.

Becker: [Laughter] Yeah, Server 2003 Active Directory, so.

Shimel: Mm-hmm.

Becker: That’s—yeah, I went to a high school with a really great computer program that let a lot of the students get hands on access to stuff, and by my sophomore year, me and my other classmates were sort of managing our computer labs and learning about how to do all that kinda stuff.

So, that’s like—yeah, I guess I was fortunate in that I got into this really early and it was something that I was really excited about and I was kind of like, you know, that guy in high school with my buddies, we built computers and things like that as well.

But yeah, and then right out of high school, I went to college and studied Information Technology as well. And one of the things that, like, for me, I’ve always sort of been, I guess, the jack of all trades when it comes to technology—everything server management, a little programming, and things like that. And then out of college, I actually got a job at Warby Parker doing office support, so like, IT support.

And that’s kind of, for me, where, I guess you could say the automation bug, I got bit by that. Because we were doing a lot of software installations and things like that on people’s machines and we wanted a way to, like, with our two person IT team scale out to support, like, you know, 300 people at Warby at the time.

So, it was like investigating, you know, more things that we use in the SRE world today, like, things like Ansible and things like automation scripts and stuff like that. I was kind of, like, getting introduced to that as a way to just make it so that our small team could manage and automate installations on a bunch of work stations.

And then from there, actually, within Warby Parker, I had the opportunity to change to what they called an infrastructure engineer role which, looking back on it now, it was essentially, like, DevOps, right? You know, because DevOps is, I guess, the big umbrella that covers a lot of different disciplines and stuff like that.

So, from there, I really—I leveled up a lot of my programming skills as well, writing automation scripts and stuff to set up developer work stations. But what was important, I think, in that role for me is that I had a really good relationship with sort of internal customers, as I like to call them, for my IT role where my sort of stakeholders of the things that I built weren’t people that were the traditional customers of the business but rather those that, people that worked or the business.

So, I think a lot of—like, one of the reasons why I like DevOps and SRE and things like that is because it allows you to have a really close relationship with your customers, because they’re in the same company as you are a lot of the time, so.

And yeah—and then after Warby Parker, I got a job as an SRE at Betterment and our team was similarly very small. There was, I think when I started, there was four of us and we were supporting an engineering organization of around 80 folks and then, from there, our engineering team grew as well as our SRE team. And now, I’m the manager of that team and so, having been on that team for two years and change before becoming the manager, I had a really good sense of what we liked to do, things we wanted to build or our engineers and platform things as well. So, now, I’m kind of like at the helm and get to control that, which is really, really cool.

Shimel: Excellent, man. Great story. You know what, Chris, I don’t think your journey is that unusual, to tell you the truth. I mean, I spend my life talking to people like you and Liz and—I mean, what’s different is, you know what, my high school didn’t have a computer lab, my college had punch cards. But, you know, my children, for instance, our local high school here in West Boca Community High, they actually do have, they have actually a Microsoft Certified program. So, a lot of—you know, you become Office certified, big deal, as a freshman. But by the time you graduate, you are Microsoft Certified.

They might have, I don’t know if they’ve moved over to Google stuff now and more cloud-based kinda things, but there’s a cyber security area of concentration they call it, which is pretty cool, too. And, you know, it’s good. I mean, because so many people of my generation who—look, we took the Internet commercial, right, and built what you see here. But so many of them are self-taught, especially in things like DevOps or cyber or, you know, those kinds of things. And so, it’s good to hear people with real academic backgrounds in this stuff. I think it bodes well for the future.

But, you know, part of what you guys are doing, obviously, is, you called it infrastructure engineering or at Warby Parker, DevOps. But the real thing here is that we’ve moved, in your lifetime, right, in your career—I don’t know if they ever had the concept of the server closet and the data center on prem. Everything is SaaSOps, right, or cloud or some sort of hybrid of that, right? There might be some third party data center you use where you’re running, let’s say, a private cloud kinda thing. You mentioned Ansible—well, that was back at Warby, so I don’t know if you’re using OpenShift or anything like that.

But clearly, right, it’s not—this is today’s infrastructure, today’s kinda new stack as I like to call it. What about Kubernetes, cloud native, any of that stuff?

Becker: Yeah. So, that’s like, at Betterment, we’re using Kubernetes. We’re on top of AWS as well. And I think it’s—I like that you mentioned sort of like old server clouds and stuff. I think the last time I interacted with a physical rack server was probably in college. But, I mean, I grew up punching Ethernet cables and racking and stacking and configuring, you know, Ratarays and things like that. And I think what—

Shimel: Fun times. [Laughter]

Becker: Yeah, right? [Laughter] Well, not with Ratarays, but I think—yeah, what I really like about sort of my, I think where my background has been really helpful for me is like, you know, when you enter this new world of AWS and cloud configurations and Kubernetes and stuff like that, like, it’s all still based on the fundamentals. And I feel like I got a really good sense of, and a really good education in networking fundamentals and things like that. Which, if you look under the hood, Kubernetes abstracts a lot away from you, but you still might have to do some kind of site or notation calculations, right? Or figure out, like, some [Cross talk]—

Shimel: It’s been a long time since did CIDR.

Becker: [Laughter] And it’s—and things like, yeah, and figuring out, like, we were debugging an issue with network connections and being able to Wireshark and look at the TCP handshake and figure out why we were dropping packets or getting RSTs or something like that. Like, being able to sort of zoom into those things that we don’t necessarily think about a lot these days when we sort of turn on a server in AWS and we don’t really think about—like, being able to sort of lean on that knowledge is incredibly helpful in those head scratching debugging moments and stuff like that.

Shimel: Yeah. No, no, it’s always good to understand what the underlying technology is about. But part of what—and this is really something strongDM does, right? Part of what we’re doing here is, we want to make it chimp simple. We want it to be fast, automated, easy. That’s a big part of the SRE kinda mantra as well, right?

Becker: Yeah.

Shimel: And so, let’s talk a little bit about strongDM over at Betterment, right? How did—was it there when you got there? It sounds like you’ve kinda built the thing, though, you brought it in. Talk to us about the use case, here. What made you go with strongDM, why, what problem were you trying to itch, here—or, yeah, what scratch were you trying to itch?

Becker: Absolutely. Yeah, no, for us—so, I was actually the Project Lead for implementing strongDM at Betterment. So, I absolutely love it, first of all. It’s one of my favorite apps because I don’t have to think about it ever, and that’s like—if I forget, like, it’s something so seamless and it is so well run that I forget about it, those are my favorite kind of pieces of software. [Laughter]

Shimel: Well, no, that goes to what we just said. We wanna make it that simple, man.

Becker: Easy, simple, automated.

Shimel: I don’t wanna do CIDR calculations.

Becker: [Laughter]

Shimel: [Cross talk] [Laughter]

Becker: Yeah, no—so, for us, we had a need at Betterment, obviously, we’re a financial institution, we have regulations that we abide by and these things, one of these things is auditability and we need to make sure that any changes to any systems that we have and that we run and we operate are auditable, it’s tracked, it’s logged.

So, for us, strongDM was sort of like the perfect picture, because it allowed us to use that platform to get auditability, we could track and log everything as well as push everything with SSH at the time through one system, which was really nice. And it also had the added goal of not being dependent on our VPN, which we’re trying to get rid of as well, for a lot of reasons. [Laughter] strongDM, yeah, allowed us…

And also, the thing that I’ve said amongst my team and one of the reasons why I really like strongDM is, it sort of abides by what I like to call the Unix philosophy, right? Like, it does one thing and it does it well. And it’s very predictable in its command line, it’s very predictable in the way that—its interface and it interacts with other servers and things like that. And it was really easy for us to build out this entire system with, you know, literally running two EC2 instances and they’re able to get into hundreds and hundreds of servers every day and have never had an issue, so.

Shimel: So, Liz, five interviews—this is the longest I’ve ever heard you go without speaking. What’s up? What can you tell us about this?

Zalman: What I can tell you is that Betterment, I think, is, I’m gonna say top three in terms of forward thinking customers that we have. They’ve pushed the envelope in a variety of ways. They were using SSH, I think, where they had requirements for how they wanted engineers to interact with SSH that we didn’t yet support in the platform. I think the same thing went for kubectl as well or usage of Kubernetes. They were the first to really stress our system—not stress our system in terms of, like, we went down, but stress in terms of, “I wanna automate stuff like this, and you’re doing this, and I need you to get to this.”

I can’t count the number of times that Chris asked for a REST API. Have you used it yet, by the way?

Becker: [Laughter]

Shimel: Tell the truth, have you?

Zalman: Have you used it yet?

Becker: Oh, yeah—no, we have. Yeah, we used it.

Zalman: Okay—good, good, good. [Laughter]

Becker: Yeah.

Zalman: They had requirements in terms of directory syncing—yeah, so, it was a pleasure to work with them. And I actually don’t recall—did we meet when you were at Warby, or were you just sort of aware of that relationship?

Becker: You actually, I think you came in to meet the infrastructure team, like, the Ops team at Warby at one point.

Zalman: Yeah.

Becker: Because I remember we were piloting strongDM at one point. I don’t think I was there when the implementation happened or anything like that.

Zalman: Oh, yeah.

Becker: But I was familiar with the product from Warby, actually.

Zalman: Yeah. And Alan, it’s actually interesting—Chris is part of a, Chris used to be based in New York City and in New York, there is this group of infrastructure folks that stays within sort of the B2C world in my opinion and goes to the unicorns. And it was almost borne out of Warby, some went to, like, Harry’s for shaving, some went to Peloton, some went to Betterment—I’m sure I’m missing a couple companies. And they’re almost more forward thinking than our traditional B2B clients are. It’s a very interesting trend.

Shimel: Yeah. You know, one of my good friends is a guy named Brad Feld out of Boulder, and Brad, he founded TechStars and Foundry Group. He used to be—he’s a big VC. But he’s also an author and he’s written this whole series around what they call startup communities, and it really talks about, Liz, what you were just saying, right? Generally, you get a pool of talent, right, in a geographic region—within a community; it doesn’t have to be geographic, actually, but within a community. And that talent, it’s almost like the six degrees of separation, right? You can see a company has a liquidity event, people make money and they start other companies. Or they develop some really great expertise—in this case, kinda B2C, using real edgy kind of…I gotta stop using the word edgy, because it’s now meaning The Edge. But, you know, kind of cutting edge is what I mean—technology players.

And they do, that—you can almost trace the DNA, if you will, right, from company to company to company because it’s that same, the same roots of people. And that’s what makes a startup community, because along the way, right, more people get added into the tribe, if you will, right? And that tribe continues to grow. And that’s how—I mean, that’s how tech centers are born, right? You can trace—like Boulder, for instance; Boulder, Colorado—you can trace a lot of what came out of, what’s coming out of Boulder by from when the storage folks were there and IBM had a big facility there and the University of Colorado and Brad coming in and investing a lot of money. There were a handful of companies that had really great outcomes or liquidity events, and it gave rise to this whole—Austin the same way, I mean, by the way.

Anyway—strongDM. So, Chris, what are you guys using it for? Liz mentioned some REST APIs and stuff like that, but how—what are you using it for, how is it working out, what do you see?

Becker: Yeah, so, we’re using it for, our sort of highest level use case is any time a developer needs to access a server or a database or a cluster, a Kubernetes cluster that we run and operate, they go through strongDM. And for us, like I said before, that was super important, because we want to make sure that all of the changes to our systems are tracked and audited.

So, we have—we actually started out just implementing sort of the SSH back end, and like Liz alluded to, we had some very interesting requirements around directory services. So, we use Okta as our identity provider and directory service.

Shimel: Sure.

Becker: And strongDM helped us wire that together so that a person on the team, their e-mail address and their Okta identity is used by strongDM so that we can sort of tie all those things together.

We also had, like, another thing that Liz alluded to was sort of like, we had a ton of servers and one of our unique use cases was, at the time, we were heavily using autoscaling groups within AWS. So, one of the big things with us and strongDM was that the server inventory was extremely dynamic, depending on load of our servers, depending on deployments and things like that. We might have 100 servers in inventory, we might have 200 servers. And they were coming up and down sort of all day.

So, for us, one of the other interesting requirements is, we needed some kind of automation so that when an AWS would turn on a new server to handle extra server load that that server was automatically enrolled and registered in the strongDM platform.

So, yeah, again, we worked with strong a lot on sort of nailing down that interface and we’ve written some automation scripts and things like that to get it to register and everything like that, and their admin, their admin token API and everything like that made that a breeze. And then our most recent implementation is actually, we use strongDM for Kubernetes. So, we basically have a, when you need to get access to our Kubernetes cluster or debug an application in our cluster, we actually live provision a container and then your proxy through strong, like, right into that container and all of that is audited as well.

And all of our developers, actually, they don’t even—the best part is, they don’t even understand, like, they can connect to an old system or a new system and for them, it’s completely transparent. But yeah, it all runs through strong and it all is—and for our compliance reasons, that’s all audited and tracked and logged, which is great.

Shimel: That’s nice. Two things I wanna highlight here and then Liz, I’m gonna ask you to expand on it. Number one is that, by using strong, what Chris’ team is able to do, as he mentioned, they use Okta—they don’t have to worry about hooking up this person’s identity maybe via e-mail with their Okta identity for purposes of IAM, right, across their disparate network infrastructure, right?

strongDM here, as part of the proxy process, is lining up that person’s real identity, right, their e-mail or whatever you wanna use as their real identity with their IAM identity—I call it an IAM because it could be Okta it could be others, right? And then—but the person doesn’t have to think about that, and quite frankly, Chris, neither do you or your team, right? strongDM just makes that—again, chimp simple, easy, done.

Becker: Yep.

Shimel: That’s number one. Number two—and Liz, this is where I really, I’d like you to comment in—the idea of using it in this Kubernetes system and containers, as Chris is referring to, is that the norm now, or do you think this is kind of an advanced use case?

Zalman: It’s an interesting question. And yeah, I think to your first point, it’s, we’re acting as an infrastructure API, right? We don’t care what Chris is using as his identity store. We don’t care where his infrastructure is, we’re just connecting the dots.

Shimel: Yep.

Zalman: Kubernetes was—I mean, we’ve seen different instantiations of Kubernetes over the years, right? Docker tried with Swarm and it didn’t stick and Kubernetes did. And maybe people were using it, they were trying it on. And I remember, like, the month that it hit production workloads, because I think we got seven or eight requests in one week. It’s like—why don’t you have support for this protocol? And we said, “Okay, time to build kubecl support.”

Shimel: Time to do that, yeah.

Zalman: Yeah.

Becker: Yeah, guilty. [Laughter]

Zalman: Yeah, you were one of them. [Laughter] It was like plain, plain, plain, plain, plain—mainstream. And so, I think everybody is trying to find some way to systematize and puppeteer everything that’s going on and abstract away a lot of complexity.

So, no, to me, Kubernetes is certainly here to stay. I see everybody using it.

Shimel: But is their—because it sounds like their Kubernetes installation, if you will, the way they’re using strongDM is maybe a little different than—is that the standard way that people are using strongDM and Kubernetes or is theirs a little different?

Zalman: I think Betterment has a particular approach to locking down access which is, you literally get this much access or this much access or this much access or over here, maybe this much access. It’s highly tailored and fine-tuned, and I think that is the—that’s sort of the forward thinking way. Like, people talk about lease privilege and Betterment has actually implemented it across the board for every single thing that somebody needs access to.

Shimel: That’s great, man. That’s—and Chris, kudos to you and your team for that, right? Because that is—look, you’re in the financial industry, you’ve gotta do what you’ve gotta do there, but that’s an excellent thing.

Guys, we’re over time, to tell you the truth, but I kind of enjoyed the conversation today, so I let it go. But we need to break out of here. Chris, enjoy—I know you’re about to take, you said, like a week off over that at the shore and enjoy it. I see maybe you’ll get that oar off the wall and actually do something.

Becker: [Laughter] Some paddle boarding.

Shimel: Yeah, that sounds cool. Anyway, I’m just thinking, I’m supposed to be going out on the boat tomorrow, but it’s also supposed to rain, so I’m not sure. But anyway, enjoy your week off. Thanks for joining us, thanks to Betterment for allowing you to tell your story here today.

Liz, always a pleasure to have you on and hear more about strongDM and this whole kind of—you know, these new companies, not necessarily new like today new, but a new way of doing things and a new way of making it easy to bring people on and access assets wherever the infrastructure is, so—fantastic.

We’re gonna wrap. This is Alan Shimel for TechStrong TV. We’re going to be right back with our next guest.

September 29, 2020