staging-devopsy.kinsta.cloud

Author: Mitch Ashley

  • Web Isolation and Secure Web Gateways with Menlo Security

    Web Isolation and Secure Web Gateways with Menlo Security

    Since the COVID-19 outbreak, many enterprises have implemented remote work policies to monitor network traffic and protect sensitive data. Organizations have been adjusting and adopting new practices and technologies to improve data security across cloud-based environments.

    In this episode of TechStrong TV, Nick Edwards, vice president of product management at Menlo Security, joins Mitch Ashley to discuss the move from network and application firewalls to creating web isolation, using secure web gateways for updated, contemporary cloud security.

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

    Transcript

    Mitch Ashley: I have the distinct pleasure of being joined by Nick Edwards. Nick is VP of product management at Menlo Security. Welcome, Nick—good to be talking to you.

    Nick Edwards: Hey, Mitch, thank you. Glad to be here.

    Ashley: Excellent. Well, tell us a little bit about yourself, and tell us a little bit about Menlo Security for folks who may not know much about Menlo.

    Edwards: Sure, yeah. So, I am VP of product management at Menlo Security. So, my team is responsible for kind of product direction and definition of our company and where we’re taking our product line. 

    I came from somewhat of a circuitous background. I spent time in the Navy, I was a Submarine Officer, so I kinda feel like I’ve been, you know, in the good guys versus bad guys world for a while. And, you know, cyber security has always been something that’s kind of near and dear to my hart, just because, as a society, I think technology can bring on so many positive changes, but it’s unfortunate that we have to deal with this overall drag of embracing it because people are capitalizing on it.

    Ashley: Mm-hmm.

    Edwards: And Menlo was started with the fundamental notion that how we’ve been going around fighting security is just not keeping pace with kind of where the bad guys are and where the threats are. You know, in the traditional world, it’s around letting traffic in and then inspecting it. You know, you basically put the traffic stream underneath the magnifying glass, you have the Petri dish, “Is this a virus, is this malware, is this phishing?” or whatever it may be. And the industry has gotten a lot better at detection, but the bad guys only have to be right once.

    And so, our fundamental approach is different, which is—you know what? We’re gonna not let anything in, and instead, we’re gonna give you a clean stream that is reconstructed via our technology called isolation. And so, you’ve probably heard this term of web isolation—that’s what the company was founded on, and that’s what we do. And it’s been primarily made more simple to adopt and execute on by the advent of cloud computing and the capabilities that are continuing to expand kind of on that front. So, we’re excited to be here, excited to talk to you more about it, and let me know what you think about, what you wanna talk about.

    Ashley: Cool. Well, you know, as more and more of the network stack has been virtualized and turned into software, it makes sense that you’d see innovations like what Menlo Security is doing, right? Because you can do things very quickly and innovate very quickly in that space. And it’s kind of interesting to me that—you know, we hear about network isolation in WiFi and other technologies, because the pipes are just getting bigger, of course.

    Edwards: Mm-hmm.

    Ashley: And just, that much more of trying to inspect as it’s coming in in real time, it makes sense that—I can see how reconstructing that web stream, as you’re talking about.

    I’d love to get your perspective of what’s the thing that somebody goes, “You know what, we need a secure web gateway instead of what we have”—what is the impetus, or impetuses, if that’s a word, to say, “I need to get to the next thing, because this ain’t workin’ for me”?

    Edwards: So, I think a couple of factors. I think one, and we saw COVID and the work-from-home dynamic of the past year expedite this, is just that when you and I were growing up in the office of 20 or 30 years ago, everyone got in their car, they drove to the parking lot, they walked in, their computer was waiting for them, and everything was in one location. And that made it easy to apply security and controls. 

    I remember my first spam message that I got, you know, in 2001 and I thought that was really weird. And I remember not being able to go to certain websites, and it was very easy to do that because everyone was in one location or, okay, maybe a big multi-national had three different locations, but it was all connected to the same network and it was easy to provide policy, and kind of what proxies merged from that environment.

    Now, you fast forward even to 2019, you know, roughly 20% of the workforce worked remotely. Then, during COVID, it quickly became 75% or greater. And so, with that, it meant that everyone is everywhere. You know, you might be at home, at a coffee shop, in the old days at a WeWork or something. And in that environment, it was very difficult to apply security based off of different devices they were accessing the Internet with, what they were doing, where they were coming from, and COVID just made that worse.

    So, I think what we’re seeing in our customer base, the people we’re talking to is, they realize that they’ve been kind of using Band-Aids to hold the old notion together, but they realize that the cloud offers a new way to think about things. And it isn’t just taking the old widgets and just dumping it in a VM, it’s about—hey, is there a way to fundamentally rethink how we can leverage this technology to advance our business needs?

    And I think all that combination of factors, you know, different users coming from different places, different devices, what they’re trying to do, applying policy based off the context of the user—all those factors have combined to really, I think, kind of introduce this tipping point of new ways of thinking about leveraging technology. I think web gateways delivered via cloud form factor is one of the primary kind of locomotives for people to rethink about their architecture.

    Ashley: It’s interesting you say that. I’ve had several discussions in the last month or so about, as people are thinking about a hybrid office or something about returning to the office, it’s really easy to kinda fall back into, “Well, let’s do what we’ve been doing, right, and make some adjustments.” And I had to go through this transition, actually, a few years before this of thinking about it as just a work anywhere strategy, whether they’re sitting in Starbuck’s or sitting in the United Club, they’re in London or Denver or South Florida—wherever they are, or in an office, or at home, or on the beach or whatever, you just have to think about it.

    And I think that was one of the choke points we ran into with COVID was, the natural tendency was, “Well, okay, swing all the traffic onto the corporate VPN, push it all through our existing pipes” and sometimes, that can fall apart on you, right?

    Edwards: Yeah.

    Ashley: It’s just so much of a big swing. How do people need to rethink this, you know, thinking in a secure gateway, web gateway mode?

    Edwards: Yeah, so, I think that whole trend that we described of, “Put everyone on the VPN” and then—uh oh, VPNs can’t keep up, call up our VPN vendor, give us 50 more boxes. 

    I think what we’re seeing customers re-evaluate is, instead of giving everyone access to everything, let’s flip it on the head and say, “Let’s give them access to only what they need.” And this notion of zero trust is what is kind of capturing this movement, you know? “Okay, we know this is who you are, this is your role. You may be a salesperson—you don’t need to have access to Jira or Jenkins or these development tools, but maybe you need to have access to our CRM system, our customer application for managing pricing and quotes and all this kinda stuff.”

    So, zero trust [Video freezes].

    Ashley: Oh, we lost Nick, there. Let’s see if he comes back—oh, there, you’re back.

    Edwards: Okay.

    Ashley: Okay, so, just, why don’t you re-start with, you were talking about Salesforce and getting access to the applications, you don’t need Jenkins and Jira and stuff. So, you can just pick up on—so, zero trust in a secure gateway, web gateway means this.

    Edwards: Yeah. So, zero trust in a secure gateway mans that, instead of giving users the ability to go wherever they want just because they’ve authenticated, you give them the ability to access the content that they need associated with who they are and their job. You know, a sales rep might need access to certain applications that an engineer might not need access to.

    The VPN model allows anyone who gets connected to have access to whatever, and cyber criminals realize that and they can move around laterally and they can exploit that. And a similar type of construct applies when you’re facing the Internet side of the network. Get people access to what they need and secured gateways via the cloud have much more granular capabilities to do that with tools like CASB, DLP inspection. 

    I think cloud gives the ability to do things at scale that on premise proxies can’t. So, for example, something as seemingly mature and pedestrian as SSL inspection, you know, that’s been around a while, but I remember in the old days, having to scale X number of proxies to be able to address the traffic. Now, almost any website that is being used in a professional manner has SSL and cloud allows you to inspect that very easily and very seamlessly. 

    And on a Menlo perspective, zero trust says, “Hey, look, for Internet related applications, deploy the same type of mentality,” except you flip it on its head and say—don’t trust any of this content from these websites. Okay, maybe you wanna trust O365 for Microsoft, dedicated IP space, domains, you may wanna do that. Or Zoom, for example. But other than that, you might wanna say, “Let’s just allow a clean stream to come in.” And that’s what Menlo does with our isolation by kinda stripping away all the active content, rewriting the web traffic, and giving this native experience to users in a way that doesn’t disrupt their flow or doesn’t require another agent to be deployed on their endpoint.

    Ashley: Plus you have the scalability of the cloud, right? So, you’re not looking to add another box, right, to do this.

    Edwards: Yeah.

    Ashley: It’s, “Okay, great, traffic doubles, we’ve got the resources right there to handle it.”

    Edwards: Yeah. Yeah, that’s right. And, you know, there are some vendors out there, I think, in the cloud web gateway world who have done a lot to mature the industry’s understanding of it. But there’s, again, I mentioned this earlier that properly capitalizing on the benefits of the cloud doesn’t mean taking what you were doing on premise and then just dumping it in a cloud data center. 

    It gives the opportunity to think about things anew and potentially consider new architectures, and leverage the autoscaling of public cloud infrastructure where it makes sense, leverage the near infinite compute and all these things where it makes sense, but still be able to deliver the same type of capabilities. And that was kind of the approach that Menlo took, being kind of more of a cloud native security company delivering these capabilities to our customers.

    Ashley: Mm-hmm. I wonder, too, if—you know, we have different software architectures that can tend to be more porous, you know, with microservices, service mesh, et cetera. We have hybrid, multi-cloud—so, we’ve got a much more, in some ways, complex environment than we had in our on premise data center if that, I don’t know if you wouldn’t say it was complex, it was. But it’s a different world, and the pace at which it can change is so much faster. I mean, you can have an application pop up in a week or a day or an hour that wasn’t there, and now you have to be able to respond to, “Oh, sorry, we didn’t enter a ticket for security to configure us,” right?

    Edwards: Yeah.

    Ashley: You need to be able to react quickly. What do you think are some kinda new applications that are pushing the boundaries of security that make it easier to do it in the cloud?

    Edwards: So, I mean, I think in general, there’s a proliferation of engineering teams inside organizations that are adopting the same type of model of just rapid iteration and agile development for their own products that they’re releasing to their customers. And so, the companies that we’ve seen are some that, they may actually use a combination of AWS or Azure or Google, but they’ll also probably use some of their own data center infrastructure that they’ve already leveraged in a model that is very similar to AWS.

    So, I think this notion of customers going through this migration path, of going from all on prem, maybe with a target of landing with nearly all SaaS, there will be this period of kind of hybrid modes where multi-clouds exist, their own or a public cloud. And I think what we see is customers kind of chipping away at this over time, and an application that was on prem, they say, “Okay, let’s run it in our own kind of cloud data center type of thing” and then slowly migrate that over to AWS or whatever.

    So, we see a lot of this kind of sequenced staging of applications and assets, and with that, it means that the data ends up living in these different places as the application evolves. So, from our perspective, this requires of our customers a rethinking not only of the technology assets, but also the team structure and the profile of the teams. All these teams have to have some level of application understanding, scripting, automation capabilities, whether you’re the application developers or the networking teams, or the SOC teams. 

    And I think the vendors who will end up winning in this world from a security perspective will build security tools that play well in that environment. So, we’re talking about having APIs that will work with their SOC teams, have APIs that will work with, come to their networking teams, so if they need to make network changes quickly, then the cloud applications will be able to respond accordingly.

    And so, in that world, it helps kind of being API friendly and kind of cloud native, because hopefully, that will easily extend to the environments that we’re deploying in from a customer point of view.

    Ashley: There we go. I keep hitting my mute button. You’d think I’d be used to this by now. [Laughter] You mentioned several things I thought were really interesting, and one of them is that, we’re using many, many more SaaS applications, as you referred to, Office 365 as well as SaaS applications, but think how much more Slack and Team and other online non-premise applications that are being used in the cloud. And a lot of times, those things don’t go through IT, and maybe the Finance Department does their own conversion from what they’re using to some cloud financial system or adding other apps to what they’re doing.

    It seems like that ability to be able to isolate some of those environments, make sure that SSL is being used across all of that, and making sure that it’s not a bigger pipe into a bigger world that’s opening up the rest of the network through somebody else’s service is a huge value, and having that visibility is super important.

    Edwards: Yeah, I completely agree. And I think one of the things, when we talk about isolation as a technology construct, not only do we essentially kind of rewrite the web stream that lands on your browser, we also have a similar capability of doing that for documents.

    So, for example, a good application is exactly what you mentioned with SaaS services, and let’s say you’re posting something on Dropbox or maybe you’re accessing something from webmail. Well, what we see customers wanting to do with our CASB solution is say, “Hey, look, we know there’s all these SaaS apps. There’s a world that we know are sanctioned by our company based off policy. So, we’re gonna let people do what they need to do there, maybe insert security for file scanning and all that kinda stuff. But if it’s an unsanctioned application, maybe we want our employees to still be able to go to webmail, but we don’t want them to necessarily download documents and potentially infect our environment.”

    So, what they can use Menlo’s approach for is to basically use isolation of the document. In this case, the document gets kind of rendered as a safe .pdf, so someone can actually still access it. You know, because IT Departments don’t want to be Dr. No and just say you can’t do anything, because in today’s environment, you know, younger employees, Millennials, that doesn’t work for them. But I think people realize that there is a balance between security and still being able to do your job and maintain your own kind of life.

    So, with unsanctioned applications, we’ll give people the ability to actually still go to these applications, but then use isolation to render documents in a secure fashion, or render the content in a secure fashion to give kinda the IT teams maximum flexibility based off policy and the use cases of the users. And I think that’s something that kinda gives the users the ability to strike the right balance based off their employee base and their business needs.

    Ashley: Mm-hmm. I think that’s a really good point. Where do people typically make this transition to a secure web gateway? Is it, “I’m in the process of moving to cloud, I’m setting up my infrastructure, getting ready to move my apps and interconnect with third party apps that I’m using, let me set it up then” or is it oftentimes, “No, I’m in the cloud, I’ve gotta figure out a better way to do security. Let me add a secure web gateway to it”?

    Edwards: Yeah, so, I would say there are kinda two types of customers, as you alluded to. There’s next gen companies who were born in the cloud and they’ve only ever known the cloud, you know? Like, consider any of your contemporary startups that are now successful public companies. They were predominantly born in the cloud, they might have added some on prem stuff for a variety of use cases, but predominantly, they’re cloud first, and they’re a different type of sell and they get it, and they understand it. And, as they have their workforce more broadly deployed, it just makes sense for them to have a way to instrument policy and security across their workforce.

    The customers who are coming from an on-prem environment, maybe traditional large financial institutions, health care, maybe military and defense environments—for them, I think, we’ve seen an acceleration of their adoption over the past several years, and really culminating with COVID as they realized, “Hey, look, this is just very problematic and costly and the TCO associated with maintaining this is problematic.” Main drivers that are the tipping point—remote us, SSL inspection and just having to deploy another box to do CPU intensive scanning. And I think just this overall notion that they realize that the SaaS adoption of all these applications, it’s here to stay, you’re not getting that genie back in the bottle. Oh, and by the way, it is making the company more effective, efficient, and in a more cost friendly manner—so, how can we find a way to embrace that trend and make our business more successful during this march toward digital transformation, but do it in a way that aligns with our own cadence of adoption?

    And I think those trends kinda culminate, and we’ll see a lot of customers start with the kind of CASB use case of securing these applications and doing it in a way that makes sense for their policy, DLP, and security related reasons, and that’s one of the main drivers we’ll see for a lot of our customer engagements when they’re coming from on prem.

    Ashley: Interesting, too. I can totally see that evolution that people have to go through.

    Edwards: Yeah.

    Ashley: Are there any operational considerations that folks need to make in thinking about security differently? Is it different from an operational world making it easier, less false alarms, those kinda things? Because we’re adding more stuff, right? I had a CISO tell me once, “Every product, I evaluate whether it adds any work. If it adds any extra work, I don’t look at it, because I just, we don’t have resources to do it. I can’t add more stuff to my team.”

    Edwards: Yeah, yeah. I think that’s a very valid concern from buyers, and we hear that a lot. They don’t want more loads for the SOC team, they pretty much don’t want another pane of glass to manage, configure and look at reporting.

    So, I think that all of these products need to think about it through the lens of, you know, not only who’s gonna be typing away setting policy, but also, the CIO, CISO, the people who are gonna be consuming the reporting and where they can get access to the information they need to evaluate their purchase decisions and that sort of thing.

    So, I think, on that level, having an API friendly platform that can integrate seamlessly with security orchestration tools, that might be a place in the Security Operations Center that can integrate with other networking devices. All that stuff helps alleviate that friction and that pain. And I think, you know, one of the things that we’ve seen for customers who deploy Menlo is that, with isolation, we actually reduce the number of spurious alerts. Because, you know, you’re not getting all this gray area vendors who rely on detection saying, “Hey, we don’t know enough to say this is bad, but we don’t know enough to say it’s good, so we’re gonna just flag this as an orange” or, you know, whatever. [Cross talk] But hey, you’ll have a human being who can look at it and they’ll decide.

    All that stuff goes away with Menlo, you know? So, what we’re able to do is just deliver this clean stream and we’ve seen multiple customers who, you know, their alerts dropped 80, 90% because of the fact that the data that they’re seeing of their users is no longer being triggered by their endpoint detection tools, these other tools that were kinda living in this gray area. And that means a lot to our customers and kinda their SOC teams.

    Ashley: Cool. What does it take to set up something like this? What’s the implementation process?

    Edwards: Yeah, so, there are a couple different ways. It depends on where the customers are coming from. I mean, I think the most fundamental, simple approach since it is SaaS is that they don’t need to deploy any hardware. There’s the PAC file that lives on all their endpoints, which basically will point traffic from their computers, laptops, et cetera to our cloud form factor, and that’s easily disseminated. Or in some cases, they might want to route traffic from their firewalls or other upstream network devices to us.

    All those things typically take less than one business day, you know, to get up and running. And we’ve had customers, one of our biggest accounts is the Defense Information Security Agency, and they’ve entered into a long-term business relationship with Menlo, and they have all these different teams who are deploying our technology. You know, different military groups, different defense agencies. And it’s basically, “Hey, Menlo, we need to get up and running on this particular agency” and it usually can happen within a matter of several days at a maximum. We’ve had customers scale to tens of thousands of users in a matter of hours. 

    And that’s, again, leveraging the benefits of cloud computing. You know, in the old days, it would be, “Okay, let’s have a pilot for a couple users, and let’s get one or two boxes—okay, great. Let’s do the math. Okay, we have 10,000 users, we need 5 more boxes.” And then if they need to scale quickly, then they’ve gotta make a phone call, I’ll have the box get shipped and all that kinda stuff—cloud takes all that headache, all that thrash away, and you can just leverage the autoscaling that’s inherent in cloud computing. And I think that’s something that really will help expedite the adoption of this as customers become more and more comfortable with security and the compliance associated with it.

    Ashley: I’m glad to hear that. You gave me a few flashbacks to the, “Where is it? It’s in shipping? Okay. Who’s gonna rack and stack it? Okay. Who’s configuring it? Okay. Who’s putting testing and putting in for”—you know? Whoa.

    Edwards: Yeah, yeah, the weekend change requests, you know, [Cross talk] by the IT guy coming in on Saturday night, you know? All that stuff, a lot of that pain has gone away by the new form factors.

    Ashley: Mm-hmm. Cool. How do folks get ahold of this, get access, try it out? Where do they go?

    Edwards: Yeah so, come to MenloSecurity.com, we have a Contact Us, you can try now. We have ways where you can kind of go down the self-service path to play around with it and see that, you know, try menlo.com. Or just feel free to shoot me an e-mail directly, you know, Nick.Edwards@menlosecurity, happy to help point you in the right direction and to cut through all the red tape. You know, we have customers who call up on a Monday with a security issue, we can be out and deployed within that week to get them the security they need, and we’re happy to help customers meet them where they are.

    Ashley: Excellent. Cool. Well, it was really fun talking to you, Nick. Thanks for joining me today and haring more about secure web gateway technology and services that you guys offer from Menlo Security.

    Edwards: Alright. Thanks a lot, Mitch. I appreciate you having me. I appreciate it. See ya.

    Ashley:  You bet. Look forward to talking with you again. Join me in thanking Nick Edwards for joining us today, VP of product management with Menlo Security.

    Edwards: Thanks.

  • How to Use the Assessment of DevOps Capabilities (ADOC)

    How to Use the Assessment of DevOps Capabilities (ADOC)

    The Assessment of DevOps Capabilities (ADOC) is crowdsourced, vendor-neutral and designed for individuals, teams and organizations who want to baseline their current DevOps state, identify the next target state, gain insights into how to improve their organization and team capabilities and measure and accelerate continuous improvement during their DevOps journey.

    The assessment models five DevOps dimensions – the human aspects, process and frameworks, functional composition, intelligent automation and technology ecosystems – to help you gauge your DevOps maturity and identify areas for improvement. In this TechStrongTV interview, Accelerated Strategies Group CEO Mitch Ashley talks with Ulises Gonzalez and Leonardo Murillo, two DevOps Institute Ambassadors, about how to apply the ADOC to get the most out of any DevOps journey. The video is below, followed by a complete transcript.

    Announcer: This is Digital Anarchist.

    Mitch Ashley: Well, I have the pleasure today of being joined by two very interesting gentlemen, we have a great topic to talk about. The first gentleman is Ulises Gonzalez, and also Leonardo Murillo. Very nice to meet you both. Congrats—good to be getting together with you. Congratulations on getting together, [Laughter] to have a TechStrong TV talk.

    Leonardo Murillo: [Laughter] Thank you. Thank you, Mitch.

    Ashley: Ulises, would you introduce yourself? Tell us a little about you and who you represent.

    Ulises Gonzalez: Oh, absolutely. I’m Ulises Gonzalez, I’m a DevOps Ambassador for Panama. I’m a Product Owner on Agile611. We are a company of way of working located in Spain and Panama. I’m glad to be here.

    Ashley: Great to have you. And Leonardo?

    Murillo: Alright, thanks for having us here, Mitch. So, my name is Leonardo Murillo, and I’m CTO at Qwinix, we’re a product engineering company in Denver, Colorado, and I’m also Founder of Cloud Native Architects, which is a consulting firm specialized in continuous delivery, security, and reliability, doing consulting for enterprises, and I’m based out of Costa Rica.

    Ashley: Excellent, excellent. Well, good to be with you both, we have a fun topic. I know you both are DevOps Institute Ambassadors. For people that don’t know what DevOps Institute is or maybe what the Ambassador program is—does one of you wanna take a shot at kinda giving a quick overview?

    Murillo: Absolutely, I can give it a shot. So, there’s a huge component to DevOps that is human centered, right? It’s about culture, it’s about practices and kinda mindset. So, the DevOps Institute is an organization that looks to provide a means for DevOps practitioners to skill up, to gain knowledge, to network. It’s at DevOpsInstitute.com, so I really encourage everybody to go and find out some more. It’s a great, great organization.

    Ashley: A lot of sharing, a lot of collaboration. A lot of folks who are going through the same journey, maybe at different speeds or different places with their career or with their organizations, so what better place to work with each other, learn from each other, and help each other? So, that’s a great thing. Very cool organization, the DevOps Institute.

    Well, we’re here to talk about this new assessment program, the short name of it is ADOC, but it’s the DevOps Institute Assessment of DevOps Capabilities—thus, ADOC.

    So, does one of you wanna tell us a little bit about what the assessment is for? Why would someone want to use this as an assessment tool?

    Murillo: Why don’t you go first, Ulises? [Cross talk]

    Gonzalez: We need to remember that adopting DevOps is not a one-day process. Adopting DevOps requires a lot of effort, a lot of co-working, a lot of understanding on where we are. So, understanding your DevOps capabilities is vital to assess your current practices. And then, it helps to know how to devise or develop an improvement plan, it’s very important.

    In my experience, when we don’t know how to do DevOps implementation in a proper way, we can do more damage, do more harm that receive the benefits. That’s why DevOps capability assessment is a very wise decision to make to start or to understand where we are. Where we are to make good decisions, to get that deep understanding about our practices, and of course, to make a plan, to make a—how to define the next steps to be close to our goal or our vision to accomplish. That’s why DevOps Capability Assessment is a more than a tool, it’s a very wise way of starting of gaining understanding on what we are doing in our company.

    Ashley: Mm-hmm. Good overview. I know you both are with partner organizations that would actually help people go through this assessment, correct?

    Murillo: Correct.

    Gonzalez: Yeah.

    Ashley: Great. Leonardo, why don’t you say a little bit about what you think that process would look like? And by the way, it’s not an unusual thing to hire someone to come in and do an assessment and get an external perspective, and then you kind of evaluate where you are and decide where you wanna go or what things would help you get to the next place.

    This really gives you a standardized way, something that you’re at least kind of—not quite a benchmark, but something kinda like that so that you have a consistent assessment of how you’re looking at organizations so you can benefit from what others have learned about going from where you are to whatever the next step is. Does that make sense?

    Murillo: That makes sense, and I think you basically are talking about some really relevant points in terms of kinda like the standardization of the tool to assess, right? Because as Ulises pointed out, it is a long time effort. It doesn’t happen overnight. And it requires the involvement and ownership of many people across the organization. It’s not just technology alone, right, that will enable this transformation. And I think the assessment is a tool that needs to be leveraged and revisited often, right?

    Because, as you perform initiatives or as you deliver initiatives towards elevating a certain capability, the target is gonna continuously move, right? And you wanna make sure that, as you progress, you have a common framework that allows you to really gauge progress, right? Because you wanna be able to compare your previous state to your current state as you work towards that desired state, right? And in the context of capabilities, for instance, there is something relevant as to thinking of capabilities in terms of dimensions as kinda like the DevOps capability assessment approaches it, and not as maturity.

    Because capabilities are subject to continuous improvement. There is a certain sense of kinda like a ceiling to maturity, right? You’re mature now, there’s nothing else to do. But there is an ongoing process of continuous improvement which, I think—well, I think we’re all into DevOps, right? We know continuous improvement is one of the core fundamentals, right, of DevOps adoption. And that’s a little bit—and also talking about how, I think, this should be approached and how, at least my organization, approaches it. It’s not a one-time assessment, and a one-time picture that tells you how to get to the end, it’s an ongoing process, and this is just a way for you to quantify the current state. And you will need to continue doing that as you progress, and deliver initiatives in the dimensions where more value can be extracted. Does that make sense?

    Ashley: Yeah, very much so, and I’m glad you brought up the maturity. I mean, there are methodologies, methods of using, a maturity matrix. Those tend to be, you know, do you have a process, do you follow it, do you improve it, or whatever that might look like as your adoption. DevOps is so customized to organizations, where they are, how they create software, their own sort of life cycle of how they work, which is one of the great things about it, but there’s no one way to do it to assess that, “Are you mature?”

    But I think that point in time look at it makes a lot more sense of how to think about where we are now on our journey. You may want to course correct, right? You may wanna say, “We’ve learned a lot, and we’ve actually just learned that this actually is really something that’s even a more beneficial part of DevOps, let’s focus on there, next.”

    Am I on the right path, here, Ulises?

    Gonzalez: Oh, absolutely. To me, the process of continuous improvement is literally endless. Organizations and companies are immersed right now in a competitive environment that is constant and required a lot of frequent changes—in every sector, in every area, in every country. That’s why quality process improvement becomes literally an imperative. For that reason, the purpose of offering products demands and services demands us low cost and meet customer expectation.

    To me, as I said, I’m very aligned with Leonardo. It’s very important to get insights about our current transformation state. Identify what our strengths are, and understand and accept our weaknesses to make decisions. Because the decision latency is critical to reduce, because we need to inspect and adapt about our outcomes. DevOps, it’s not only about tools, even though that kind of tool, like the assessment, helps us a lot to, as I said, gain insights from different points of view. In my case, a Product Owner, a Product Development leader, we need to inspect constantly about the results that we get. Because it’s not about what I want as a business, it’s what a market needs. That’s why this kind of assessment helps us a lot through this kind of process, to realize how steps we need to make to get close to our goal or our business objectives for this month or this quarter.

    Murillo: And let me riff off of that a little bit of what you just said.

    Ashley: Yeah—please do.

    Leonardo Murillo: I think you raise a very valid point in terms of prioritizing, right? And I think that’s very valuable of this type of assessment. When organizations approach the adoption of DevOps, attempting to follow a pre-defined path, a pre-defined immutable process, they’re really not evaluating what is most meaningful for the organization at that particular point in time. Like you were just saying, right, when you’re building a product, you wanna deliver those features that are most meaningful, that are gonna provide the most value to the users of that product.

    And I think a capabilities assessment gives us a little bit of that in the context of an organization. There are many, many different dimensions and sub-dimensions of what an organization can improve towards DevOps maturity. But what is more relevant to your organization at this point in time is not gonna b the same for other organizations.

    Ashley: Mm-hmm.

    Murillo: And this type of assessment gives you the ability to identify where to focus your efforts. Because you don’t wanna try and boil the ocean; you don’t wanna try and fix everything at the same time. Because then, you likely will struggle, right?

    So, this concept of identifying, granularly, which areas allow for improvement and providing a quantifiable means to assess which ones are more relevant or your organization at this point in time is a very effective mechanism to direct, after all, scarce resources. There isn’t endless money, there isn’t endless time, and there isn’t an endless capacity of people to change. So, you need to very effectively apply initiatives to those areas that make the most sense for your current state.

    Ashley: Mm-hmm. Spot on—very important point. [Cross talk] How is this administered? How does someone go through the assessment? Is it a series of interviews, do they fill out an online survey? Lots of ways of doing these things—how do we do this with ADOC?

    Murillo: You wanna talk about that Ulises?

    Gonzalez: Yeah, a little bit, it’s ________, it’s a mix between online surveys and, of course, interviews with several leaders or persons of importance of the company, because we need to understand or get that 360 degree understanding about what is really happening. That’s why the instrument or that kind of assessment, it was common understanding of what we need to know about we need to understand what we are.

    That’s why we can use it in several ways. As you said, we can use it from an online survey, so everyone can participate independently of the part of the value stream where you are, because this is a very important topic. And then, when you get inside, you can interview the people who are already responsible, already part of the time to start to make decisions. That kind of point is very important to me as well, because this instrument allows us, we can gain a capability to make decisions as well. We need to wait a long period of time. We don’t need to wait a lot to make decisions quickly in a smart way, data-driven. We can make a data-driven hypothesis, we can put in our roadmap a lot of, as Leonardo said, prioritizing steps to get what the company wants. That’s why this is an easy way to get a lot of understanding on what’s happening right now in our company.

    Ashley: Mm-hmm.

    Murillo: And let me share some ________ as to how I think this also needs to be applied. Because as Ulises mentions, right, the tool itself is an online delivered Likert style assessment, right—multiple questions, different dimensions, and that is used to define the scores to your capabilities.

    But as we’ve mentioned multiple times in this conversation, ever organization is different. And I think this is also where the DevOps Capability Assessment is being partner led. There are consultants out there that are delivering this and applying this in organizations.

    I think this is also why it’s very important to partner with somebody. Because it’s relevant to have an external view to understand where there might be bottlenecks to tie this together with other practices when you think kinda in terms of value stream management. You wanna make this tool a component of a comprehensive intervention, and that intervention is going to be defined not just by the tools that you’re using, but also by the structure of the organization.

    You will want to understand exactly what your structure looks like—both in terms of paper, what the organizational structure looks like, as well as in terms of team dynamics. And that will give you a sense of who you really need to talk to, who are the ones that are influencing, who are the ones that can give you further insights? Extend the tool. I think that’s very important in terms of applying this, which was kinda your original question, right, Mitch?

    Ashley: Mm-hmm.

    Murillo: And this is just one tool in an arsenal. It’s a tool that satisfies a lot of precision in terms of gauging a state, and it needs to be executed in a way that is consistent with the organization, just as the process of maturing into different levels of skill, right, will vary depending on your unique characteristics. I think that also applies in the context of delivering this type of assessment. There is a discovery opportunity for partners to really get to understand the culture of the organization, the culture of the teams.

    And I think another component that is relevant, and in the book Accelerate, that I’m sure everybody is familiar with by now, there’s this concept of organizations trying to apply DevOps practices to one group and then just trying to replicate that across the organization and now that really doesn’t work too well.

    As you expand your DevOps adoption to more groups in the organization, you’re gonna have to repeat a little bit of the process to really understand how each one team will evolve, and what is the current state of each different organization as you expand. This is not something that you do once, you transform a business unit once and then you copy paste. That’s kinda all the thoughts that come to mind when you mention how this actually looks like in practice, being applied within an organization.

    Ashley: Well, and it seems extremely helpful to have the data that’s collected through the online portion and then really, those interviews also add, as you mentioned, talking about things like culture, structure of the organization—it’s that context, right?

    So, you may be wherever you are on your answer to certain parts of the assessment tool, but understanding how that fits into your environment, your company, your culture, how you work—I like to describe thigs as, you know, if you are a data driven, no decision gets made without data, that’s a different kinda culture than one who goes by, let’s say, these are the inspiring leaders that help make the important decisions, right, just to pick two very different examples. But that context matters. You’re gonna take different actions based on the environment that you’re doing DevOps in. [Cross talk]

    Let’s talk about how someone would use this—I’m sorry, Ulises, I cut you off there, but we really wanna hear, too. So, you go through this process with your help. What does someone get from it? Do they get a document or a readout? And then how do you go about helping them with the next phase of using some of that information to their benefit? Go ahead.

    Murillo: Yeah. Go ahead, Ulises.

    Gonzalez: Okay, everybody. [Laughter] Okay, to me, of course, there are different outcomes you can get, absolutely. You can, after you complete that kind of assessment, you gain insight of your current information, you get the ability to benchmark your teams and your organization across different industries on your actual level of practices. With our help, you can visualize the road ahead from one baseline to another future state. Of course, the management gets the investment areas, so we need to make decisions. They’ve got very normalized indicators to understand what we need to do on the next iteration or the next spring or the next process.

    Of course, the operation teams part gets understanding on most critical areas you need to improve. So, as I said, the assessment brings us a lot of information with data, normalized data, in a controlled environment to make decisions, to make smart decisions, to gain common ground, to create consistency. Because, as Leonardo said previously, to me, it’s about consistency and a holistic view in a way that enables everybody in the company to understand independently of the level that we are, we understand the same parts of DevOps that we need to achieve, because it’s a business outcome we need to support.

    So, that provides us with a high impact of our software, our service, our productivity. So, more than an instrument that provides us number, it gives us very helpful insights, as I said, to make wise decisions.

    Ashley: [Laughter] I appreciate your perspective on it, Leonardo, because what you’re describing, Ulises, very much follows that Plan Do Check Act.

    Gonzalez: Yeah.

    Ashley: You know, take those actions based on that continuous improvement process and cycle again so you can use this as a tool more than once, right? You can go back and assess yourself maybe in a year or so, see if you—did you end up where you thought you were going to head, or did, actually, the journey migrate a little bit, move a little bit on a different track, now let’s adjust to that and move forward?

    Murillo: Exactly, exactly. And I think the Act component is where there’s a lot of room for creativity and innovation, right? Once you have your, as Ulises points out, your normalized metrics, right, your normalized numbers, you will need to identify what are the better mechanisms to influence change, to produce change? They might be technical, they might be technically implemented, they might be technically led, and they might not.

    So, here’s where training—and I’m shamelessly plugging, her, the DevOps Institute, this is where a lot of the skill up type of initiatives that organizations like the DevOps Institute also promote and enable. There is skill up, there is education, there is cultural changes, there is many, many ways in which you can act. And, as you point out, Mitch, which is really, really spot on, you will need—you want to constantly measure. And in terms of constantly measuring the impact of these changes, you need to reassess, and it’s a constant, ongoing effort, whether it’s every year, whether it’s every six months, whether it’s more often, I think it depends on the state of the organization and kinda what they’re experiencing at this point, what they’re going through at this point.

    But I think it should never stop, because it’s continuous improvement, so you want to constantly renew this perspective of where you are.

    Ashley: Well, let’s talk a little bit about—so, how would one go about doing this? Do we visit the DevOps Institute site and that kinda helps us get the process started, maybe we have a partner, one of your organizations already, or maybe we need help in selecting somebody to help us go through the process? I assume there’s resources available on DevOpsInstitute.com, is that correct?

    Murillo: I think that’s correct. I think you can go and see all the different partners that are offering this tool, and you can basically look them up. That’s what I would do, look them up, see what their specific areas of expertise are in addition to the tool, where they’re located, and get a sense of who might work best for your organization. It’s a tool that, I think a lot of the value of the tool revolves around it being introduced by a partner that can lead the way. It’s sometimes difficult to gauge when you’re too close, right? So, go to DevOps Institute and look for a partner.

    Ashley: And it’s a global activity, right, as represented by both of you.

    Gonzalez: Yeah.

    Ashley: We were talking U.S. and Panama, and I forgot where you were.

    Murillo: I’m based in Costa Rica, yeah. My [Cross talk] is actually not based in Costa Rica, so we sell to the U.S. market.

    Ashley: I see.

    Murillo: But I’m in Costa Rica and I speak Spanish, so if you want some Spanish support, you’ve got two people here that can give you that guidance.

    Ashley: Exactly. Well, very good. We’re running out of time, unfortunately. We could talk about this all day, I’m sure there’s some really interesting things and, as you do this with organizations, you know, you carry that knowledge with you to the next customer, too, so there’s benefit in working with you as you go through this process, because it—

    Murillo: Oh, and Mitch, you bring something up—real quick, before we go.

    Ashley: Mm-hmm.

    Murillo: There’s something unique about the Assessment for DevOps Capabilities, and that’s that the body of knowledge that was used to produce this tool is directly extracted from the real world experience of, I don’t remember the number, but it’s dozens of actual DevOps practitioners, the DevOps Institute’s own Ambassadors and other partners, I think there’s tremendous value in that. It gives a collective perspective, a joined wisdom that I think is encapsulated in the tool.

    Ashley: Mm-hmm, yeah. It’s far from an academic exercise, right?

    Murillo: Mm-hmm.

    Gonzalez: Yeah.

    Ashley: Developed by DevOps people for DevOps people.

    Murillo: Exactly.

    Gonzalez: Exactly.

    Ashley: Well, it’s been a great pleasure talking with both of you, Leonardo and Ulises, and I wish you the best as you work with organizations and use the ADOC tool, and we’re looking forward to seeing some great impact and help that you can help bring to their organizations. Thank you for joining me today. Great to talk with you both.

    Murillo: Thank you, Mitch.

    Gonzalez: Thank you so much, bye bye. Ciao, Leonardo.

    [End of Audio]

  • Application Security and Continuous Observability with DeepFactor

    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.

  • Security Policy Management and Hybrid Cloud with Tufin

    Security Policy Management and Hybrid Cloud with Tufin

    In this TechStrong TV / DevOps Chats interview, Colby Dyess, director of cloud product management at Tufin, joins Mitch Ashley to discuss security policy management across hybrid cloud, multi-cloud and cloud-native security. Recorded in late 2020, Colby shares some experience from working with customers during the rapid migration to the cloud in 2020.

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

    TechStrong TV Video

    DevOps Chats Podcast Audio

    Transcript

    Mitch Ashley: I’m joined today by Colby Dyess who is director of cloud product management at Tufin. Welcome, Colby. Welcome, it’s good to be talking with you. Would you introduce yourself, tell us a little bit about you and of course, tell us about Tufin.

    Dyess: Yeah, well, you’ve got my name and my title, so I’m dialing in here from beautiful Southern New Hampshire where it’s fantastic weather. So, I’ve worked for Tufin Technologies, Tufin is really well known in the industry for providing security policy management, mostly in the organizations like the Global 2000 complex environments where you need to make changes to the network environment and you need to be able to do it quickly, safely, ideally you do it automatically and it’s secure. The Tufin product suite helps organizations do that and we’ve done that in the traditional space. Of course, our customers have adopted cloud, cloud native platforms, Kubernetes, and we’ve been taking these same capabilities for securing the environments and bringing them into the cloud, so no matter where you put your workloads, we can help you, and that’s mostly what we’ve been focused on.

    Ashley: Good stuff. Boy, the center for the universe for a lot of folks. Kinda speaking of that and just thinking about the timing of where we all are, you know, there’s a lot of statistics. I run an analyst firm as part of MediaOps organization called Accelerated Strategies Group. Anyway, we have a lot of data showing some of the acceleration that’s happened, both in digital transformation and also move to the cloud, just in the last six to nine months. I don’t think that’s news to anybody, right? I don’t know if you need data to say that, because it’s happening probably in most people’s organizations.

    Dyess: Right.

    Ashley: If I put on my security hat for a moment, we always get plenty of notice when we’re making changes and doing new projects and accelerating stuff—sarcasm—so, I’m sure there’s a lot of security folks who are scrambling still just to not only keep pace, but make sure we’re all doing a good job of securing environments that our developers are taking this into, making sure we’re understanding the services we might be using now that we weren’t before, cloud services that we’ve been in. I’m sure you’ve seen a ton of that happening with your customers.

    Dyess: Yeah. It’s no surprise. Organizations have been moving to public cloud environments for a long, long time, at least, technically, for the past 15 years, they’ve been doing it, but it hasn’t always been sanctioned, right? Let’s say over the past five or eight years, organizations have really begun to intentionally adopt the cloud. And now this year, of course, everybody’s moved to the cloud about as quickly as they could.

    What we’re seeing, at least what I’ve seen a lot is, security is now scrambling to try and get ahold of some visibility—what’s really going on inside these cloud environments—and trying to put some sort of guardrails around the services that the Dev teams are using. That’s a real challenge because they’ve been focused so much on how to secure most of the on prem environment or use firewalls to protect the cloud space, but now they realize they’ve got to go a bit deeper, because the threats are pretty real out there and they’re really dynamic. And if you’re not sure how to secure the cloud environment, you’re going to leave yourself open to threats.

    So, security has really been spending a lot of time trying to learn more about cloud and cloud native security controls. We spend a lot of time helping customers figure out the difference between cloud native security controls and on prem stuff and then how to combine them so they can be assured it’s all secured. We see that a lot, yeah.

    Ashley: Well, you know, I mean, we’ve all been doing firewalls and intrusion prevention and access controls and the list goes on.

    Dyess: Yeah.

    Ashley: So, the topics aren’t new, but the environments are different and the services. It’s not like you can go into the cloud—no, let’s use all the things I’m normally using in my on prem environment. Maybe you can get some software versions of that. Sometimes it’s just better to use because it’s better integrated, you spend less time making the environment work by using what’s provided by the cloud provider.

    Dyess: Yeah. That pattern is the same everywhere. I’ve seen that you’re gonna go to a new environment, you wanna take some of the things that have worked for you in the past and carry them forward. And a lot of times, that makes sense as you try to move quickly into the cloud. If you’re not familiar with cloud native security controls, you probably think, “I’ll just use firewalls and the process for managing firewalls in the cloud.” And there are a lot of options to do that, a lot of the traditional vendors in that space have tried to make a pivot to offer their same services, same capabilities in the cloud environment. So, it’s no surprise that we see a ton of that.

    At the same time, those processes around managing all that stuff still takes too long. If you moved to the cloud, you went there for agility, right? You want to rapidly build applications and get them out into the market as quickly as possible. But if you’ve got to fill out a ticket to get a firewall changed and it takes three days for that stuff to be processed, you’re no longer as agile as you used to be when you could twiddle a little configuration in a Terraform template, redeploy, and—poof, you’re up and running all over again. That’s something that security teams—

    Ashley: If you take another two days to answer that ticket, you’re probably gonna have a fourth after your third _____ while you’re add it to the mix, right? Some developers are gonna be like, “I’m outta here, let me go set up the next environment.”

    Dyess: Yeah, it’s too difficult. You can’t wait. You don’t want to see shadow IT any longer, because IT was taking too long to respond, but you’ve got to respect that IT’s there, the security site of IT is just really trying to help protect the business.

    But you know, you also saw Amazon and AWS, they both announced their own firewalls, right? Azure did a little bit back and AWS just did within the past month. And I think that’s really just paying homage to the fact that those are really good technologies. Firewall technologies really are good stuff and it’s more than security groups or NSGs, it goes beyond that, and the businesses really need these. These do address customer problems. So, we’re seeing a lot of folks ask about how do they adopt those new to the cloud provider, new technology, and how do they integrate them into the very agile processes? And I expect we’ll see a lot more of that.

    In fact, what we are finding that we do often is try to help organizations see how they can get the most value out of the cloud native security controls, because these cloud environments are really, they’re pretty solid. And like you pointed out, the security controls are integrated into the services. So, it makes a lot of sense to use the services, they’re there to protect your assets and they’re so integrated in the services, you really should be trying to use them, but it’s a learning curve for security, so it means a lot to try and help them get the visibility and then start to affect control over that, so that they don’t have to slow down the rest of the business, swapping out, let’s say, a cloud native control with a legacy control [Cross talk].

    Ashley: Mm-hmm. It is that tradeoff, and I think that’s one of those where it’s sort of, I think it puts security teams in a position where, are we gonna stick to our guns of this is the environment we’re gonna have consistent across all of the environments we operate in, or for sake of speed but not sacrificing security, maybe we do look at some other options and can those integrate into the monitoring and management systems as opposed to using the same firewall in every environment that we take with us there, right?

    Dyess: Yeah, yeah.

    Ashley: Easier said than done. I appreciate it’s not an easy job.

    Dyess: Right. You know, whether you decide to use the cloud native security controls or use the traditional kinda controls, the virtualized versions of those or a combination of them, one thing I think we’re sharing is, we see a lot of conversations around how—which technologies to adopt and then how to actually manage those technologies.

    And from my point of view, it seems like we’re almost too focused on getting down into the weeds about the specific security control and, as a security person, I think it makes a lot of sense to step back a little bit and try and focus on what’s the overall security policy. Instead of thinking what firewall should I use, should I use one from the cloud or should I use from my traditional vendor, maybe a better question to help organizations remain agile is for security to be able to focus on what the security policies are, what the guardrails should be, and then begin to get the practice of checking cloud environments against those guardrails, against these policies as part of your CI/CD pipeline, the whole buzzword of shift left.

    That’s a real thing, right? That’s really important. That security can focus on defining security policies where they have the strength, but the actual implementation of enforcing the security policy is probably handled by the cloud operations or whoever actually twiddles the bits on the security controls. Like, if you can marry those two things together and you can do it in the CI/CD pipeline, then that’s a huge win.

    We’ve seen organizations move a lot faster because security focuses on what they do and they get it codified in a way that can play in a pipeline, and now the app teams, they can make changes to an application or a cloud Ops can change the configuration of an environment and get an alert saying it doesn’t comply with the security policy. That’s great. To step away from choosing which sort of security device you want to use and focus on do things comply with the security policy? That’s a major shift, and one that seems to be really hard for organizations to do. I think to kinda get away from security being hands on with the control and now focused on the policy—it’s trust but verify, I think.

    Ashley: [Laughter] Back to that old saying, right?

    Dyess: Yeah.

    Ashley: You know, in a way, it also comes down—you know, we’re used to, let’s first take an inventory and make sure we know what’s all out there that we’re trying to secure.

    Dyess: Sure, of course.

    Ashley: But it’s equally just as important to have, whether it’s change management practices or software that can help you with notifying when changes occur or understanding, so when a change occurs, how does that map back to policies that we have in place and are we still in alignment, are there gaps that we have to take care of? Because the environment isn’t—it isn’t an environment we control everything in any more. It changes by itself, because other people are changing it along with us. So, it seems like it’s a more dynamic environment than maybe what we had 10 years ago, if you reflect back a bit.

    Dyess: Intentionally more dynamic, right? Businesses have to move faster, we also have to react more quickly to customer demand or competitive threats or whatever. So, the fact that we’ve got these dynamic environments is just a reflection of what we actually needed to have built, anyway. And now, we need to find a way to incorporate that back into our regular practices.

    So, you made the comment about being able to track what’s changed and when and all that, but if you adopt more of an infrastructure as code model, you already have that. You don’t need a CMDB—maybe you do, but you don’t have to have a CMDB in place when you could go back to your Git logs and see, oh, here’s the pull request for the change that we made that allowed for this security group to be open or for this Azure firewall to have this particular rule. You can actually see that information, but these are, on the security side, these are new tools. As a security person, when was the last time you looked into a Git repo to see what the configurations were? [Laughter]

    Ashley: The repo—right, GitOps and security, right?

    Dyess: Right. Right, but we’ve got to get somewhere around there, as a group collectively, whether we’re writing the code or we’re managing the operations or we’re managing the security collectively, we’ve got to be able to collaborate and use these tools that I can’t say are merging, they’ve been around a long time. Terraform and Helm, Ansible, Chef, Puppet, the whole bit—these things have been around for a while, but to incorporate them now into our security practices is a pretty big leap for folks.

    Ashley: Mm-hmm.

    Dyess: So, we really try to encourage that the security team gets the visibility that they need, that’s the first thing, as you pointed out, right? You absolutely need to understand what’s deployed, what’s talking to what and whether or not things are properly segmented.

    You’ve got to first get that visibility, but I think before you start jumping into let’s throw a bunch of other control points in there, consider what resources are there and how can you, on the security side, participate in automation, participate in these flows that your CloudOps, DevOps, SRE, whomever had set up. Because there’s a really good opportunity now on security to be part of this agile process and to allow the business to be secure, but to do so in a way that won’t break the developer productivity.

    Ashley: Mm-hmm.

    Dyess: And that’s, it’s uncomfortable, because it’s a big change, but it’s a change that I know it can be done successfully. We’ve worked with companies that have done that, you know, make the conscious decision.

    Ashley: I almost wish we had stepped back and redefined shift left, because if, you know, I were king of the world for a nanosecond, I would think about it as, it’s not just about getting security people to work with the software teams earlier in the life cycle of software—yes, it’s that. But think about it this way of, the old world was, set the policies and then how do we implement the enforcement mechanisms, right, to make sure that those are being followed.

    Dyess: Mm-hmm.

    Ashley: I think in the world we’re in now, it’s, security people are, if you were gonna set up a security practice in an organization today, what I would do is, let’s start with how software is created, let’s work with the team about how the entire tool chain is set up, how that flow happens, both for application software, but also for the infrastructure and how that gets created where we’re talking about test environments and production environments and maybe you’re stepping into infrastructure as code if it really, truly is kinda dynamic Terraform or whatever kind of environment.

    But start there, because if you understand how that’s done, now you know how to secure it. You know how to work with teams to help them secure it, then the next layer would be getting into the software architecture itself around microservices and things that are more porous than we’re used to, kinda the hard outer shell of monolith applications of the past.

    That, to me, is the mental shift, the big mental shift for a security team to not necessarily be an expert at all that stuff, but understanding that’s what you’re really securing now.

    Dyess: So, two things that stand out, like responses I can imagine people having right now and that’s, I don’t have time to go and learn all that stuff. [Laughter] I’ve already got 20 other tickets for all high priority things. I’ve gotta get on that right now, so I can’t go and learn all that stuff. Valid, that’s definitely the case in a lot of organizations, yeah.

    And another problem related to this is security teams who maybe do want to know, maybe have some time to do that, but struggle that the application teams themselves don’t even know what makes up the application and what connections do they need. So, even the folks who you think would know because they built it, you’d think they would know the answers to some of these questions, but it turns out that they don’t—in a shockingly large number of scenarios, that’s the case.

    Ashley: Mm-hmm.

    Dyess: And so, if you’re gonna shift left, you’ve got to address not just the problem of the security team getting visibility in this—or maybe, actually, it’s the same thing. The application teams have to be able to come to the table to say, “This is what the application looks like. Here’s how it’s put together. Here are the resources it needs and here are the services that will rely upon it.”

    Ashley: Mm-hmm.

    Dyess: And so, if application groups can come to the table with that, then a security team can look at it usually very quickly, look at a map and say, oh, I can see where it needs to be segmented this way. I can see where he’s a resource that has too close of an access to PII, PCI, right? And so, that conversation could start a lot sooner if it’s part of your normal bill practices, you were generating these views, you had some way to produce an item that a network team or security team could look at, right? They don’t need to look at the source code, they need to look at your network topology, they need to understand what you’re connecting to.

    So, if you can bridge that gap, that goes a long way. So, to your point, it’s not just like, “I just need to check if it doesn’t comply with the policy.” Sometimes, it’s even just trying to define the policy at the outset.

    Ashley: Yeah, on what you’re trying to secure.

    Dyess: Yeah, but also, while security never seems to get the heads up about the things that are coming down, the joke that you made at the beginning, it’s also the case that when the application team is building something that they don’t really have all the rules, they’re not sure what all the restrictions are, and there are certainly plenty of guardrails, guidelines that they could have if you give them access that they could pull from an API to do their own checks.

    So, you know, there’s a model. We’ve done this before in the industry, back when I wrote code, we had a separate QA team, so we’d write code, we’d do a little bit of testing, but just enough, frankly, to get us through the build, right? And then we throw it over the wall and it went over to QA. And then thankfully, our development practices matured to a point where we realize we actually need to integrate testing as part of what we do. So, as developers, we had to own some of that testing, some more of the testing, but also importantly, the test team got involved earlier in the application life cycle, the model you were talking about. So, the QA teams could come in and learn a bit more and begin to set up some of the additional tests and participate in the build process, so what they did showed up in NMake.

    So, I think security is on a path like that as well. I think security, instead of app teams just throwing it over the wall and asking security to figure out how to lock it all down, I think we’re going to, and in some places, some customers for sure are moving to a place where security is part of the process earlier, and if they can say, “Here’s some of the tests,” so now the guardrails, they can contribute some of that and they can go into this build process, then now you’ve really begun to get that shift left.

    But I know this can happen. We’ve seen it happen before. Now QA is just integral to what we do. You can’t even imagine putting a product out without some part of QA being part of the build process and tests happening really early on, test planning happening early on. I imagine security just going in that same sort of loop.

    Ashley: Yeah, of course Tufin’s been in this space for a while, has built up, I’m assuming, a body of knowledge about this. If you were gonna advise maybe a new customer or an existing customer on—okay, we’re always playing catch up, we’re really playing catch up now with how much more cloud services that organizations are using in such a short period of time, what are some of the sort of best practices or recommendations of, “Here’s to sort of get the first thing established, here’s the next thing to work on, here’s the next thing to work on.”

    Dyess: Yeah.

    Ashley: Any suggestions about that?

    Dyess: Sure. We have this whole crawl, walk, run methodology, and it’s designed to help organizations take these small steps towards getting to really secured environments. And the first step right away is just to get visibility, which is kind of a “no, duh” statement, but it’s actually one of the big problems that orgs have. You’ve got to be able to see what’s deployed inside your cloud, what’s deployed inside your cluster, and which resources are communicating with each other, where are the dependencies.

    So, understanding that is a really major first step. It’s true for the application teams, but for the security, it’s to know are things properly segmented, where are the biggest risks? So, getting that awareness, that’s really the crawl phase. And in the walk phase, that’s where you take what you’ve learned about what’s deployed, what talks to what, and whether or not things are segmented properly and then you begin to isolate. Here are specific accounts that we need to tackle or here are clusters that we need to tackle—like, hone in on the higher priority items and begin to define a security policy for those cloud native environments.

    And as you develop the cloud native policies, which you then share with the application teams or the cloud operators, whoever’s responsible for configuring it. As you develop that sort of, that skill, you’ve gotta get to the run phase, and the run phase is when you begin to automate this. You automate generating security policies, you automate validating security policies, but at the very beginning, where most organizations are at right now is, first get the visibility and then the second step of defining a security policy. Not defining what is my security group definition, not defining what is my AWS firewall definition, but what is my security policy? What are the rules that should govern access to applications, assets, resources of certain categories? Those are two big steps to take right away.

    Ashley: I think that’s some great advice. I’m curious, any thoughts as we—I think we all want to turn the page on 2020 and kinda get to 2021, and hopefully, we’re looking at a different kind of a year. But one of the things about 2020 is, we’re not gonna go back, I don’t think. We’re not gonna go back to, let’s rewind to January and start working in that environment again, right? Everything is changed with remote work or how much we’re using the cloud.

    What are some things that you’re anticipating for 2021 as you look forward in the next 6 to 12 months. Do you kinda think it will be topics maybe not as talked about yet but will be more topical in 2021? I’m just kinda asking you—

    Dyess: Are you asking for predictions of 2021?

    Ashley: You know, I don’t see it, but I’m pretty sure, there might be a crystal ball right behind your chair, just look back a little bit there and kinda check back. [Laughter]

    Dyess: [Laughter] Well, I think, given the maturity of the market adoption of public cloud environments, I think we’re going to see more security teams getting their arms around how to help in securing these cloud environments without necessarily always relying on the traditional devices. We’re already starting to see that even now. So, I think we’ll see more of the cloud native security control adoption. I know organizations have seen the benefits of doing that to lower cost of operations, just total lower cost of ownership, plus the benefit of being able to say when there’s a problem, I can call my cloud vendor, I don’t have to worry about vendors poking at each other. So, I think we’ll see more of that.

    I think it’s the Kubernetes space that’s probably the most interesting, because it’s the least well known for most folks on the security side.

    Ashley: Mm-hmm.

    Dyess: So, I’d say maybe over the past year, there’s been a lot of emphasis, just like with cloud, slap a firewall on it and we’ll solve the problems of micro-segmentation later, but later is gonna happen real quick, and I’d expect in 2021, you’ll see securities start to get more involved in getting visibility into the clusters and then looking to define the security policies.

    And not—again, not to try and define the policy of an individual cluster, but just the general rules, because there’s no way we can keep up with what will really be thousands of services running inside of a cluster.

    Ashley: Yeah.

    Dyess: So, we’ll see that. I think we’ll see more organizations at the security side have to deal with the scale and the rate of change and begin to participate in the automation processes that the Dev teams are using to manage it.

    Ashley: Maybe that’s something we’ll hear more frequently. I wouldn’t be surprised if the—let’s think of it as cloud native security, not just as security, sort of think about it as one of you architectural approaches to how you do security.

    Dyess: Cloud native. The native controls of the cloud provider—yeah, that’s a big shift for folks, I think.

    Ashley: It is. We’ll see if something like that happens. And I think the things you said made a lot of sense. Well, it’s been great talking with you, it’s the first chance you and I have had to talk before, and—

    Dyess: Yeah, it was good to talk to you, Mitch.

    Ashley: – a lot of fun. Tell us a little bit about where folks can learn more about Tufin.

    Dyess: Yeah, of course, you can go to Tufin.com, that’s T-U-F-I-N dot com. On the cloud side, like what’s really relevant to what we’re doing here, we’ve got a lot of resources at Tufin.com/try-securecloud. It’s cloud native security controls. It’s really designed to help you get visibility and control the cloud native security components. Great stuff there, free to use product. There’s a great trial for people to give a go. Tufin.com would be the place.

    Ashley: Great. Perfect. Thanks. Well, we wish you the best and a even better 2021, we’ll look forward to that.

    Dyess: Yeah. From your lips, man.

    Ashley: [Laughter]

    Dyess: Good luck in 2021, everybody.

    Ashley: There you go. Hang onto that, hang onto that. Alright, well, take care. It was very nice talking with you, Colby—Colby Dyess from Tufin.

  • Open Source and the Mainframe with Rocket Software

    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.

  • TechStrong TV: How to Build and Refine Your DevOps Skills with OpsCompass

    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.

  • The Use of Open Source in Mainframe Environments

    The Use of Open Source in Mainframe Environments

    Open source is a critical element of IT computing. As companies modernize the mainframe and start to add components to mainframe applications that are off the mainframe, they should to be able to build, test and deploy the components of that application that go across the mainframe and different computing platforms in the same manner. Organizations need 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.

    Tim Willging, chief architect and strategist, and Peter Fandel, mainframe open source evangelist of 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.

    The video 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 correctly, 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, oh, 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.

    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 open source 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 open source. 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, open source 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 ten 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.

  • Managing Data Risk in 2021

    Managing Data Risk in 2021

    You can’t protect your data if you don’t know where it is stored. The first thing to consider when creating a risk-based approach to data protection is the ability to identify and prioritize data, and control who has access to it. But, how do we do this? How do we prioritize data?

    In this TechStrong TV episode, Ron Bennatan, senior vice president and general manager of data security at Imperva, joins Mitch Ashley to discuss privacy, compliance and managing data risk in data lake environments in 2021.

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

    Transcript

    Mitch Ashley: I’m very happy to be joined by Ron Bennatan, who is GM of Imperva Data Security. We’ve talked before—Ron, it’s good to be speaking with you again.

    Ron Bennatan: Hey, Mitch. Nice to see you again.

    Ashley: As always, yes. Data and security—two of my favorite topics. [Laughter] Welcome to 2021.

    Bennatan: Yeah, 2020 finally is over. [Laughter]

    Ashley: Ooh! You know, it takes a pretty big rearview mirror to look at that, but I’m not sure I wanna look back too much. [Laughter] Well, we’re gonna be kinda talking about looking forward into this new year. First, would you introduce yourself, tell us a little bit about you, and also a little bit about Imperva?

    Bennatan: Yeah. So, Imperva is kind of the market lead for data and application security. We secure all paths to data. So, it kind of straddles between both covering how data is accessed and where data is accessed, kind of covering everything regardless of on prem and cloud, hybrid cloud.

    Ashley: Mm-hmm.

    Bennatan: And I am the GM for the data security side, and really glad to be here.

    Ashley: No small problem you’re solving. [Laughter] Data is everywhere, you know?

    Bennatan: One problem, yeah.

    Ashley: [Cross talk] data. At least not very many of ‘em. So, let’s talk about it. I mean, you know, we have the whole government breach in 2020 Russia—you know, Russia, Russia, Russia, that whole thing.

    Bennatan: Yeah.

    Ashley: It certainly brought a lot of attention to supply chain attacks. Of course, you know, that being an intelligence brief, it’s collecting a lot of data, right? You know, that could, of course, happen on a—it is, did happen on corporate networks, it could also be for financial gain; it doesn’t mean it has to be a national state attack. So, I imagine that’s gonna be a—supply chain is a word we’re gonna hear a lot about this year.

    Bennatan: Yeah, I think so. I think, you know, as a, just an individual, my fear, by the way, is—you know, there’s a really big project coming for the entire world, which is the delivery of the vaccines, and that itself is a supply chain. I just hope nothing messes up there, you know? Like, you know, knowing that whatever vaccine you’re getting is actually the valid one and not—you know, there’s a lot of…everything is in data and everything at the end sits in some kind of a, like, what’s the lineage of something? What’s the providence of something?

    Ashley: Mm-hmm.

    Bennatan: You know, it doesn’t necessarily—you know, we in the data governance area talk a lot about providence and proving the correctness of data, but you know, it goes all the way to the vaccine as well. So, I think this issue that we’re seeing, whether it’s breach—breaches get headlines, okay? And, you know, so this SolarWinds thing gets a big headline, the thing that these attacks on MySQL with ransomware, that gets headlines. But really, the bigger issue is getting control of our data and creating kind of a complete risk oriented approach, not just plugging a hole here and plugging a hole here and plugging a hole here. It’s—that’ll never work, right? It’s much easier to create a new hole than to plug all the holes.

    Ashley: The whack a mole strategy. “Here’s another mole to whack.” [Laughter]

    Bennatan: The whack a mole—yeah, the whack a mole doesn’t work. Whack a mole doesn’t work. And especially today when the complexity of the data environment is so much greater.

    Ashley: Mm-hmm.

    Bennatan: You know, 20 years ago—okay, 40 years ago, we just had some dashboard on the mainframe. Twenty years ago, we just had Oracle sitting on some Unix server. Today, it’s such a complex environment, data moves from place to place, you know, you look at what a data lake implies. It’s no longer a single stack, it’s a combination of stacks. Whack a mole doesn’t work.

    Ashley: Mm-hmm.

    Bennatan: So—and most companies understand that. Most companies are in this process of investing in a non-whack a mole approach, in a risk based approach that says, “Okay, I need to know where my data is. I need to prioritize which. You know, not all data is created equal. I need to scan, I need to understand, I need to know who has the ability to access something. I then need to know who is accessing something. I need to control what they’re accessing.”

    So, you know, I think there’s a better understanding that whack a mole doesn’t work.

    Ashley: Mm-hmm.

    Bennatan: I think 2021 is still gonna be a transition year. I don’t think we’re gonna necessarily get there, but we’re gonna transition.

    Ashley: We won’t have universal enlightenment [Laughter] on day—

    Bennatan: It just takes time. I mean, it takes time.

    Ashley: It does.

    Bennatan: There’s a lot of data.

    Ashley: I wanna ask you about—you did a nice job of kind of outlining, you know, identifying what data you have, prioritizing it, access to it. One of the things that I’ve always struggled with is that second step. How do you prioritize? What are the things to consider? You know, there’s obviously sorta crown jewels of my business—this is the customer data or secret sauce or that kind of things, but is there a good sort of stratification of how to prioritize data?

    Bennatan: Okay, there’s a technical answer and there’s a human answer.

    Ashley: Okay.

    Bennatan: Okay, technically, there are very good ways to do this. It takes some effort, okay? You can—you really do this based on a scoring of a bunch of dimensions, okay? So, one dimension could be the sensitivity level of the data, okay? Another dimension could be, what is the impact if something happens, okay? Which—but the reality is that we’re all people, and people are driven by incentive, and incentive is not necessarily, doesn’t always necessarily create the right prioritization. It creates whatever prioritization the incentive is structured around.

    So, I’ll give you an example. A lot of projects going on around privacy—a lot of projects. Because it’s a very, it’s a relatively new thing, less understood, and people don’t always equate the fact that we have been doing the work, almost the identical work, we just didn’t call it privacy, right? We called it classification.

    Ashley: Mm-hmm.

    Bennatan: But when you look at what privacy implies, it’s the same, but very new terminology—different semantics, different terminology. So many people don’t start from an investment they’ve already done in the last five years, they start from scratch, and the incentives are created because there’s a new role in the company. There may be a new—you know, a data privacy officer, okay, and that person has certain mandates and they drive things top down.

    And so, I think that the reality is, prioritization is driven by the projects and the funding that these projects have, and they’re also driven by breaches, okay? Because breaches are very dramatic.

    Ashley: [Cross talk] response, right? [Laughter]

    Bennatan: Dramatic, immediately created. So, I think that the reality is gonna end up somewhere kind of in the middle where things are gonna be driven bottom up and top down and they’re gonna meet somewhere.

    Ashley: Mm-hmm.

    Bennatan: But it’s not terribly complex to create a good prioritization strategy, but it’s not trivial, either.

    Ashley: Yeah, you definitely have to put some thought into it, and it’s not a textbook exercise, right? It’s all contextual.

    Bennatan: Yeah.

    Ashley: What’s important to the business.

    Bennatan: And I think you’ll find in—I mean, my prediction in 2021 is that there’s gonna be a lot of, you know, privacy is not gonna just drive a lot of these from a compliance perspective. Okay, until now, privacy is really—you know, when a company embarks on these privacy and classification projects, or at least what I see from our customers, is that it’s driven a lot by compliance, okay? They need to comply with a CCPA, they need to comply with GDPI.

    Ashley: Mm-hmm.

    Bennatan: I think we might end up having also, like, an attack flavor, okay, around privacy, which is not intuitive, not necessarily intuitive. And it has to do with the fact that, you know, part of the mandate is, you know—so, say that I am, you know, year one of my consumers and you store, I store some of your data. That means I—you have the right to demand some things from me. Like, you have the right to demand that I delete you from my system.

    Ashley: Mm-hmm.

    Bennatan: You have the right or portability, you have the right to ask me what data do I own or do I store about you? And you can come to me with these requests, okay? Different terms, different subject rights request or data access requests. You know, you can easily think about what is the effort that I, as a big company, have when you ask me to do this? It’s not a small effort. So, okay, if you—now, the nice thing is, most people don’t do that, okay? I’ve never called somebody up and told them, “Hey, delete me, okay?”

    Ashley: [Laughter] No, I think that’s probably very much an exception—maybe a rare exception.

    Bennatan: Yeah, but what happens is some people realize that this is the way to cripple a company.

    Ashley: Mm-hmm.

    Bennatan: What happens if they organize and they say, “Hey”—

    Ashley: Or protest, right?

    Bennatan: – protest, you know?

    Ashley: Moving of Facebook onto whatever.

    Bennatan: “We don’t like you, let’s organize 10,000 of our friends and we’ll all hit them at the same time.” What do you think that’s gonna do from a work perspective? It’s pretty serious.

    Ashley: Yeah, I’m guessing it’s not just press a button—that’s gonna consume some resource at the company, people resource, things like that.

    Bennatan: Yeah.

    Ashley: You know, one thing I was wondering, too, is, with this year, there’s discussion now about do we need a national cybersecurity strategy, things like that, just to mention politics, the Biden administration is talking about working with other countries to establish sort of norms of what we do when it comes to cyber whatever with each other and what is considered an attack.

    It seems like that is—maybe not this year, but that’s certainly potential for regulation of those kind of discussions, whether it comes out of any national strategy or not or could be another country that says, “Okay, now we’re gonna take this to the next level.” Like, what is our position around data? Not just privacy, but if it’s compromised, then what happens to you as a firm? I mean, it could get kind of interesting.

    Bennatan: Yeah, it could. You know, I mean—again, we’re delving into, like, opinions and politics.

    Ashley: [Laughter] Yeah, I know.

    Bennatan: I’m not a fan of—I’m not sure that something like this could go that route. But I do think that it goes other routes. So, for example, like, I’m reading a book on kind of the history of the Mossad, okay, the Israeli intelligence service.

    Ashley: Mm-hmm, mm-hmm.

    Bennatan: And you can see—and whenever you read any of these books, you see that all of the intelligence community, they have back channels, right? They agree on things.

    Ashley: Right.

    Bennatan: So, to me, if we wanna have something like that, it should be, like, the cyber czar of the U.S. and some other—you know, the big players, they have to agree. It doesn’t need to be regulated, it doesn’t need to be at the politician level, it has to kind of stay at the—

    Ashley: Kinda behind the scenes with the cyber czar.

    Bennatan: Behind the scenes with the experts at the—but, you know, there’s definitely an issue with state nations, okay? This does need to be addressed. Now, you know, it’s not necessarily that every—you know, we always think that, you know, we’re the good guys, they’re the bad guys, you know?

    Ashley: We would never do anything like what they did to us, right? [Laughter]

    Bennatan: Well, you know, there’s examples in history, okay, of things. So, I do think this is coming. I don’t believe it would happen at a politician level, it will happen at the actual subject matter experts. And by the way, there are good examples of things that have happened like that, especially in the financial services community. I mean, for years, maybe even decades, you know, FS-ISAC, they work together to create some level of standards across investment banks or banks. These things work, I just don’t think it’s political.

    Ashley: Interesting. Well, I wanted to kinda tap your thoughts on that. I know I threw the line pretty far out there in the water, [Laughter] just to kinda get your thoughts on that.

    Well, let’s reel that back in a little bit and talk—you know, there’s GDPR and CCAPE for California. A lot of people are still in this, I think in this kinda implementation stage, even though we’re supposed to have those things all covered, right? Maybe a little farther along with the GDPR, of course, but is that something, this year, you think it’s—we’re in this, okay, let’s now institutionalize some of those things in the organizations and really take care of our knitting there or do you think there’s more things on the horizon that are gonna come at data people?

    Bennatan: I think it’s gone into an implementation phase, for sure—which is good.

    Ashley: Mm-hmm.

    Bennatan: You know, there’s a lot of things, many things are not terribly clear, by the way, even though it’s in implementation. I’ll give you an example, right, this notion of being—my ability to request that you delete me, okay? But let’s take something else, which is a different type of compliance requirement, which is for you to keep logs for a certain period of time, activity logs. There are a whole bunch of other compliance requirements that require you to do that.

    Ashley: Data retention requirements, yeah.

    Bennatan: Yeah. Okay, so—now, what happens if part of the activity logs has my identity in it and I request you to delete it?

    Ashley: Mm-hmm.

    Bennatan: Should you delete it, or should you not delete it? One, in order to comply with one thing, you should delete it. In order to comply with another thing, you can’t delete it, maybe for three years. So, there’s even things like this, which are conflicting messages. And at the end of the day, it’s going to depend on some level of interpretation.

    Ashley: Mm-hmm.

    Bennatan: Which, at the implementation level, I can tell you, I can see two approaches. One is—okay, this interpretation needs to be given by legal or it’s okay for the business to give the interpretation to that. So—and you know how it is. If it goes to Legal, it takes a longer time; if the business can make the decision, then it goes much faster. And I’m seeing more and more of this moving to the business, taking ownership, and making the decisions, in which case, it goes much, much faster.

    Ashley: Well, and oftentimes, it seems that that always happens with laws and regulations, right? There’s what it is and there’s the interpretation of it, and there’s sorta those middle tier organizations, the consultants, the larger firms to sort of establish the frameworks that, “This is our interpretation of it,” so if you do that, you’re sort of in the norm with what the industry is doing. Who knows if that’s the right interpretation or not? It’s always subject to change, but that’s usually where that help comes from, at least on the big thing.

    Bennatan: Well, yeah. I mean, it starts from there and then usually what happens or what it evolves to, which makes it really go much faster, which is what’s happening now is that if—and by the way, it goes back to your question about this nations coming together or an industry coming together. The minute you have some critical mass within a certain peer group and you say, I don’t know, maybe I’m an insurance company, if my peers have taken upon themselves a certain interpretation, I usually don’t even care where they got it from.

    Ashley: Mm-hmm.

    Bennatan: Maybe they got it from these consultants, maybe they didn’t. But if three big players in my industry are doing the same thing, I’m gonna do the same thing.

    Ashley: Yeah.

    Bennatan: And that’s what’s happening now is that, you know, I know the insurance industry well and I know the banking industry well, and I can see that they’re now, “Oh, we’re gonna do like them” and then it’s much easier to follow, like, a track that seems to be proven than to try to invent it. And that’s happening and that’s why I think there’s an acceleration for a lot of these things.

    Ashley: Yeah, I agree with you. That makes a lot of sense. What are your other thoughts about 2021? What are we gonna be thinking about that we didn’t realize is gonna be on our radar for this year?

    Bennatan: I think we are going to kind of understand this notion of, you know, look at the data from every way that you can get at the data, not try to—like, historically, there have been a focus on pillars or silos, which were more and more, or in the past were driven really by tool specialization, okay? Like—okay, I’ve got the DLP and I’ve got this and I’ve got FAM and I’ve got databases, and I’ve got big data.

    And today, the lines are so blurred, especially on the cloud services, they’re even more blurred that there’s starting to be a realization that we really need to look at all paths to the data and all ways to secure the data and look at it instead of individual silos, looking at it as, “This is my data fabric.” Okay, so you’re starting to hear things like, you know, data lakes, data fabric, data services, and the data service could be structured by different implementation stacks. But you’re no longer trying to secure each stack by itself, you’re trying to secure the entire fabric.

    Ashley: Mm-hmm.

    Bennatan: And it’s really the right thing to do. It’s the right way to think about it. It is something that requires a transition, because even organizationally, many companies had one group doing this and one group doing this and one group doing this. And this notion of, you know, looking at a single overlay control layer, okay, which can drive policy down or can bring things up is, you know, it’s time for that. And I think 2021 is gonna be, part of this year is going to be starting to deliver things at that level of abstraction, and it’s also enabled by the fact that there is technology that can kind of bubble everything up into one level, right? You don’t need to look at it as 20 different tools, you need to look at it as kind of like a federated layer, and at least it’s doable, right? Ten years ago, it wasn’t doable to do any of it.

    Ashley: You know, it’s interesting. What it makes me think of is maybe some norms that we’ve had for a while of thinking about data owners, and that sort of puts the blinders on of, now I create that vertical view of, “This is that data for that purpose for that business unit for that application or process, whatever it might be.” And what you’re saying is looking at it more systemically, right? The entire collection of data, and securing it, but also uses of that data and sort additional intelligence and things you can mine from it.

    It’s interesting—so much, as we continue to move more and more into the digital economy, digital world for how we operate, all of those digital activities generate their own data, too. So, now, we’re adding that to the fabric of the data of, you know, we have a lot more usage information, we have a lot more telemetry that we never had. You know, it seems to be expanding exponentially. So, our ability to even just fathom what’s there and how it’s—what uses it might have and how it might be correlated in new ways sort of boggles my mind. [Laughter]

    Bennatan: Yeah, yeah. And, you know, I mean, it used to be this—one of the things people used to talk about when they started building big data platforms was that, you know, until recently, we just, we couldn’t use our data. We just threw 97% of our data away, and now we don’t wanna throw it away, but you’re right, it’s a beast that feeds itself.

    Ashley: Mm-hmm.

    Bennatan: But yeah, I think it’s, I think looking at the risk profile of the entire thing and not cutting into separate projects, which then have no tie to each other, right? I mean, if you want to reduce the risk, you asked about prioritization. Okay, prioritization needs to drive everything, right? Needs to drive reducing service area, needs to drive access control policies, needs to drive audit. If you start separating each one of them, not only is it not very effective, but it means you’re working 10 times harder, because you need to do this many, many, many times.

    So, this notion of a single kind of data security platform which kind of can have this internal feedback loop and use whatever effort you’re doing, it doesn’t matter if your effort is driven by compliance or security or privacy, whatever investment you make needs to build into this platform, not do itself over the next time you do anything. Otherwise, we’re just wasting our time. We’ll never get done. Because you said the data’s growing exponentially—if we’re chasing, if we’re not leveraging what we’re doing for one purpose when we wanna do the next purpose, we’re gonna lose. It’s gotta be a single platform.

    Ashley: Well, and to your point, it seems that once you sort of make that shift, right, to that platform view of data, now you can apply that to how you look at the data across all sources, all uses, all former kind of vertical siloed—you know, you may still want to look at it that way, but it’s not like, “Okay, now we’ve figured it out for compliance, but we’ve gotta go start over to do it for something else for operational process or whatever.”

    Bennatan: Exactly.

    Ashley: No, it’s there, you kinda take that—

    Bennatan: Exactly.

    Ashley: – those same tools and look at the data, analyze it. Now you’ve got that capability to do that for lots of things.

    Bennatan: Yeah, it’s exactly—it’s exactly right. I mean, you know, it’s like, in the business world, there was always this notion of a customer 360 where, you know, what’s the point that I have one system for quotes and one system for support and one system for my policy and I never know what’s going on, and I can’t upsell, and I can’t cross sell. It’s the same thing in security, okay?

    There’s this notion of data 360, data security 360 where, if it’s there, you know, then prioritization becomes easier, right? If you can check your configs and your vulnerabilities, okay, and you get this huge list—what are you gonna do? But if you know that, of this huge list, your consumer data is here and that, you know, the crown jewels are here—great, you don’t have to boil the ocean.

    Ashley: Mm-hmm.

    Bennatan: And if, at the same time, you can bring in and you can check your entitlements and you can say, “Well, you know, I have this vulnerability, and it is important data, but I did a really good job at narrowing it down and access to it is only by these individuals and access is Kerberized and—I don’t know, and maybe I also regulate the policy very tightly—these are all related, okay? So, if you have that single platform, you’re in much better shape than…you know, it’s like, I’m trying to think of a metaphor of, you know, when you have a single viewpoint, that viewpoint may be wrong. When you have—it’s kind of like, you know, these days, this discussion about whether news means anything any more, because it’s so tailored to what you wanna hear.

    Ashley: Mm-hmm.

    Bennatan: But it’s kind of like somebody forcing you to go and watch Fox and CNN and NPR and—you must watch all of these before you make a decision. It’s the same way. We can’t reduce risk by just looking at one thing at a time.

    Ashley: Yeah, we certainly have our own selection bias and data as we do our news programming as well, right? [Laughter]

    Bennatan: Yes, exactly.

    Ashley: Well, this has been a lot of fun talking with you. I just have a sense 2021 is already off to a good start with vaccines and the COVID situation. Hopefully—

    Bennatan: Hopefully.

    Ashley: – you know, we’ll round that hump and folks can really figure out new ways of collaborating with each other without worrying about COVID. Maybe that day’s down the path not too far, but we hope, anyway.

    Bennatan: Yes.

    Ashley: So, it’s been fascinating talking with you. So, we didn’t talk about, you know, go into product stuff, it wasn’t that conversation, but tell us a little bit about where folks can find out more about Imperva.

    Bennatan: So, Imperva.com, we are—you know, if we’re talking about data security, then there’s a whole section there, and you’ll see that we’re investing a lot in, you know, things that we believe 2021 and our customers are implementing. So, a lot of kind of complete security, complete security, whether it’s for compliance, security, privacy—a lot of effort in privacy, a lot of effort around data lakes, everything around cloud. Any cloud that you can think of or any data service, any data-centric workload on the cloud is something that we’ve worked very hard with the cloud vendors to provide support for. And yeah, I think 2021 is gonna be an exciting year because of this modernization that everybody’s embarking on.

    And my hope and what we’re trying to do with Imperva is that the path of modernization for the applications and for functionality also brings with it modernization of security, updated security. That’s really what we’re working on.

    Ashley: I would definitely suggest folks check you out. In thinking about our conversation before of the response to regulation and policies and things like that of looking at what other leaders do, Imperva works with some very impressive companies who are solving the data challenge from a platform standpoint. So, there’s a lot of good reasons to check out Imperva, because there’s a lot of problems you’re solving on the advance that could help a lot of organizations, so I hope people will do that.

    Bennatan: Yeah. Well, thanks, Mitch. Always great to talk.

    Ashley: You bet. Good to talk with you, Ron, and thanks, everybody, for listening in. It’s been a great conversation, and I wish all of you a great 2021 as well.

  • Top 10 Common Software Vulnerabilities

    Top 10 Common Software Vulnerabilities

    An essential part of an effective software security process is being familiar with software vulnerabilities, which are flaws or weaknesses in your code. Often, testing and manual code reviews are unable to identify every single vulnerability, which can impact the performance and security of your software. For that reason, it is important to have a working understanding of software vulnerabilities as it will enable you to more effectively manage potential security threats.

    The top 10 most common security vulnerabilities are as follows:

    1. Insufficient Logging and Monitoring: Insufficient logging and monitoring process are dangerous as they leave your data vulnerable to tampering, extraction, or even destruction.
    2. Injection Flaws: Injection flaws can trick the targeted system into executing unintended commands as well as provide untrustworthy agents access to protected data.
    3. Sensitive Data Exposure: Sensitive data—which includes addresses, passwords and account numbers—must be adequately protected against human-error and security breaches to avoid potential exposures.
    4. Using Components with Known Vulnerabilities: Components—which are made up of libraries, frameworks and other software modules—are often run on the same privileges as your application. Which means if a component is vulnerable, those weaknesses can be exploited in an effort to access your application.
    5. Cross-Site Scripting (XSS) Flaws: Cross-site scripting flaws can be exploited by untrustworthy agents in an effort to execute their own scripts in your system.
    6. Broken Authentication: If authentication and session management application functions are implemented incorrectly, a software vulnerability can be created.
    7. Broken Access Control: If user restrictions are broken, it can create a software vulnerability that can be exploited.
    8. XML External Entities (XXE): In order to properly understand an XML data, an XML parser is necessary. However, if the parser is poorly configured and the XML input that contains a reference to an external entity, it can provide a flaw that an untrustworthy agent can exploit.
    9. Security Misconfiguration: Security misconfigurations are often brought upon for numerous reasons, including: insecure default configurations, incomplete or impromptu configurations, open cloud storage, misconfigured HTTP headers and wordy error messages that contain sensitive information.
    10. Insecure Deserialization: Deserialization flaws often result in remote code executions, which enables untrustworthy agents to perform replay, injection and privilege escalation attacks.

    Prevent Software Vulnerabilities

    In order to efficiently and effectively prevent software vulnerabilities, we recommend the following best practices:

    • Establish software design requirements.
    • Use a coding standard.
    • Test your software.

    To read more, please visit: https://www.perforce.com/blog/kw/common-software-vulnerabilities

  • What is SAST? Overview + SAST Tools

    What is SAST? Overview + SAST Tools

    Static Application Security Testing Overview

    With the growing number of cybersecurity threats, you must ensure that your software is protected against potential vulnerabilities and threats. One of the most beneficial practices is to use static application security testing (SAST).

    What You Need to Know
    Static application security testing is a type of software test used for inspecting and analyzing code to identify security vulnerabilities. Software security tools — such as static code analyzers — scan your code as it’s being written to identify potential weaknesses, errors and bugs. These kinds of tools are invaluable to software developers, as they are able to detect the most prevalent and common software security vulnerabilities.
    How It Works
    In the simplest terms, static application security testing works by having a static code analyzer check your code for design and coding flaws that could make your software vulnerable to security vulnerabilities. During this inspection, the static code analyzer will identify security issues, including programming errors, unsensitized input processing and vulnerable constructs.
    Problems That It Solves
    In general, static application security testing has been designed to solve three main software development problems:

      1. Detecting source-code vulnerabilities. The most significant benefit of using a static application security testing tool is identifying software security issues early on in development when they are easier (and less costly) to fix.
      2. Eliminating late diagnostics. A common cause of massive technical debt is late diagnoses of problems in the source code. However, by using a static application security testing tool, you are able to easily diagnose the vulnerabilities and errors in your code.
      3. Enhancing root-cause analysis. With a static application security testing tool, you receive notifications that pinpoint the exact location of vulnerabilities and errors in your code.

    To learn more about static application security testing and how it can help ensure the security of your software, please visit: https://www.perforce.com/blog/kw/what-is-sast?utm_source=content-syndication-devops&utm_medium=content-syndication&utm_campaign=kwk-global-2021-wtl-demo&utm_content=what-is-sast