staging-devopsy.kinsta.cloud

Author: Mitch Ashley

  • Techstrong TV: Leveraging Low-Code Technology with Tools & Digital Transformation

    Techstrong TV: Leveraging Low-Code Technology with Tools & Digital Transformation

    Low-code is playing a big role in Henkel Corporation’s digital transformation by connect remote workers with 30 shop floors all over the globe. Catarina Pinto, Henkel Digital Transformation Manager discusses how the team leverages low-code technology to deliver weekly releases across ten apps. HCL Software AVP Product Management Andrew Manby shares the role HCL Volt VX is playing at Henkel and other customers’ digital transformation initiatives. The video and a transcript of the conversation are below.

    Announcer:                 This is Digital Anarchist.

     

    Interviewer:                Well, the really great pleasure being joined by two very fantastic people talking about low-code/no-code and some of the impact from digital transformation projects. First joining me is Catarina Pinto, who is the digital transformation manager with Henkel, and she’s – Henkel Corporation. She’s gonna be talking about their project and involve low-code and that has been taking place. And a repeat guest, returning guest sitting in the right-hand chair is Andrew Manby, who’s AVP product management with HCL Software. Welcome to you both.

     

    Interviewee 1:             Thank you so much.

     

    Interviewee 2:             It’s great to be back,  Mitch.

     

    Interviewer:                Welcome back. Well, let’s do this. Andrew, why don’t you briefly introduce yourself, and then, Catarina, I’ll have you do the same, tell us a little bit about Henkel, and then we’ll go right into talking about your transformation project.

     

    Interviewee 2:             Right, perfect. So my name’s Andrew Manby. I head up product management for our HCL Digital Solutions portfolio. My specific focus and passion is really about digital transformation and using low-code to do that, and our tool of choice here is Volt MX, our low-code tool for professional developers.

     

    Interviewer:                Funny, that’s our topic today. And then –

     

    Interviewee 1:             I think this is.

     

    Interviewer:                Yes, go ahead.

     

    Interviewee 1:             Sure. Catarina. I am, as were said, digital transformation manager here at Henkel. I’m based in Amsterdam and I mainly work with the factories, so my goal is to lead partly the digitalization of the factories. I’m responsible in leading a global project that is the Connected Worker, where we basically aim to augment our workers in the shop floor. One of the biggest parts in this program is the Connected Worker apps, and that’s made with Volt MX as well.

     

    Interviewer:                Excellent. Well, I’m sure that a lot of interesting things have been happening over the last 18 months plus. How long has this project, digital transformation project been happening? Has it been more related to the pandemic, or is this part of the bigger program that’s going on across the company?

     

    Interviewee 1:             This is part of the bigger program we have. It’s one of our core pillars in the company, and it has been in full force since I joined, so 1. years ago.

     

    Interviewer:                Great. So your part of the project, would you say that’s a big component of it or one of several?

     

    Interviewee 1:             In this moment is the strongest component of it, so especially the Connected Worker apps, but we have a lot of things going on in our factories. We have a very powerful digital backbone. There are plenty of articles out there, business cases out there in terms of our digitalization in the supply chain, especially in Laundry, where I sit in this business unit. And basically what we aim is to extend this super powerful backbone that connects our machines in more than the 30 sites that we have worldwide, and also give the extra information of the user, so the knowledge of the person that is operating the machines, that is making sure that products are with extreme quality, that is making sure that everything is safe in the shop floor.

     

    Interviewer:                Now, we talked about the project you’re doing and with remote workers to the factory floor. Is that people who are across all 30 of those locations generally? Is it more concentrated in certain areas, locations?

     

    Interviewee 1:             No, we have, we are a real global program, so whenever we deploy an app it’s for everyone. It certainly helped during the pandemic because there was less need for people to be all the time in the shop floor if they are not business critical, and you can still see all the information from far away about what is going on in the shop floor, and basically are establishing a new way of communication here.

     

    Interviewer:                Great. And are you most of the way complete with this project? Are you still in the sort of early throes of it? Where are you at on your journey for this particular initiative?

     

    Interviewee 1:             So I would say that we are certainly in the scale up phase. So imagine this as a mini startup within the company where we see in the shop floor what are the processes that we can digitalize, so basically everything that is done in paper we will try to create an app or incorporate in our ecosystem so that we allow this information to be part of our data lake and really have insights from that. So we will work on everything from designing the product based on customer needs, so a lot of needs finding that is out there. Product design is also on our feet. Then we do the development with two teams of developers in this moment that we have, one in Cairo, one in Serbia. And then we also lead the implementation within the factories, so it’s a big project with a lot of scoping and that really hits all the parts of the factory, be that continuous improvement, be that safety, quality, and other departments that we are also thinking about expanding to.

     

    Interviewer:                Yeah. Mission critical for sure. So let’s talk a little bit about the role of low-code and the tools that you’re using, obviously Volt MX being one of those. And I know you’re here not as an endorsement necessarily, but clearly you’ve partnered with HCL Software and they’re playing a role in this also. Is low-code type tools, is that something relatively new to Henkel, or have you been using those types of tools for quite some time?

     

    Interviewee 1:             So they are relatively new, since the project started I would say, but it was super important for us because we really wanted to be very quick to market. And since the beginning of the project we kind of work like an Amazon company would do, so our goal is to get products that are unfinished into the shop floors, so MVPs, and make sure that we kind of use it as a playground with the people in the shop floor to get real user needs, to make sure that it’s customizable to 30 locations. So it’s really important for us to be not only fast in getting the MVP, but also fast in getting the feedback introduction of our people. So we are very people based, very customer obsessed. We really did this very big mindset shift in terms of it’s not creating the whole product and then shipping, but delivering that iteratively with the people that will use it in their day-to-day, and here low-code plays a very important role because it allows us to be very fast in getting to the market needs.

     

    Interviewer:                Yeah, a very lean approach doing MVP, rapid development iterations of your releases, so totally, that’s a great use of low-code type technology. Andrew, are you working directly with Catarina on this in the organization, or kind of observing as part of the HCL team from a little bit more distance?

     

    Interviewee 2:             I would say observing more about what they’re doing, and I think there’s a good interchange between our people in Europe working with Catarina and her team. We want to invest in some future innovation things that they’re looking at as well, and to bring those and help Catarina. Because I think part of the value that I hear from customers is us coming to the customer and saying, “Well, we’re sort of seeing these trends. How do they apply to your individual business?” And then take them through a period of exploration to really try and understand what is your digital vision? Now let’s get concrete on a specific area, and how does that innovation really help?

    I think in terms of Henkel, they are a leading innovator in digital transformation. I mean I, given the types of things they’re doing, they’re very data centric and very outcome oriented, and I think this initiative dovetails. But what delights me about what some of Catarina’s point of view is very pragmatic, but it’s – I think one of the things that you said, Catarina, is when you’re interacting with the people on the shop floor, you’ve got to show the value to them directly. Right? So if it’s – I was thinking about the expression you have. It’s not only simplifying their lives, but it’s as easy as paper. It’s got to be. Yeah.

     

    Interviewee 1:             Exactly. With our biggest competitor, so in the end it’s really difficult to compete with, and that was really a key, it plays a key role that we really have the interest of the people. And if people feel ownership in the sense, oh, I asked for this feature. Two days later it was there, it’s so much more important. They understand. And in the beginning I had to do a lot of push to say, “No, please give me your feedback. Bring me your problems. That’s exactly why I am here. I’m contacting you every day.” Until the problem today that is I get my inbox flooded with all the requests, and I don’t know where to turn to. But I think it’s much, much more – it’s a much better environment.

     

    Interviewee 2:             Yeah. So that’s actually interesting, Catarina, ’cause you’ve reached that sort of tipping point where it’s actually, instead of being push, it becomes a pull –

     

    Interviewee 1:             Exactly, and that –

     

    Interviewee 2:             – from the factories, which is tremendous, and I think you were also telling me where they’re actually saying now is, you know, we want these features and we want more iPads. Right?

     

    Interviewee 1:             Yeah, and that’s a big pull from the company as well, but I think it’s, I see it as a very positive insight into the program. Just building on the previous point, for example we are trying to build now a product, also app-based, but the idea is that it’ll be a company-wide product, so be for all the functions within the factory. And especially in the beginning I was a little bit unsure. I was thinking maybe this is too much. And then one of the factories just told me, “Hey, if you add these two little things, I can push this all over the factory.” Like okay. One week later, they were implementing in all functions, and I got, wow, that’s amazing. I didn’t even need to do marketing because their, it was one of their biggest needs, and we are really cooperating with HCL to really take this to the next level, and I think it will be a very awesome product.

     

    Interviewer:                What’s interesting is over so much time people have gotten conditioned when requesting technology applications, systems, you know, they don’t get what they want very quickly, at least they haven’t historically, and so I imagine it’s a big shift, a big mind – initially they didn’t expect you to be able to deliver as quickly as you are, and now that they are, of course, they flood your inbox. Right? Be careful what you ask for, too, right?

     

    Interviewee 2:             Yeah. Yes, exactly.

     

    Interviewee 1:             _____.

     

    Interviewer:                I’m curious, how many people do you have working on the project? And is this inside IT? Is this outside of IT? How’s it considered –

     

    Interviewee 1:             No, it’s inside IT. So we have in this moment four developers sitting in two places, two kind of scrum masters, say it like this. I act as product owner as well, so I have a lot of hats during the development of the products, so from end to end of the products, but that’s basically the core of the team. So very, very small team, and we really need – it’s like I said, like almost a mini startup, and we have ideas and we say, “Okay, find a way to do it. Let’s do it. Let’s put this into the ground and let’s make people happy with what we do.”

     

    Interviewer:                Are you doing sort of an agile two-week sprint type approach?

     

    Interviewee 1:             One-week sprint –

     

    Interviewer:                Are you doing more DevOps release it as it’s ready, it’s tested, it’s good to go?

     

    Interviewee 1:             In this moment we are doing one-week sprints, so really we – especially because we have a lot of apps simultaneously. So we have in this moment around ten apps that are part of our major ecosystem that all need some kind of maintenance or they have new requests from the guys on the shop floor, or I have new ideas that I want to implement. They are based obviously in customers’ feedback. So it’s really very, very fast. We don’t release in all of the streams of course, but we try always to be very based on customer requests and superuser centric.

     

    Interviewer:                So how would you say using low-code, using Volt MX low-code kind of tools, how does that – has it fundamentally changed your ability to deliver that quickly? Is it that revolutionary? Is it sort of an evolution of a journey you’ve been on to get to this point? How would you describe it?

     

    Interviewee 1:             I think it certainly helps, and especially with the connection with HCL that provides a lot of support so that we can also take advantage of this low-code product, that we can create things that are repeatable. Right? That we don’t have to reinvent the wheel every time that we build something. And here really the size of the market decreases, yes.

     

    Interviewer:                Interesting. And something Andrew and I have talked about is the citizen developer, the professional developer, inside, sometimes both inside IT, can also be external. Would you consider your team more of a professional development team as what people – that’s their jobs is being developers, or are these citizens, business people sort of performing the development functions?

     

    Interviewee 1:             In this moment a little bit more towards the professional developers here, because we really are not that big and we really have a lot of apps, so we really need to be a little bit more focused on that.

     

    Interviewer:                Interesting. I’m curious, Andrew, what do you see – you see some commonalities between things that are contributing to the success that Catarina is having at Henkel that you maybe have seen with other customers?

     

    Interviewee 2:             Yeah, absolutely. Yeah. I mean our focus, Mitch, is predominantly in enabling people like Catarina and Henkel with the professional development teams, and they don’t need to be big teams. I mean you can tell they’re a very agile team, a very responsive team. It’s very impressive to hear that. In our world, it’s really that idea if they’ve got the vision around the digital transformation and a willingness to be able to do that, we can help facilitate to do that very quickly with them, and I think it’s really that partnership. Sometimes that’s simply just being able to sit down, train, work with the customer, train them, build some prototypes, and sometimes it’s a little bit more of a discussion around a business process that they want to re-engineer. And we have a, what we call a studio process where we can bring them in, we can reimagine or think about what that would look like, build a prototype, and then get the feedback from the people on the ground about whether that would work. And sometimes either of those approaches works. it just really depends, I think, on the maturity of the organization.

    But what I also find interesting, which is embedded in what Catarina was saying about the only if you add that couple of thing, you know, we’re seeing that – we did a session recently with Jarrod from VELCO which is up in Vermont, the Vermont Electric Company, and they’re like the nation’s first purely distribution network, and they’ve got about 15 apps out there and they’re starting to think about how can they sort of consolidate some of those apps and build some super apps in the area of field service. So we’re seeing the folding in on some of those developments to go in new directions, but one of the impressions and the feelings I get talking to the customers, where they start and where they end up are two different places. I mean like the old adage, right? There’s always new ideas that come from customers that take them in different directions. In the case of VELCO, they have a scientific application which is part of the government reporting to say, you know, in times of hot temperature, what happened on the loading of the transmission lines. So that required them to integrate with MATLAB software and lets you do some heavy computational analytics.

    So I mean what we’re seeing is people are asking the questions, and we’re sitting down with them and figuring out how to do it, so it’s an exciting time.

     

    Interviewer:                It definitely is. And Catarina, sorry for stumbling on your name. I’m curious, success breeds more success, or certainly brings a lot of attention, and one of the things that’s happening in this whole COVID time acceleration of digital transformation projects is as people had success other parts of the organization started looking at that and say, “Well, how come they can deliver in a week, and we deliver every two months,” or every whatever. Are you getting some attention from the rest of the organization? Is that part of why you’re adding more apps, or are other groups looking at potentially spinning up and doing low-code kind of work?

     

    Interviewee 1:             A little bit of both. So from our organization, I would say yes because we are really working, maybe we are even extreme agile because we are one-week sprint. But the mindset shift of delivering products to the shop floor that are not extremely ready, that are still to be improved, that are lending pages in apps that then are created with the people, I think it’s an almost new paradigm shift that we are starting to see more and more and more, and people are also requesting things that are more useful for them for their daily lives.

    And one of the things that we are also doing is we are going into this exact idea of having less mini apps and have one core that connects our backbone to different modules, and the apps worked basically as modules and puzzle pieces. And that’s more or less type of ecosystems that we want to have, one thing that connects everything that’s basically our core, this big problem that I was talking about, and then having the different workflows that the guys have to do every day, just piece in in order to make the complete puzzle.

     

    Interviewer:                Wonderful. This has been fascinating. Thanks for sharing your story with us, and congratulations on your success, and congratulations also to the HCL software team with a very apparent, a happy customer and productive team using your technology and leading digital transformation. Catarina Pinto, thank you for joining us from Henkel, and Andrew Manby, thank you of course from HCL Software.

     

    [End of Audio]

  • Techstrong TV: Value Stream Management & Value Creation

    Techstrong TV: Value Stream Management & Value Creation

    Lance Knight, ConnectALL President and COO, joins us directly from the Agile 2022 conference. Lance discusses the concepts of value stream management and value creation. The video and a transcript of the conversation are below.

                                         

     

    Mitch Ashley:            I have the pleasure of being joined by Lance Knight. Lance is COO and president of ConnectALL. Lance, good to be talking to you.

     

    Lance Knight:            It’s great to talk to everybody here again. It’s great to meet you as well.

     

    Ashley:            Nice to meet you. I know you’ve had a lot of conversations with Allen and great opportunity for me to have a conversation with you, too. For folks that might not know you or have seen you before, tell us about yourself and of course ConnectALL. Tell us a little bit about that.

     

    Knight:            Well, you know, I hardly ever done that before, told anybody about myself. But anyway, I’m Lance Knight. I’m president and CEO of ConnectALL. And you know, we’ve been around ConnectALL for a while. We’ve been spearheading in maybe in the forefront of this value stream management market and we’re excited to be part of this fun ride that’s value stream management. It’s been an interesting ride for me for years. I’ve been in this space since even before it was value stream management for years now. Just excited to see it grow and excited to be a part of___.com and we recently got nominated. It’s part of the 12 for value stream management solutions. So appreciate that. Yeah.

     

                                     As for myself, more about myself, you know, I’ve got a wife, a kid. I’ve got three kids. I’m just kidding now. But lots of cool things happening in our industry now.

     

    Ashley:            It’s fascinating I think one of the things that is fascinating about value stream management is it’s emerging but it’s been around for a long time. It’s not like it’s new. It’s in the manufacturing and you go back to the goal and all. You know, a lot of other things and Toyota. So it isn’t a new concept, but it is as we apply it to software. What do you think it’s now is the time for value stream management? I’m really curious. Obviously you made a big decision of you’re CEO of this company and that’s what you’re focused on. Why is now the time you’re going to be able to make this happen?

     

    Knight:            First, you know, you’re so right and I’ve said this quite a bit, is, you know, I started my career in manufacturing, dong value stream management work, understanding leans, systems thinking, all of those things to improve how manufacturing happened. And what I think is now as you take a look at what happened with Agile, what’s going on with DevOps, and the way that people are developing software, they’re thinking how do I make this even better. And I have a whole bunch of opinions why now. One of those is maybe a little controversial, is the goals, aims, and means, and the great vision of what an Agile transformation was supposed to do with my organization was never truly achieved.

     

    Ashley:            You mean it got overhyped and oversold?

     

    Knight:            Overhyped, oversold. It only really talked about how developers to work better. It never, you know what I mean?

     

    Ashley:            Oh, I totally know what you mean.

     

    Knight:            My organization has spent millions of dollars on these coaches and transformational people, and now you want me to do that with DevOps too and build a community and feel good about it, and sing Kum-Ba-Ya.

     

    Ashley:            [crosstalk] solve that for us, didn’t- Agile solved that for us too before that and you know, this succession.

     

    Knight:            Yeah, right.

     

    Ashley:            It’s an evolution, right.

     

    Knight:            And I see a little of that bleeding into value stream management, but I think why V.S.M right now, because it makes you look at your end to end flow. It makes you understand how you’re deciding what to do. Makes you look at how co goes through things. It’s a little more logical, not that those other ones aren’t. But it’s more specific. It’s got an age old set of things. And business people, the ones that make decisions on things can wrap their head around it. All right, so someone puts a request in here, it goes here. It goes through our agile processes. What do mean? I can finally get these reports to tell me how efficient my teams are? I think that’s what’s driving a lot of it. And ConnectALL we call it see, measure, automate. I can see my value stream now. I can measure and I can automate.

                                       

                                     And I think that’s just one reason why it’s taking off. And I think there’s some other ones. You know, well, we do agile, DevOps, value stream, what are we doing and how does this relate? And at ConnectALL we say this all the time, so it’s really interesting. Value stream management is a human thing. It’s a human endeavor. We talked earlier it’s been around forever with manufacturing. We didn’t have machines and computers out there measuring our value stream. We went and did that. We improved the flow. We looked at how parts moved around the shop floor. We mapped it. And we had some tools to help us. And a value stream management platform that’s what they’re there to do, help humans be more effective with managing requests to code in production, connecting it and automating the processes within it.

     

    Ashley:            yeah, there’s this phrase I heard, I don’t know where from. You know, you want to work on the business not just in the business. In other words, you have to sort of, that’s about continuous improvement, whatever that might be. But you have to understand it first. You have to be able to measure first. Where do we go improve. Another thing I wanted to run by you is I think one of the reasons why value stream management gets a lot of attention is we’ve elevated the value, the strategy behind software and how much that is importance of that to businesses, how much they’re counting on our ability to deliver. But you know, gone are the one year, 90 day whatever projects where you know, we think we’re going to get this spec, but we never do and something else pops out. And now we’re doing lots of little smaller races. How does a business know if I put a quarter in here I’m going to get my quarter’s worth of what I thought I was going to get there and how we can manage that process to help achieve those results? Is that fair do you think?

     

    Knight:            That’s fair too. And I think that’s another reason why it’s taking off right now, right. You know, my controversial point, but then there’s this other point of I’m never- I’m an executive. I’m over an organization. I’ve never seen what I’ve had move quick enough, move through. What are the bottom numbers? It’s invisible to me. Right? I have an initiative and I know I need these capabilities. I need this software. I need all these things. And as I’m saying that I’m watching just this initiative that’s an artifact in some system, I don’t know if that’s moving forward. I don’t know if I’m blocked. It’s a black box to me.

     

                                     And value stream management kind of opens some of that up as you kind of look at flow. And then also like you said earlier, how am I prioritizing that? I’ve got technical done. That’s really important to repair. But how do I prioritize that rather than somebody saying I need to fix this technical debt. Where you could look at it and say, not yet. This is more important than that. This new capability to make me competitive in the market is more important than if I fix that technical debt today. And those decisions aren’t able to be made at the right levels. And it’s also strategy execution where I can go and to sign my outcomes I want and my initiatives. And then have those get executed across all the organizations, because we have all this visibility and track it.

     

                                     So that’s the see part. And also the measure part where you talk about measuring. I can say, all right, now I’ve improved our processes by 25%. So now I can move quicker. The only thing that I think value stream management we have to be careful of is I don’t- and I’m seeing some of the other analyst firms do this. It’s not DevOps value stream management. It’s value stream management. And DevOps things are a part of that value stream.

     

    Ashley:            We have a value stream whether you’re doing DevOps or not, right?

     

    Knight:            You know, at ConnectALL my head of products says there’s a value stream now. Every company has it. You may not be aware that that is a value stream, but it is.

     

    Ashley:            I think it’s just been more elevated to our consciousness, right, because of DevOps.

     

    Knight:            Or more aware of the flow of value through it. Right. So, it’s interesting as it takes off and goes next stages of it and so on. I just want to make sure it stays the highest level thing from an organization perspective and that’s your value stream, right. You have DevOps tools of course and those are part of your value stream also. I just did a speaking slot somewhere about value stream management is not a feature and I went into that whole thing about how value stream management isn’t a feature of a tool or another tool. It4 is what you do and the tools and the platforms how you be more efficient. So it’s a different take I think than a lot of organizations have on it as they try to figure out how to build the best value stream feature in their product.

     

                                     So ConnectALL we have value stream management platform. It lets you see, measure and automate but if you’re not educated on systems thinking, lean principles, we can do some little stuff, but you would have to map it, use area waste principles, lean principles to think it through, right. I’ve got some mooda, if I used the word right. Maybe we’ll get some text about he said that wrong, which I probably did. Which anyway, that’s waste. And then you could go figure out how to fix that. Why am I having these things?

     

                                     So yeah, I mean I think it’s going to take off pretty well in organizations need to do this now because software is no longer that thing that that guy in the corner called Lance programs so that you’re more efficient in some of the manufacturing stuff you’re doing.

     

    Ashley:            Reminds me of, well, Jim and I first worked together in security. Security we evolving from sort of the people nobody knew that did this thing behind the scenes and couldn’t talk to them because they didn’t know what it was about, to more everyday people, system administrators, network administrators. And so you had to really think about the barrier to entry, right. Do you have to be a lean expert to do value stream management? Or can you step your way into it so there’s the whole idea for barrier to entry for your products? And how do you make that lower to get people started? And I know you had I think an announcement recently for ConnectALL. Can you tell us about that?

     

    Knight:            Yeah. So first, so you don’t need to be a lean expert to do it. Just have to maybe read a little white paper on it. And understand just the basics of it and it’ll help you through. So what we have done if you’re referencing to the fact that, and one of the reasons why we wanted to do this is that ConnectAL is going to offer a free online value stream management visualizer, designer where you can log in, put all your tools on there, draw the boxes of flow, decide what kind of flow loops you want, and just lay out your whole value stream, that’s actually yes, that’s’ what we have. That’s our big announcement coming next week is the free online value stream design. And it’s a nice little drag and drop environment where I can just drag on my tools. It’s going to have all the different tools on there, and then I can draw lines between them. I can set up my swim lanes, my boxes. We can do all kinds of things in order for you to lay out your value stream. You can name the links. You can name it so it’s personalized. You can put notes in there. And then it’ll give you a  PDF view of your value stream that you can export, you can go around and share that with your manage- here’s how our workflow works. And it comes from the years that I’ve been doing value stream management workshops on a big whiteboard, but we’re not getting together these days for these big whiteboard sessions. So you know, it’s got these different pallets and you can do all these things so that you can actually get a good vision to see your value stream and how things are flowing. And we’d be happy to help you lay that out if you wanted to get on with a session with one of our session architects to walk you through it. You can save them because maybe multi-session thing. Export them and share them with other people that can load it into the free value stream from their computer. And we’re really excited about it because I think it’ll really help people understand how they can use just this one part of value stream management.

     

    So you know, at ConnectALL we’re all about helping the humans be more effective at this, right. And it’s just a great opportunity for anybody’s interested in getting involved in value stream management to have a place where they can go just lay it out. It’s pretty robust. There’s some cool things. Yesterday I was messing with it. I drew a turkey in it. So, you know, Thanksgiving’s coming. So, we drew this little turkey in there, right. Somebody will probably do a Christmas tree as well. But the cool thing is I know some people will probably be like well, I can do that with this tool and this tool. That’s true you can. However, this one’s also free and we’re going to have all of the images and icons of the tools and the flow icons and all of those things preloaded so you can just drag and drop on there. And you’re off to the races of being able to start to tell the story around how you can improve value stream within your ___.

     

    Ashley:            Looking at things systemically, even if you think you know the system, the process really well, at least my going through things like that, you just go, I don’t really know what happens here. I kind of do but I don’t really know. So you can learn that or figure that out or somebody who’s mapping this out. And then to your point is once you’ve got that, now you’ve increased your understanding of what we do or the flow of what we do, where do we work? Right, you’re going to go with the theory of constraints and let’s look for a bottleneck. Let’s look for you know, we need a future over a technical debt is where value is. And you start to connect it into a system of creating software, which is I imagine more of your- the paid version of ConnectALL.

     

    Knight:            Well, so paid version will operationalize your connections. We can actually, you’ll see the flow of work and we do the integrations, the connections, the triggering, the capturing. We offer all the tough stuff the V.S.M. platform can do at ConnectALL. And normally for these talks I don’t talk much about our great product which is really, really great. We got a brand new release, 2-11 coming out that has some great- I’m using platitudes by saying great, but it has some really great features coming out in the future.

     

                                     Usually when I talk I want to help the industry. I want to help the space. And that  helps me of course. But here this free tool will get you up and running. You can see, measure, you can do some measurement stuff in there. And actually you can put your measurements in there and actually tell a story to your boss. So I was on a conference recently and someday said, well, to do value stream management you need to you know, go talk to your boss and have him approve the project and build a little community and figure out how you’re going to adopt value stream management principles and do all this stuff. And I started to feel like here we go again with community and adoption and the feel good part of it.

     

                                     And all of that is really relevant when you think about agile, when you think about DevOps, that is relevant. DevOps is a culture shift. And a culture shift, I’ve spoken on this before, is transforming operations and DevOps to work so well together and when operations is normally commanding control, right, can’t have access to those servers because this reason. I used to be that guy, so I can speak to it with great understanding. And having people change that mindset and culture so they can collaborate better, this is not. This is value stream management. You map the value stream. You look for waste. You point it out. You try to figure out how to remove it. And you work with people to do it, don’t get me wrong. But there’s no sprints. There’s no ceremonies. Once you’ve done it, you look at it, figure out how to improve it. You improve it. You modify your map. And by the way you can save these and come back. And then you look for the next place to improve flow. I’m for the other stuff. I’m just saying this is not. This is value stream management. It’s lean thinking. It’s been around forever. Doesn’t require all this other stuff, go do it.

     

    Ashley:            I think from an end user perspective I would think that now having a way of dipping my toe in the water, maybe more than that to really understand what’s going on. And I can decide. Now I can decide to go to the next place, whatever that looks like with ConnectALL.

     

    Knight:            Yeah. I go map it out and then I can talk about it.

     

    Ashley:            Not making a big bet that this thing is going to do stuff for us, but I just don’t know. Right. You know, you’re going to get value unintended.

     

    Knight:            So we’re really excited about it.

     

    Ashley:            Well, congratulations. When this airs actually I think it’ll be when this is released. So, how do folks get ahold of this? Is this ConnectAll.com?

     

    Knight:            Right, ConnectAll.com you’ll see a link there in the home page to go to designer and it’ll come up. We’re not looking for tons of lead information. We don’t want to know how many people run your company and you know, got control over that. I mean all we want is maybe an email and you’re off to the races and you can save them and do all the stuff. And just use it to take that first step. And we have some partners who are using it to run consulting sessions and different things like that. So, I think it’s something that nobody’s done yet. I think it’ll really help move value stream management forward.

     

    Ashley:            Great. Well, congratulations on the launch of this entry point, the value stream designer. And definitely I’m going to check it out. So, appreciate-

     

    Knight:            I’d be happy to walk you through it. I’ll send you a quick copy of the turkey we made.

     

    Ashley:            I would love to see the turkey. All right, Lance. Lance Knight, CEO and president with ConnectALL. Thanks for joining us today, Lance.

     

    Knight:            Thank you.

     

    Ashley:            Take care.

     

    [End of Audio]

  • Fixing Spring4Shell Starts With Software Supply Chain Management

    Fixing Spring4Shell Starts With Software Supply Chain Management

    Spring4Shell is the latest call to action for radically improved software supply chain integrity. While Spring4Shell investigations continue, one conclusion is indisputable: We must holistically rethink the way we continuously inventory and manage the complex landscape of interrelated software and its sources.

    Whether or not Spring4Shell surpasses the breadth of impact of Log4j, there’s still massive potential for severe consequences to software and API security across the open source infrastructure, frameworks and application software stacks.

    That’s because, as we saw with Log4j, this attack could impact most enterprise Java applications globally. It seems the root cause is a vulnerability in the widely used, free, community-developed, open source programming framework Spring Core.

    The Spring framework is the foundation for most enterprise Java applications—as many as 74%, according to some data. Specifically, Spring serves as the foundation for enterprise Java apps so that teams can focus on application-level business logic without being locked into specific deployment environments.

    Spring Core’s ubiquity introduces significant potential for widespread impact due to its use across enterprise software, cloud services, third-party software and service products as well as internally managed software. This is another call-to-action to improve the way we approach software supply chain security and supply chain management. Thankfully, there’s already a place to start.

    Every infrastructure and software team can begin addressing this vulnerability by leveraging resources from The Linux Foundation’s Software Bill Of Materials (SBOM) project. The 2021 initiative included an SBOM readiness survey, a Generating Software Bill Of Materials training course and an SBOM generator tool based on the SPDX standard (ISO/IEC 5962:2021).

    The Linux Foundation’s SBOM contributions provided all of us a head start to begin addressing issues with software supply chain management. With widespread adoption, SBOM equips software projects and users to assess and address Spring4Shell as well as any other as-yet-unknown vulnerabilities and prepare us for what is undoubtedly a season of high-impact infrastructure software vulnerabilities.

    For more Spring4Shell resources, please visit: https://www.contrastsecurity.com/security-influencers/new-spring4shell-vulnerability-confirmed-what-it-is-and-how-to-be-prepared

  • Updating and Managing Infrastructure-as-Code (IaC)

    Updating and Managing Infrastructure-as-Code (IaC)

    Infrastructure-as-code (IaC), often embodied by open source Terraform, is an essential ingredient to cloud and cloud-native strategies. But without the ability to scale, secure and manage IaC, you very quickly experience drift. Tim Davis, DevOps advocate with env0, pronounced “N zero”, discusses establishing a single source of truth and reigning in drift by updating and managing infrastructure as code. The video is below, followed by a transcript of the conversation.

    Announcer: This is Digital Anarchist.

    Mitch Ashley: I have the pleasure of being joined by Tim Davis. Tim is DevOps Advocate with env0, and so, we’re going to be getting into some infrastructure as code type discussions, so, looking forward to that. Welcome, Tim—good to be talking with you.

    Tim Davis: Same for you, Mitch. Great to meet you. Thanks for having me.

    Mitch Ashley: You, too. I love your cloud off to your right shoulder, by the way. [Laughter] Anyways, so—introduce yourself, tell us a little bit about env0.

    Tim Davis: Absolutely. So, I am the DevOps Advocate with env0. dnv0 is a TACoS platform, if you will, the Terraform Automation and Collaboration Software space. We really focus on infrastructure as code, automation, teams and governance, and other tools to help you with the life cycle of your infrastructure as code environments.

    Mitch Ashley: Cool. Good. Well, you know, it’s a great conversation to have, because something that I observed always happens in our industry is, you create a new technology, it’s kinda easy to get started and starting to use, sometimes it isn’t always easy, but the complexity comes—alright, how do I scale this? How do I do this across a larger development team or multiple development teams? How do I operate it? How do I secure it through the day two kinda stuff?

    Tim Davis: Right.

    Mitch Ashley: And I wouldn’t be surprised if you told me the same is true for infrastructure as code, and in fact, I know that to be true.

    Tim Davis: [Laughter] Exactly right.

    Mitch Ashley: Let’s talk about that. What are some of the challenges once people get into doing infrastructure as code, particularly with Terraform? What are some of the challenges that you run into?

    Tim Davis: Yeah, and most of those kind of lie around the visibility and kind of the control space of that. Infrastructure as code is great. It is a fantastic way of speeding up, kind of pushing yourself into the future for DevOps, getting into that real GitOps life cycle. But with that, you know, if it usually just starts out with either one developer or one infrastructure person that starts running it locally on their laptop and figuring it out, it’s great, it does what they want.

    As soon as you start to scale that methodology and doing it locally to multiple people, that’s when you start losing that visibility of, “Where are my state files stored? Who just deployed something into the cloud? What variables might they have used for that?”

    So, it really becomes kind of an, “I don’t know who’s doing what in my cloud anymore.”

    Mitch Ashley: Mm-hmm.

    Tim Davis: So, really making sure that you’re staying on top of that, kinda centralizing everything to maintain that visibility is very important when you’re scaling it.

    Mitch Ashley: Let me ask you, then—is it fairly typical that within one software Dev team you have a person or sort of a close enough coordinated group of people that are doing the software as code, infrastructure as code. And then the confusion may exist as you start to go across multiple teams, or does it also occur within one team, just sometimes, it’s every developer for themselves and so—

    Tim Davis: Yep.

    Mitch Ashley: – you could have a wild, wild West kinda situation before you know it.

    Tim Davis: [Laughter] And the answer of that, of course, is yes, I mean, it’s all of the above. It could be even just two people on a small team that start to use these tools and they start to step on each other’s toes by having deployments that kind of counteract each other. Or you have it where somebody is deploying out into the cloud using your infrastructure as code and somebody else is just going into the cloud and clicking around and deploying stuff manually where you get something called drift, where what the infrastructure as code says is out there isn’t necessarily matching with what’s actually there.

    Mitch Ashley: Mm-hmm.

    Tim Davis: So, it can be across a single team, multiple teams—any time you really scale it past a single person on a laptop is really where you start to see those issues.

    Mitch Ashley: Yeah, okay. It’s a familiar problem, right?

    Tim Davis: [Laughter] That’s exactly right.

    Mitch Ashley: We’ve had this in other things, too. Well, what are some of the best practices or kind of good infrastructure as code hygiene to keep your worlds at least sane to start with so you—the first question is always, “What’s there?” If you don’t know what’s there, then—

    Tim Davis: Right.

    Mitch Ashley: – everything is up for grabs, or you question everything because you just don’t feel like you have a good grounding of what you’re looking at and what you’re dealing with. What are some of those best practices?

    Tim Davis: And I really—I try to stay away from the best practices thing, because sometimes what’s good for somebody isn’t great for somebody else, but that—

    Mitch Ashley: Well, and I say that as best practice is not universal, right?

    Tim Davis: Absolutely. And there are some things that you can do to help yourself out, for sure. If you’re using infrastructure as code, having the single source of truth can be very helpful for everybody, essentially stopping that drift that I just mentioned. So, if you are using infrastructure as code, save them in a repository somewhere. Make that the single source of truth where whatever’s in there, whatever’s in those infrastructure as code files, that’s what’s there.

    So, whenever you decide to go for infrastructure as code, stop using the cloud UI, stop going around and click, click, clicking and adding resources and things. Do it by updating the infrastructure as code file and then re-deploying. That can really help you make sure that you’re not causing any problems, nobody’s stepping on anybody’s toes, and you know if I see it in the files here in this one spot, that’s what’s out there.

    Mitch Ashley: Mm-hmm. Yeah, I totally agree with you. That makes a lot of sense to me. What are some of the complexities, then, you have to deal with? Because now we’re working an environment where infrastructure, the stack, the distribution of that, the locations, whether geographic or service provider really can change instantly without necessarily the full development team, which is an advantage, right? You want that sort of abstraction.

    Tim Davis: Exactly.

    Mitch Ashley: But it also can be—introduce new variables and maybe even new problems.

    Tim Davis: Yeah, and it could be new problems, it could be the same old problems, or it could be new problems that you kinda deal with the same, old way. And, you know, adding controls of making sure you’re adhering to policy, like, you’re only allowed to deploy to certain regions or you’re only able to deploy a certain number or size of instance, making sure that you have some form of role based access control there to know, you know, this person is allowed to deploy straight out to development, no problem, but if it’s going to production, it needs to wait for approval and somebody from either the DevOps team or the SRE team needs to validate everything first before we actually make that push.

    Mitch Ashley: Mm-hmm. I think something else that always happens, too, is in—you know, I’m a security guy as well as a software guy, so, I always worry about the security side of it. Now, automation can make that, you know, much better.

    Tim Davis: Exactly right.

    Mitch Ashley: Much more reliable, less human error. There’s a lot of good things that come with infrastructure as code from a security standpoint, but it also can be, it’s sort of security is in the eye of the scripter and the person who’s—

    Tim Davis: Right. [Laughter]

    Mitch Ashley: – doing, you know, configurations or doing the scripting, too, which can be good or bad. How do you address security in this kind of a world?

    Tim Davis: Yeah, and this is just one of those things where we’ve all heard the term shift left, and shifting all of these different things—security, performance, you know, billing—everything, if you shift it left into the deployment process, it really helps if you foster that communication. I mean, we know that old school term of silos where one hasn’t isn’t talking to the other hand. If everybody gets involved, if the security team is involved with writing the policy, they’re involved with double checking that it is implemented into the deployment process so that you don’t have to go and fix a problematic deployment later, it’s just stopped before it starts. That can really make sure that everybody kind of gets what they want, but security folks still have to be involved. They are still in charge of the overall process and procedure and policy, it’s just, it’s kind of a new way of getting that implemented and at what stage of the life cycle you’re implementing it.

    Mitch Ashley: Do you think it shifts—and this is actually, I just did a talk on this about shifting left of, we wanna shift everything left, which is generally a good idea, right?

    Tim Davis: Right.

    Mitch Ashley: To be able to address some of those things early and design it in, design security in, et cetera. Oftentimes, it’s interpreted as, “Let’s put that on the developers, too. Let’s have them—the developers will worry about that. The developers will worry about all those.” Now, it’s pretty much, it could be everything, sort of a ridiculous request, right?

    Tim Davis: Right.

    Mitch Ashley: Because that’s not a developer’s expertise to necessarily know all those things. What is your—when you say shift left or infrastructure as code—

    Tim Davis: Right.

    Mitch Ashley: – in practical terms on a software team, what does that look like?

    Tim Davis: Yeah, and a lot of folks think that that just means, “Hey, I’m taking away your job as the security guy and I’m gonna give it to the developer” and that’s not the case. The developer, they may be a little security conscious, they may understand the infrastructure or the networking piece, but nowhere near as much as the career security guy or the career networking and infrastructure guys. It just kind of brings them in and fosters that conversation.

    I definitely think the developers are going to be part of the conversation, because it is bringing it into their tooling, into their languages, into their life cycle, but it still requires that expertise to be able to make sure that it is done correctly, it’s implemented correctly, and that it’s being checked the way it needs to be done.

    Mitch Ashley: Mm-hmm. So, does it look like security engineers, to use that as a term, they’re sitting down with the developers, saying, “Okay, how are we configuring the environment?” and, “Here’s how you’re building your Terraform configurations”—going through that with them?

    Tim Davis: I think so.

    Mitch Ashley: Is it saying, “Here’s the principles we want you to follow”—

    Tim Davis: Yeah.

    Mitch Ashley: – “and as you’re creating this, please do these things, and then we don’t have to sit on your shoulders”?

    Tim Davis: I definitely think there’s lots of different ways you can do that. I mean, obviously, you know, having your standup meetings, making sure that they are kinda telling them, “This is what the policy should look like, however you want to implement it is fine, but this is the kind of processes and procedures, these are the rules that we need to check.” So, it can definitely be done however works best for everybody, but as long as you’re having that communication and you’re making sure that everything’s going through—yeah, you know, you can always do it different ways and be successful, still.

    Mitch Ashley: Mm-hmm. Interesting. What are some of the things that you’ve seen change? You know, there’s been a lot of acceleration over the last 12 to 18 months.

    Tim Davis: Right.

    Mitch Ashley: And, you know, I’ve heard people talk—of course, you always hear about the, as much digital transformation happened in the last year that was planned for five years.

    Tim Davis: Yeah.

    Mitch Ashley: And there is some truth to that, and I’m sure some exaggeration, too. But there’s a strong belief that, you know, people are now thinking they can deploy applications much, much faster and they’ve proved it in this last window. Have you seen that happening?

    Tim Davis: Yeah, absolutely, and you know, technology changes. They used to say it doubles every six months or what have you, and really, we are iterating and changing and kind of moving forward very, very quickly. A lot of times, we get a new tool and it’s great and then people are like, “Alright, I’m gonna pull this tool in and automate it” and then they figure out, “Oh, there’s some extra complexity here and we’re having to go back through and figure it out.”

    I definitely think there’s a lot changing, you know, even just the shift from on prem legacy, I guess, enterprise architecture through to new, like, cloud native architectures and things like that. We’re moving fast, we’re able to change and pivot and do what we need to do, but as long as we make sure that we’re kind of keeping grasp of what we’re supposed to be doing from either a security or an infrastructure construct, we can make sure that we can iterate and change and adapt as fast as possible without causing any major issues down the line.

    Mitch Ashley: Mm-hmm. Cool. What do you think the next 6 to 12 months look like? If you had to put on your crystal ball, your Magic 8 Ball, that says, “Ask Again”?

    Tim Davis: [Laughter] Yeah, I love to look into that. Obviously, it’s good to see, you know, what am I gonna have for lunch next week, but also, you know, looking into the industry of what’s gonna happen. We’re seeing more and more X as code. We’ve got infrastructure as code, you’ve got security as code, you’ve got policy as code tools. I think we’re gonna see more and more and more, you know, performance as code and things like this that just are able to bring those day two plus operational tools closer left into the deployment cycle and have all of these single source of truth in the repositories of, we know exactly what our infrastructure is supposed to look like, we know how it’s supposed to be secured, we know how it’s supposed to perform. All of this is just declaratively set up there. I think we’re gonna see a lot more of that going forward.

    Mitch Ashley: Mm-hmm. Well, certainly, as you said, it follows the “everything as code,” right?

    Tim Davis: Exactly right.

    Mitch Ashley: And if we’ve learned nothing else, I think that’s been a lesson of the past 12 to 18 months, right? It is software, it’s all about software.

    Tim Davis: It absolutely is.

    Mitch Ashley: What do you think some of the skill challenges are for people as we continue to evolve this and move into this rapid world, shifting things left, doing more infrastructure as code, and maybe asterisk as code—everything? You know, it’s always the self-learners can be at the edge of the curve, other folks have other ways of learning. How do we bring everyone along in terms of their skills and their learning, their development?

    Tim Davis: Yeah, and that’s definitely something. I mean, I ran into myself. I’m an infrastructure guy at heart, that’s where I’ve been, you know, my whole career, and eventually, someone was telling me, “Hey, this Python thing might take off” or, “I’ve heard of this thing called Terraform and it’s basically like code, but it’s our job.” And, you know, just realizing that nobody’s trying to take away your job as a security guy or an infrastructure guy or girl or what have you. They’re not trying to take it away from you and move it over to a developer, it’s just one of those things where you need to adapt to move forward faster.

    Now, it’s not just infrastructure folks that are learning to code, it’s also developers that are kind of learning infrastructure and figuring out how can I optimize my application against this infrastructure a little better? How can we work together to move forward faster? So, it’s kind of a melding of skills from different, you know, old school silos now to work together to solve the problem.

    Mitch Ashley: I made that recommendation to a network and security engineer about 10 years ago. It’s like—learn Python, and he looked at me like I had six eyes instead of two.

    Tim Davis: [Laughter]

    Mitch Ashley: And he came back from the Cisco conference, he goes, “Now I know why you said that.” [Laughter]

    Tim Davis: Exactly right. And that’s a great piece of advice even today in 2021. I mean, if you’re in infrastructure or you’re a network tech or you’re a security person, look into Python. It’s not as hard as you think and you can do so much with it. It’s a fantastic way to kind of break into that DevOps automation type space.

    Mitch Ashley: I like that, too, and not that we’re trying to make everybody a developer, but if it’s not a skill you have, it sort of leaves out this whole domain of things that you can either do to understand what’s happening—

    Tim Davis: Right.

    Mitch Ashley: – or do to automate or et cetera. It’s sort of like you’ve got one arm tied behind your back, why don’t you have two out in front where you can fully work?

    Tim Davis: Yeah. And it also helps from a cohesive understanding between groups. Back when I was a dedicated infrastructure person, myself and the development team didn’t care for each other, because we all were trying to get in each other’s way, it seemed. We were trying to solve the same problems, just going about it in different ways, because we didn’t necessarily understand the methodologies or how those people were trying to get their work done.

    If you as an infrastructure, security, or other operations person start to kind of learn the development methodologies and figure out how things work, it’ll help you to communicate and solve problems across teams better, simply because you kinda see where they’re coming from with their tool sets and the way that they do business.

    Mitch Ashley: Great. Well, it’s been a great conversation. I’m glad we got to explore this path together.

    Tim Davis: Absolutely.

    Mitch Ashley: Where can folks find out more about env0? I know you have a kind of funky spelling of env0.

    Tim Davis: [Laughter] Yes. We are at env0, E-N-V and the number 0.com. You can find us on Twitter @E-N-V-Z-E-R-O and on YouTube at E-N-V-Z-E-R-O.

    Mitch Ashley: Great. So, environment zero, right?

    Tim Davis: Exactly right.

    Mitch Ashley: Perfect. Well, hey, it’s been fun talking with you and hope you’ll come back again.

    Tim Davis: That sounds great. I look forward to it. Great to meet you, Mitch. Thanks for the time.

    Mitch Ashley: Alright, take care.

    [End of Audio]

  • Log4j: Is There Such a Thing as ‘Too Much’ Open Source?

    Log4j: Is There Such a Thing as ‘Too Much’ Open Source?

    The Log4j vulnerability got me thinking: Is there such a thing as too much open source?

    Before anyone immediately fires off a flaming email, rage tweet or scathing blog post, hear me out for a moment. If you know me, you know that I am an open source fanatic. I’ve been asked many times, “Should we use open source software and, if so, how much?” My response was (and still is) that open source software is a massive source of innovation and I can promise you, whether or not you use it, know that your competitors certainly are!

    I could go on and on extolling the virtues of open source and how it enabled the cloud, reshaped software architectures, created new product categories and gave us valuable tools like telemetry and increased visibility into cloud-native apps, infrastructure and beyond.

    When I first heard about the Log4j vulnerability on December 9, like many others, I quickly informed the tech leaders, engineers and SREs in my network about the serious potential risks such a zero-day vulnerability in the widely-used Log4j tool represented. In one way—probably the only way—the Log4j exploit shared a very important characteristic with the SolarWinds supply chain attack of late 2020: The widespread distribution and ubiquitous use of the software across applications, systems and organizations. Arguably, Log4j is used much more widely.

    This similarity raised questions I hadn’t fully considered in the context of such widely used software. Can we use too much open source software? Is Log4j too prevalent in its use and, therefore, a single point of failure? How bad would the Log4j situation be if a fix wasn’t immediately available or if one wasn’t forthcoming?

    The answer I kept coming back to is a resounding ‘no’. I still don’t think there’s such a thing as using too much (insert any open source project name) software. Log4j—and so many other open source software projects—are massively beneficial to us, and we virtually couldn’t function without these systems, tools and solutions in today’s age of ubiquitous software.

    What the current Log4j vulnerability, recent software supply chain attacks and other cybersecurity incidents with widespread impact highlight is our need to quickly respond to security incidents and take remediation steps anywhere they are found in the software stack. And that includes open source software. High-impact security vulnerabilities can occur anywhere across the numerous software stacks and services we use, though they have even greater impact when they occur in widely-used infrastructure, reusable components and microservices.

    In a world of infrastructure-as-code (IaC), it’s no longer a matter of patching a particular set of routers or servers. Unfortunately, much of the software stack is not containerized or built using smaller, easily replaceable containers and microservices—at least not yet. Our mindset and processes going forward from this incident must change, and we have to be prepared to respond to and remediate vulnerabilities both horizontally and vertically across the software stack. In certain circumstances, we have to do this on a large scale.

    As is common with active open source projects, Log4j contributors responded quickly with a readily available fix. The real answer to my original question above is that few are as prepared to respond to an important security vulnerability as those incredible, hard-working, active and engaged open source software developers.

  • Automating Security with Palo Alto

    Automating Security with Palo Alto

    Today, automation is more important than ever before. Integrating security and automation early into the SDLC decreases the risk of potential cyberattacks, provides early and relevant feedback, reduces time to market and improves product quality.

    In this TechStrong TV episode, Taylor Smith, senior product marketing manager with Prisma Cloud, Palo Alto Networks, discussed the need to take a software-centric and cloud-focused approach to security. He explained the importance of automating security to keep pace with rapidly changing applications and software infrastructure.

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

    Transcript

    Mitch Ashley: Well, I’m very privileged to be joined by Taylor Smith. Taylor is Senior Product Marketing Manager with Prisma Cloud, of course, of Palo Alto Networks. Welcome, Taylor.

    Taylor Smith: Thanks so much.

    Ashley: Good to be joined by you today. Tell us a little bit about yourself. I know you fairly recently joined Palo Alto Networks and you have an interesting background in the industry, and of course, tell us a little bit about Prisma Cloud.

    Smith: Yeah, absolutely. So, I’m coming up on my six month mark and I’m really enjoying it. I came from both big and small companies, so previously at infrastructure companies and then I did a little stint in the DevOps space working on some DevOps tooling and chaos engineering. Really enjoyed that, but glad to be back into cyber security, which is really my passion, and covering cloud security and shift left security for Palo Alto Networks.

    Ashley: Excellent. Tell us a little bit about Prisma Cloud. I know it’s pretty comprehensive, a lot of things there, but how would you give a kind of brief overview of what it is?

    Smith: Yeah, absolutely. So, Prisma Cloud, we have the benefit of being best in class in multiple different categories in cloud security. So, we really cover the full life cycle of cloud security, from the infrastructure all the way up to the code level, the code that’s the applications that are running on top of it, and we do that across the full life cycle of your cloud application. So, we’re securing your infrastructure as code all the way to your container images, and we do that at the build time and the run time.

    Ashley: Excellent. Well, as a—I’ve used Palo Alto Network products myself. As a networking company, if you wanna think of it that way, maybe that’s an outdated way of thinking of Palo Alto Networks, which is the point of my kind of thought here is, we’re talking about application security and applications and really, everything is becoming software now. So, the network itself, of course, has been turned into software and now is in cloud and on prem. But the whole stack, the entire stack, you know, infrastructure as code.

    So, that brings some obvious benefits, maybe some challenges with it. What are your thoughts on that?

    Smith: Yeah, absolutely. So, it’s an interesting time to be in the application space right now. Before, you had to go in and physically provision servers, you had to connect cords to routers and network switches, and all of that and then maybe get into the CLI to make some changes.

    All of that’s moved to code, all the way from the infrastructure as code all the way up to the containers that you’re defining how they’re gonna operate, the operating systems are all contained in code. Which is great for developers, they’re able to move a lot faster, they can provision things on the fly, they can use things as they need them or scale them down if they don’t. It saves us costs and makes things move a lot faster.

    The double-edged sword to that is, now it’s out of the security and infrastructure, the IT team’s hands. Developers are just deploying things, it’s kinda the Wild West. And so, to kinda bring that in, rein that whole world in and make sure they’re secure and doing all the right things, it’s good to embed that security in their process. So, making sure you’re scanning in infrastructure as code templates, scanning container images before it gets to the repository and before it gets deployed into production. And that really gives us a chance to actually patch more often, because now developers are getting the direct feedback, and frankly, they’re more qualified to make those fixes than the security team. So, they can actually go into the code that they wrote and make the changes if they’re given that right feedback.

    Ashley: Yeah, I think that’s one of the things, as a security engineer when you think about software, it’s not—I can think of this now as, instead of a solid, it’s almost a fluid.

    Smith: Yeah. [Laughter]

    Ashley: It’s constantly changing, right? And that makes it really difficult to secure, it also sometimes can be difficult from a quality standpoint. But, really, it is almost that kind of a form of matter and the things are constantly changing. So, you can’t expect manual processes were stopping the line to be what’s going to bring security back into the fold. You’ve got to equip people, you’ve got to equip the toolchain, the pipeline that’s creating code and delivering it out to production, and then guiding that process through what you want secured, how you want it secured, what you deal with, those issues as they come up.

    Smith: Yeah, absolutely. Microservices has really revolutionized this where we have a couple customers who, the application that they have, one at the beginning of the week looks nothing like what it looks like at the end of the week. They’ve completely redeployed the full stack, and that’s great for innovation, it really opens up the world, but it does—and you don’t want, as a security engineer, to be going in there and slowing things down. You wanna be a part of that development and actually be a supporter, be someone who actually enables that speed to happen, but still make sure it’s done secure and you don’t get bitten by the misconfigurations, the vulnerabilities in your applications.

    Ashley: Mm-hmm. What is it about the cloud, too—I mean, we talked about microservices containers, those don’t have to be run on the cloud, but of course, we think of them as cloud native architecture. Is it from infrastructure management all the way through to the application itself? How do we have to rethink things than maybe what we did when everything was running in our own private data center? What’s fundamentally different that we might try to do it the old way in the cloud, but really, we’ve got to fundamentally change how you think about it?

    Smith: Yeah, I think a lot of it comes down to that everything is accessible. I mean, there are private links and there are VPNs to make sure that it’s locked down, but at the end of the day, you don’t have physical access to these data centers. So, a lot of it comes down to, there is somehow public access, and we lock that down as much as possible.

    But if you have an EC2 instance in AWS or a VM instance in Azure or GCP, it can be exposed to the world. And making sure that the security groups or the firewall rules are set so that they’re blocking, there’s no catch—I had a customer who explained it to me very well. Where you kinda get these layers of checks in the on prem world where, even if somebody goes in and provisions a virtual machine that is exposed and has all these misconfigurations, most likely, it’s not gonna be touching the world. No one’s gonna be able to access it, so it’s not a big deal. But cloud security, those misconfigurations can really bite you, because they are exposed. And so, getting that right is more critical, and making sure the misconfigurations are found and fixed, it’s much more important than it was in the on prem world.

    Ashley: That’s interesting. I’m wondering how you approach a platform like Prisma. Obviously, people who are already Palo Alto customers may come to it kinda naturally through their relationship with you. But how is it, is it a network engineering team that says, “I need to figure out how to secure the cloud?” Is it a software Dev team saying, “I need better tools to make sure I’m configuring and writing secure code?” Who is it that usually is engaging you for Prisma and then how do they bring it into the organization and kind of spread the love, if you will? [Laughter]

    Smith: Yeah, yeah. No, it’s fun. Part of what I really enjoy about being at Prisma versus some of my previous jobs is, I’m not working with a single person or archetype, I’m working with some cloud engineers, who they, it’s this new—frankly, new to me engineering type where they’re covering everything cloud. They’re doing full stack up to the application for everything provisioning infrastructure in the cloud. Where before, you might have a network specialist and a compute specialist, now you have a single engineer that covers the full cloud. And then we also have developers and DevOps teams that work with us, and so it’s not necessarily the security teams. And then, we also still work with the security teams, so the SOC, the security engineers and the cloud security specialist.

    And all of them have different us cases that they come into Prisma Cloud with, but all of them in the end are trying to use Prisma Cloud to make their lives a lot easier to automate that security and make sure the checks are happening. So, the developers are much more worried about the pre-deploy time where they can secure their applications, their infrastructure as code when they’re container images before they’re actually running containers.

    And then, the security teams are actually going into our system to see what’s the posture in the cloud, getting that view, the complete, comprehensive view of all the things that are running in their cloud environments, and then securing their containers, their Kubernetes environments, their serverless environments, all the things that are actually running. And running incident management through Prisma Cloud, running through the incidents and all the trace data that we give them if there’s an incident that happens.

    Ashley: It’s really fascinating how the security engineer/network engineer job has changed, that role and the skills that are involved. I wonder, I’m just curious what your experience is being more, dealing with software and configuration of software, maybe automating, scripting, things like that as a network engineer/security engineer. It seems like that would make that job more relatable to what a software developer might be doing. They’re not the same thing, but much different than someone who is rack and stacking and, as you mentioned, plugging things in and thinking of networks and physical devices like we used to, not that long ago.

    Smith: Yeah. Yeah, it’s funny, I agree. The role of the infrastructure engineer is becoming much more like a software developer. So, they’re actually learning Python or HCL so they can write Terraform scripts or they can write Ansible scripts and deploy infrastructure using code. And that can now go through pipelines. So, now, I’m hearing infrastructure people start talking about CI/CD, which you would never expect in the on prem world. They’re using a lot of the same language, like unit testing static analysis of their infrastructure as code.

    So, they’re kind of learning to be a developer, but specifically for infrastructure.

    Ashley: I remember the day, it was actually about, I guess, 11 years ago when I took over an IT organization and a network engineer asked me, “What should I be learning? What’s the next thing I should be thinking about?” and I said, “Learn Python,” and he looked at me cross-eyed.

    Smith: [Laughter]

    Ashley: Ended up going to a conference, maybe it was yours, came back and said, “Now I know why you said that, now that we see what’s happening in”—yeah, that’s a huge transformation that’s happened in, really, less than a decade. Think about how massively the network stack has changed and really folded into infrastructure as code as its part of it.

    How has your job changed through your career, and have you progressed with how this has happened in our industry?

    Smith: Yeah, so, like I said, I came from a big infrastructure company and I covered traditional network security back then, and I moved to a DevOps company. And so, I kinda saw this complete transformation where things were automated, people were moving fast. Reliability is kind of—it’s a whole new definition in the cloud. And so, now, you can, even small companies can have redundancy where they didn’t before.

    That makes things very different for the security person. And so, if I’m—now that I’m covering security, again, but now from a more developer focus, I’m seeing how that automation is much more important than ever before, and how that network perimeter is no longer the only place where you can apply security. And it’s becoming less and less important, but it’s still critical to have that perimeter, but all the things happening inside, too. So, that zero trust networking inside your infrastructure, inside your applications, securing your Kubernetes deployments, making sure your containers aren’t over privileged or you’re not pulling in images from open source that are vulnerable.

    All that is now just as important or more important than the traditional security that I kinda started my career with.

    Ashley: Mm-hmm. Yeah, it’s a fascinating journey we’ve been on.

    Smith: Absolutely.

    Ashley: Well, we’re kinda running out of time, here. Where can folks find out more about Prisma Cloud and offerings from Palo Alto Networks?

    Smith: Yeah, absolutely, you can check out our website. So, you can go to PaloAltoNetworks.com/Prisma and you can find out a lot more there, or we have a lot of useful resources like blogs or white papers, and so, if you want to find out more about container security or cloud security, go there, and there’s a lot more information for you.

    Ashley: I was just gonna suggest, right, developers as well as security and network folks, if we wanna say whatever your role or title might be. Well, it’s been fascinating talking with you, Taylor, and good to be on this journey with you through the evolution of the technology that we use and innovation that’s happening.

    So, hope you are doing well and you’ll come back and talk to us again.

    Smith: Thanks so much, Mitch. It was a pleasure.

    Ashley: You bet.

  • Adapting Security with Menlo Security

    Adapting Security with Menlo Security

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

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

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

    Transcript

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

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

    Ashley: Such is the career in security, right?

    Miller: Yes, it is.

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

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

    Miller: Mm-hmm.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Miller: Right.

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

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

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

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

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

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

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

    Miller: Exactly, exactly.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Ashley: Good luck with that. [Laughter] 

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

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

    Miller: Yep, definitely.

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

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

    Ashley: You bet.

  • Managing Cloud Security with Check Point Software

    Managing Cloud Security with Check Point Software

    Managing cloud security across multiple cloud providers, private cloud, AppSec and software as infrastructure, is highly complex.

    In this TechStrong TV episode, TJ Gonen, head of cloud security product line at Check Point Software, advises a security strategy that meets the challenges of cloud environments and cloud-native software architectures, and DevOps toolchains.

    Information about Check Point’s cloud offerings is available here.

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

    Transcript

    Mitch Ashley: I have the pleasure of being joined by TJ Gonen, who is head of cloud security product line at Check Point Software. Welcome, T.J.

    TJ Gonen: Hey, thanks for having me, Mitch.

    Ashley: I love your name. A guitar player in a band in college was named TJ, a good friend of mine.

    Gonen: Oh, really? [Laughter]

    Ashley: So, it’s always nice when I come across another TJ. Well, hey, would you introduce yourself and, as we were joking before, for the two people who might not know, in the world, Check Point Software, tell us a little bit about Check Point.

    Gonen: Right, yeah, so TJ Gonen, and I joined Check Point actually about a year and a half ago from an acquisition of the company. I was one of the founders in the serverless security space, in the cloud security space, so I’ve been around Check Point for 18 months, about 18 months.

    Check Point has been around for a bit more than that, 27 years, one of the OGs of cyber security—literally invented the firewall. [Laughter] So, it sounds crazy, but that’s literally what happened and over the last 27 years or a bit more now, one of the largest individual or independent cyber security companies in the world, billions of dollars, traded on NASDAQ, 100,000 customers over the years, 60,000 active customers, enterprises, I think we secure literally everyone and provide solutions across the full gamut of cyber security with a lot of focus on cloud security over the last two, three years, just because that’s a topic. And that’s what I do for Check Point, I round the cloud security product line.

    Ashley: Excellent. Yeah, I was sharing with you the second firewall I implemented was a Check Point firewall back in the ‘90s, so it goes back a ways. You’ve been around—

    Gonen: It does, it does.

    Ashley: – tried and true solution, for sure. Well, we wanna talk about not just the old days of when maybe you or I started in security. You know, obviously, the environments of what we manage and have to deal with the threat, the attack surface, all of those things has become infinitely more complex, and it’s continuing to go that way, if that’s an accurate phrase.

    I’m sure one of the issues that you deal with is helping customers with how do they manage all of their security across, you know, multiple clouds, cloud providers, their applications, their on prem, stuff that they’re running, SaaS services—whatever it might be that anybody in the organization is touching, whether they’re inside a firewall or outside, right, especially with remote work. Tell us a little bit about that.

    Gonen: Right. Yeah, I think—I mean, because both you and I go a long way back, then we have the privilege, if it’s a privilege, to look at the generations. So, it’s interesting. I think, you know, we talked about Check Point inventing the firewall in ’93, ’94 when the Internet revolution started, and I think that differently, when you look at security before the Internet and you look at security since then, obviously, that changed dramatically. And I think that what we’re experiencing now with cloud is sort of that thing happening again. It’s another inflection point.

    Ashley: Mm-hmm.

    Gonen: And if you—and realistically, from the invention of the Internet and the ultra-connected world, most of what we had to deal with was, generally speaking, in the same domain. Yeah, more complex, more bandwidth, more stuff, more operating systems, but the blueprint—I think people figured out sort of the blueprint over the last 20-something years of what you are supposed to do after the Internet came across, right? Cloud, I think, restarts a lot of this discussion, and it’s not just the sheer notion of, yeah, your data center is somewhere else and your stuff is somewhere else—I think it’s just velocity and scale.

    I think the biggest struggle we hear from customers and prospects, and honestly, even if you own your own environment, is just, you think you figured it out and then a day after, it’s 10 times bigger, 50 times more people have access to it, and you lost control. It’s so easy to lose control. So, I think where we were, where we had, “Hey, you know what? Oh, you have a data center? Okay, let’s put the firewall, let’s put some segmentation, let’s put AV or whatever—okay, here’s the blueprint.” Now, we are in this place where, how many data centers do we have? One, day after it’s 50, and now, how do you know, even, what’s going on there?

    So, I think scale and speed has been the biggest problem, and I think cloud is a real revolution. It’s not incremental, it’s not another thing you need to deal with.

    Ashley: Mm-hmm.

    Gonen: It’s a thing you need to deal with, and it’s a big issue.

    Ashley: The evolution of, we move things to the cloud, but we do things the same way we did on prem.

    Gonen: Right, right—it’s not that.

    Ashley: Then there’s the next evolution of how do you do it within, truly within a cloud environment that matches that. I mean, I remember the days of just managing the rules and what were they all in there for and who put what in, and just—that was complex, you know, when you’re an enterprise, multi-location.

    Gonen: Yeah.

    Ashley: Talk about the management capabilities that you have to have in a cloud environment, multi-cloud environment.

    Gonen: Actually, you sort of touched on something that is a no-no in the cloud environment. You literally mentioned something that, like—hey, someone was sitting down and writing firewall rules and configuring who has access.

    Ashley: Mm-hmm.

    Gonen: Manual, right? There is just no way you can do anything manually in the cloud. I mean, think about this, Mitch. Everything that happened over the last 10 years in Dev and infrastructure has been focused on automating everything.

    Ashley: Mm-hmm.

    Gonen: Literally. We talk about CI/CD, and obviously, DevOps and now cloud, if you look at cloud—cloud totally automated infrastructure and then it totally automated application infrastructure and now it’s automating everything, no code and stuff like that.

    Ashley: Including infrastructure as software, right?

    Gonen: Yes, exactly.

    Ashley: Not all of them are in a stack.

    Gonen: Everything. So, everything has moved towards automation. So, if we are going to, let’s say, you can imagine saying someone is gonna configure something manually on security, by definition, we’ve failed. So, the biggest challenge that’s facing security is how do I automate security? Because it has to secure stuff that’s fully automated.

    So, I would say, you asked about management—the first thing I would say about management for cloud, it can’t be manual. If there is, we have a saying inside Check Point that we say in the CloudGuard team, it ain’t done ‘til it’s automated. Whatever you were working on, whatever capability feature security for, if it’s not automated, if you can’t automate it, you are not done, because by definition, you are gonna be left behind and something is gonna be open, because the rest of the stuff is automated.

    So, I think the biggest—and when we talk with a prospect and when I talk on the stage, even, I always say, “Listen, when you talk about your security blueprint for the future for the cloud, number one is automation. It’s not how secure it is, it’s how automated it is.” Because it doesn’t matter, you can have rocket science technology for security—if it’s not automated, you’re gonna miss half of your footprint, anyway. So, automation has—

    Ashley: Mm-hmm. [Cross talk] the same way twice, right?

    Gonen: Right, exactly. [Laughter]

    Ashley: Without the audit trail. Well, talk a little bit about, you know, there was sort of the orchestration phase, right?

    Gonen: Right, right.

    Ashley: What we thought of as automation now, you’re talking about the entire Dev and Ops process.

    Gonen: Yeah, right.

    Ashley: The infrastructure as code, applications, dynamic environments—you know, things are changing very quickly.

    Gonen: Right, right.

    Ashley: How does it differ today from maybe folks that remember orchestration as [Cross talk]?

    Gonen: Right, yeah. So, it is different, and I think in security—let’s talk from a security perspective, because I think that’s the angle that, definitely, we deal with today. We feel like there’s two pieces to automation that are critical in this world. I call it, I split it into the first one being the presence of security needs to be automated. We lost the luxury of someone telling us that it’s doing something so we can put security in place.

    Ashley: Mm-hmm.

    Gonen: That luxury is gone, so the presence of a security control or mechanism has to be there automatically. So, if someone—just to keep it really simple, if someone is deploying new container to the cloud, which happens a billion times a day, and I decided that that container needs to be secured, then whatever the security mechanism I chose for that container needs to be there automatically. The container is deployed, security is there. How? Magic. I don’t know, but the presence of security has to be automated.

    The second thing that has to be automated is the security configuration itself. Because, again, we lost the luxury of someone saying, “Hey, I deployed an application, how about you call someone to configure the web application firewall and fine tune it to the application?” or, “I changed the application, now someone needs to fine tune the rules.” What? Find new what? It’s gonna change in five seconds, again.

    So, two things have to be automated—the presence of security, and that really talks to DevOps and integrating into the infrastructure as code pieces, just like code is automated or the deployment process is automated, the presence of security and deploying serverless functions, security has to be there. I’m deploying a new VPC and I decided that I need a firewall at the entrance, it has to be there automatically. No manual, no human intervention. And the second piece is the actual configuration. So, if I decided—let’s follow that thought process—if I decided that I’m deploying a serverless function, a Lambda function with AWS, security needs to be there. The security needs to be there automatically, but also the profile of that security, the allow and block rules has to be there automatically and they need to auto adapt to changes.

    And I think that’s such a—this is such a different breed of security automation. This is not just orchestrating security into where it needs to be, and it needs to be in a billion places, it’s also the sheer notion of how do I keep things maintained and configured correctly. And that’s why I think a big change is the definition of who does security engineering.

    Ashley: Mm-hmm.

    Gonen: Like, you and I started a billion years ago—me a billion, maybe you half a billion.

    Ashley: I’m two billion, so.

    Gonen: Two billion? You’re two billion, okay, there you go. [Laughter] So, between us an average of one and a half billion years ago. A security engineer is the one that configured the Check Point firewall, right?

    Ashley: Mm-hmm.

    Gonen: And part of the process was, “Hey, open this port for me, close this port for me, what’s the”—that’s gone. The new engineering is, the new engineer is not only the DevOps guy and the DevSecOps guy, because everything is as code and security has to be as code. I would argue that the new security engineer is the machine itself. Because you have to eliminate, as much as possible, even the process of an intervention, even by a DevOps person.

    There is, the security just needs to find itself there and auto-configure itself. That’s where it needs to go, and that’s where we put in a lot of effort. That’s why I said it ain’t done ‘til it’s automated, because I can give you the best solution ever, but if I actually require you to know what’s going on, there is just no way. You can’t keep up. There’s not enough humans in the world to keep up with the change of what’s happening now in the cloud.

    Ashley: Let me ask you this, because something that I’ve believed for quite a while now is that we are always talking about educating developers about security and helping to write a more secure code.

    Gonen: Right, right.

    Ashley: But the opposite is true, too. Not that security engineers need to be software developers, but security engineers need to understand software architecture as more than a temporary cloud. You obviously know it, you’ve been using the language of containers and Kubernetes and software as code. It’s not that you need to—it isn’t the old way of let’s go to the security team and have them set this all up for us, which is the whole premise of what you’re talking about. That happens, that has to be built into the process, it has to be built into the environment.

    So, what is the role of the security engineer in that kind of a shift left, DevSecOps, that kind of an automated environment—what skills do they need to have today that they maybe didn’t need 5 or 10 years ago?

    Gonen: It’s so fascinating. I mean, this topic, I think that there’s—we’re in this real point in time where there is a new role, architecture, or let’s say hierarchy defined. Because I think you’re gonna find security people, just to your point, when you come to a CISO and you say, “Hey, can you tell me what’s happening in my Kubernetes environment inside Azure?” And the average CISO is gonna say, “I have no clue.” The Dev guys, they do whatever they want with this environment. My security guys know how to read dashboards. They don’t know how to read code.

    Ashley: More of a SecOps kind of—

    Gonen: More of a SecOps, yeah. And I think, then—and to your point, though, when you go to the develop and you say, “Hey, developer, what’s your security strategy?” and he says, “Dude, I’m a developer—what security strategy?” So, I think you’re right that there’s new roles being defined, and I think where the world is coming to is one that you’re gonna find more, like I mentioned a bit earlier, the SecOps and Sec engineering roles are gonna be more and more definitely, in the world of the cloud, people who can write scripts.

    Ashley: Mm-hmm.

    Gonen: I think that you come back in five years from now, you talk with a SecOps guy, and you say, “Hey, can you write item scripts, can you write bash process, do you understand how to connect to the AWS API?” and he says no, he’s gonna have a real problem managing engineering, security engineering in the new world.

    Now, so, I think where the world is gonna go is that you’re gonna have what today is traditional, security do policy, defining what needs to happen, and governance. So, these are the two ends of the spectrum. I’m gonna define what I expect to happen, which measures what do I test for, what do I scan for and so forth, and I’m gonna make sure that it’s being done. And then, inside that sandwich, inside that Oreo cookie, the piece in the middle is gonna be more of the developer people—DevOps, DevSecOps. Because they’re gonna be in charge of actually doing a lot of the security work, so if the policy says applications have to be segmented in the cloud, so the payment application has to be segmented, you know, separated from the CRM application. The security people are gonna say that. That’s the policy, because it’s PCI data or whatever.

    The people that are actually gonna implement segmentation are gonna be DevSecOps people or DevOps people, because the segmentation is done in Kubernetes, and the security guy doesn’t know how to write Kubernetes microsegmentation over Calico and CNI, and these are all buzzwords, he doesn’t even know what they mean. And there’s gonna be governance at the other end to say, “Okay, that was being done. That might be a dashboard or something like that.”

    Ashley: You know, there may be—we could spend a whole other conversation on this.

    Gonen: Oh, yeah, I’m sure. [Laughter]

    Ashley: There might be a nice parallel, the analogue to this was what’s happened on the Ops side, because SRE is big, right?

    Gonen: Right, yeah.

    Ashley: And those are people that know how to code and know how to write scripts, and maybe something like that is the emergence of the security engineer role is going to be as, “My job is to automate the security.”

    Gonen: Exactly.

    Ashley: “Work with the teams, whether it’s the tool pipeline or it’s the software Dev team, the infrastructure teams.”

    Gonen: Right, right.

    Ashley: And almost that kind of a role, I wonder if that might be where we’re headed.

    Gonen: It’s actually very much true, I think that you are heading in the right direction. The SRE was born exactly from that necessity—hey, I need an Operations guy, but I need him to be able to actually orchestrate stuff using code. And I think it’s exactly what’s gonna happen or is already happening to some extent, but it just doesn’t have a name yet, except DevSecOps, right? Like, maybe DevSecOps is the closest thing, which just doesn’t come down to an acronym—DSO, maybe, I don’t know. [Laughter]

    Ashley: Yeah, we need a new job title, I’m sure.

    Gonen: We need a new job title. [Laughter] But other than that, that’s exactly it. And really, I mean, in the cloud world—listen, if you’re a cloud native company and your data center and applications are cloud native, if you hire a security guy from 10 years ago, he’s gonna be lost.

    Ashley: Mm-hmm.

    Gonen: I mean, everything is code. He needs to be able to—

    Ashley: Plus, a lot of developers are moving into security that have an interest, right?

    Gonen: Yeah, right, yeah.

    Ashley: So, that may be the best way to acquire. Well, hey, we’re running out of time, T.J., and I look forward to having you back.

    Gonen: Yeah, sure.

    Ashley: I’d love to chat with you more, especially as we get into sort of the DevOps and the CI/CD pipeline and integrating security into that.

    Gonen: Yeah, I’d love to.

    Ashley: Who knew 27 years ago we’d be having this conversation—

    Gonen: [Laughter] There you go.

    Ashley: – with Check Point? So, things have certainly advanced. Where can folks find out more and check out your cloud offerings?

    Gonen: Yeah, so, CheckPoint.com, and it says in very large letters cloud. That’s where you can go and you can start a demo, you can read a lot of the white papers around these things. And actually, I think more than anything else, we were just talking about developers—experiment with it yourself. Developers, that’s what they like to do.

    Ashley: Mm-hmm, absolutely—write a little bit of code, see what it does.

    Gonen: [Laughter] Right.

    Ashley: TJ Gonen, great talking with you, Check Point Software. I look forward to chatting again. Take care.

    Gonen: Sounds good. Take care.

  • Data Needs and Challenges with CData

    Data Needs and Challenges with CData

    The data businesses and applications need are everywhere and access through a multitude of technical interfaces, including APIs, database queries, data layers like ODBC, cloud services and SaaS applications (to name a few).

    In this episode of TechStrong TV, Jerod Johnson, technical evangelist at CData, joins Mitch Ashley to discuss the challenges of meeting the data needs applications require to support digital and transformation initiatives.

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

    Transcript

    Mitch Ashley: I’m joined today by Jerod Johnson. Jerrod is technology evangelist with CData. Jerod, good to be talking to you today.

    Jerod Johnson: Yeah, no, it’s my pleasure to be here.

    Ashley: Well, as an old ex-DBA, data is always kind of a passion of mine, interest of mine, so I’m anxious to hear more about CData. Would you introduce yourself and tell us a little bit about what CData does?

    Johnson: Yeah, sure. So, like you introduced me, my name is Jerod Johnson, I’m a Technology Evangelist for CData Software. I’ll start with CData. So, we call ourselves a leading provider of data connectivity solutions. In short, what that means is, we make it easier for every user in an organization to connect to their data, which lets them focus on the job of finding value from that data or building applications on top of that data instead of having to focus on the integration, instead of tasking IT teams to build connectors or pipes or flows, whatever the case is, in order to work with the data that they need to drive business.

    Ashley: Mm-hmm. You are number two on my list of what are the reasons people come to IT when they’re building apps.

    Johnson: Yeah.

    Ashley: And that is, security, data, and other apps.

    Johnson: Yeah. [Laughter] 

    Ashley: So, always need data. Well, tell us a little bit about yourself. I’m curious—how did you become a technology evangelist? How did you—

    Johnson: Yeah, so, I actually spent six years teaching before I got into software. So, my education background was in teaching and computer science, and spent six years in a classroom teaching math and computer science, and just decided that we needed a change, for myself and my family.

    So, I started at CData, I was actually a member of the support team, which meant I was answering e-mails and helping solve customer problems. And then I moved into engineering, and spent some time there, but it really became obvious that there was a need in the company for somebody with a skill set that I had, being able to speak to people, being able to present information, even write technical documents. 

    And so, I was pulled into the marketing team, and I’ve been doing that since 2016 for the company. So, writing technical documents, giving talks at trade shows when those used to happen, through webinars.

    Ashley: When we were [Cross talk], right? Hopefully soon, hopefully soon.

    Johnson: Yeah.

    Ashley: Interesting. You’re not the first person I’ve talked to who’s come out of an education background and moved into technology and, in your case, moving into an evangelist role. That whole skill of being able to explain sometimes very complex concepts, sometimes not so complex, but you may not necessarily have the context or the background for a certain thing that you need to learn or understand—

    Johnson: Sure.

    Ashley: Or even explain to non-technical folks, right? So, a great thing to have, especially in the DevRel world that we all live in now of really focusing on how we work with service and kinda think like a developer.

    Johnson: Sure.

    Ashley: Because that’s the people who are using it, whether they’re business developers or people inside IT. Let’s talk about sort of the data challenges, and I’m curious, maybe you’ve seen some things over the last kinda year plus, too, with the acceleration of digital transformation projects.

    Johnson: Yeah.

    Ashley: It seems that one of the challenges always is data sprawl—it’s everywhere, and every application is creating data, consuming data, sometimes creating data exhaust that’s unused or somebody else might be able to use it. It’s no small feat just to find where it is, more or less find out how you can get to it and use it.

    Johnson: Yeah, no, absolutely. I think there have been studies done, I think programmable web is probably the best place to look if you’re looking for a list of APIs. And I think that they have 22,000 public APIs listed at this point.

    Ashley: Wow.

    Johnson: So, I mean, and each of those APIs, you know, there’s data behind it. So, you have that kind of explosion, the API explosion. On top of that, you’ve got private APIs and then databases, data warehouses, these traditional stores. So, data is everywhere.

    One of the things that we’ve found is that, as data explodes, as businesses transform digitally, you get the opportunity to pick the best service for your needs. So, you know, you’ve picked your CRM application because it meets your needs the best. You’ve picked your ERP solution because it meets your needs the best.

    The consequence of that is that your data is now spread everywhere. So, your CRM data is somewhere, your ERP data is somewhere, your warehousing data is somewhere else. And so, there’s this, as you said, this data sprawl where data is everywhere.

    And what we do is, we make it all look the same. So, we like to say that CData lets you see the world as a database. So, we’ve created technologies that allow users to connect to their data, no matter where it is, as if they were connecting to a database. And so, I’ll drop some buzz words, some acronyms here—so, JDBC, ODBC, ADO.NET, these are all database connectivity standards that we’ve produced that now can connect to things that are not databases.

    And so, you know, what that does is, it really democratizes data access. Now, anybody can get to data, from any of the tools or applications that they’re using. So, whether you’re looking at an IT team or a DBA or something like a citizen analyst or a data scientist, it doesn’t matter. As soon as your data looks like a database, anybody can work with it.

    Ashley: Mm-hmm. That’s interesting you say that citizen data scientist—it’s not just developers. Of course, developers are very familiar with ODBC and other connectivity layers for data access, which are fantastic for developers, but you have to have some pretty specific development skills to be able to [Cross talk] this thing.

    Johnson: Sure.

    Ashley:  A lot of this data is sitting on a Dropbox file server in some cloud application, you know, we signed up for a CRM system—well, guess what, I need to connect that with my workflow for when an order comes in. And, you know, as good as Zapier and things like that are for doing kinda nice integrations for automation, that’s not even gonna cut close to solving these kinda problems.

    And you mentioned, too, making it look like a database. I’m curious, from my experience, it’s how you get to it and making that understandable.

    Johnson: Sure.

    Ashley: But it’s also understanding the data and what it means and how it’s represented, because a customer is not necessarily defining the attributes similar in a CRM that they might be in an order system, there may be some variations in just the format of how we capture that data.

    Johnson: Yeah. Yeah, so, you know, what we do is, everything that we make sits on top of the API. So, your API is gonna have endpoints, and those endpoints are gonna expose fields for entities.

    So, let’s take a customer, for example. When you hit a customer using one of our drivers—hit the customer, well, now, it’s a table, it was an API endpoint. What we’ve done is, we’ve kinda tabularized that data model. So, now, every customer is a row in a database table and then each of the fields for that customer becomes a column.

    And then, you know, what we do from there is basically free you to map the data from one system to another as you need, in the tool that you’re using. So, we don’t force a model on you, we’re not trying to create one universal picture of a customer across your organization. We’re gonna let your business specialists do that part. We just make it easier to see, and because it looks like a database, the schema, the metadata, however you define it is really self-describing. 

    Ashley:  Mm-hmm.

    Johnson: You know, if you can talk to a database, you can point your tool. So, let’s say you’re looking at something like Tableau. When you point it to a database, it’s gonna show you all of the tables that are available and then all of the columns that are available for each of those tables.

    Well, we do the same thing, but for something that isn’t a database. So, it could be a NoSQL store like MongoDB or Couchbase or even Amazon S3. It could be a SaaS application like NetSuite, or even Dynamic CRM. So, whatever it is, you get that full tabular model where you can see exactly what’s there and then you can decide how best to work with that data.

    Ashley:  I mean, think about the advantage of, if you don’t have, necessarily, all the programming skills you might want, to go get that data, just not having to use an ABI, but use the driver instead.

    Johnson: Right.

    Ashley: And so, just get that to me in a table form that I can—now, I can compare how one customer is _____ and one, I’m just making that example, to another customer set of attributes and other applications.

    Johnson: Yeah.

    Ashley: Sometimes it’s hard enough just defining who is—what a customer is. [Laughter] 

    Johnson: Sure.

    Ashley: I remember that modeling. But now, you can see what the data is without writing a whole bunch of software and translation and trying APIs and learning specifics about this particular service or this cloud application or whatever it might be.

    Johnson: Right. Yeah, yeah. And that’s one of the things that we really offer is, we free you from that integration problem. We free your developers, we free up IT resources. So, APIs are constantly changing. I don’t know if you’re familiar with the Facebook API, but I think they give a new version, like, every three minutes. I think it’s realistically like every three weeks, but it feels like three minutes when you’re a developer.

    Ashley:  I try not to be familiar with the Facebook API. [Laughter] 

    Johnson: Yeah, which—that’s fair. [Laughter] But with our drivers, our engineers are the ones that are keeping up with those changes. So, every quarter, we release a new product, and that includes all of the API changes that have happened on the back end. So, the only thing you have to do is literally install a new driver into your system. There are no changes—no breaking changes to the API, we merge everything as much as we can. And it really, as I said in the beginning, it lets your business experts focus on your business, whatever that is.

    Ashley: Mm-hmm. I’m curious, too, is it primarily developers that are using CData and the drivers that you have? How many folks may be from a non-super technical environment, maybe some maybe a little technical skills and might use CData?

    Johnson: Yeah, so, that’s a good question. I think it’s a pretty solid blend. So, you know, one customer story might be a mom and pop shop, they wanna be able to look at their QuickBooks data in Excel, they wanna be able to work with it, print it out, edit it, even, and update it that way. They don’t like the QuickBooks UI, they’re familiar with Excel, and so they simply install our Excel add-in, and now they’re connecting directly to QuickBooks from Excel, with full read and write capabilities.

    We can get more complicated than that with customer stories. We have one customer who was dealing with that data sprawl, the data silos where their data is everywhere, and they needed a solution that allowed them to replicate all of their data into the data warehouse that they were already using for BI and analytics. And so, we have a tool, CData Sync, that allows them to do that. So, connectivity—solving the connectivity problem and solving the replication problem, so they get automated, incremental replication of all of their business data into one place for BI and analytics.

    And then, you know, I touched on this before, but we solved that BI and analytics problem in other ways. So, you know, you have data scientists that are familiar with, that really love their reporting tools, whether that’s Tableau or Power BI or any other tool on the market. They don’t wanna have to change tools just to be able to connect to the data. And with our connectors, that’s exactly what they get to do. They get to stay in the tool that they’re already using.

    Ashley: Mm-hmm.

    Johnson: But when it comes to developers, this is where we kind of get into our most complex customers. Ultimately, the customer is an organization that’s building a data-centric tool or a platform, and their developers, you know, they’re the ones responsible for maintaining the connections to data from those tools and platforms. So, you know, you’re building the best BI tool on the planet but if it only connects to SQL server, is it really the best? So, we’ve had companies come to us and use our drivers to build products. And what it really frees up there is one-off API integration.

    So, if you’re building a tool and you’re connecting directly to the API from your tool, integrating against Salesforce looks one way, integrating against NetSuite looks another way. Integrating against Google BigQuery looks a completely different way. But as soon as you use our drivers, it all looks the same. If you can develop a tool that can talk to a database, you can develop a tool that can talk to anything.

    Ashley: And one of the situations I’ve run across several times is through M&A, when you start bringing companies together through acquisitions and of course—

    Johnson: Right.

    Ashley: – you know, you need information, you need data to operate. I mean, just imagine combining a sales organization across two or multiple companies together and ones in Salesforce and one’s in HubSpot and one’s in homegrown whatever.

    Johnson: Sure.

    Ashley: And, you know, getting that data quickly, you don’t wanna have to go through a whole conversion and, “Okay, now everybody’s in Salesforce” or whatever your tool of choice.

    Johnson: Right.

    Ashley:  Maybe that’s where you go, but you may live six months, two years, where you need data out of multiple systems to see your pipeline, see the sales bundle, see, you know, how we’re closing the deal and what’s the conversion rate and all those kinda things for. And tools like CData are extremely valuable in getting to data very quickly to get value out of that [Cross talk].

    Johnson: Right, yeah. I mean, that’s, legitimately, our own personal story. So, when we first started as a business, we had a homegrown CRM, and then we started incorporating HubSpot. And now, you know, as we grow, as we get bigger, those systems don’t work for us anymore, and so now, we’re using Salesforce. And we’re in a place right now where we are concurrently using all three, and actually using our own technology internally to build reports, to do analytics, and then, as part of that process, to migrate data from one system to another—so, moving our data from our internal CRM into HubSpot and then into Salesforce.

    So, because the drivers are standard based, because they make things look like a database, it’s incredibly empowering for IT teams and DBAs to work with the data and to either consolidate it or migrate it, or leave it where it is, but build up connections to it in a way that lets the other data experts, the C suite, whoever needs to see the data, see it quickly and easily.

    Ashley: That’s a good point. We don’t always wanna take on the work of combining things, migrating things. If you can leave data in place, that makes sense to do.

    Johnson: Yeah.

    Ashley:  Boy, what an asset, because now you can get to it, but—okay, just manage it the way you were. And it’s great that you could relate to that example that I brought up where we didn’t coordinate that, at all.

    Johnson: Yeah.

    Ashley: I’m curious, how about the security? What comes with data, security is always super important to access control, things like that. Where in the stack does that fall, and how does CData play in those roles?

    Johnson: Yeah, so, we will leverage whatever security is available from the API. So, you know, as one example, Salesforce users have different permissions, whether that’s permissions to access different entities, permissions to only read entities, to write entities, whatever the case is. 

    So, when you connect to Salesforce using any of our connectors, you choose the user that you wanna connect through and then everything that they can do, you can now do through our connector. Anything that they couldn’t do before, you can’t do. And then we support the full gamut of authentication protocols. So, if an API supports OWASP, we’ll support it. If an API supports other authentication schemes, even—so, like, your Microsoft based products, on premise, we do NTLM. If you’re looking at Kerberos authentication, we can manage single sign-on—just whatever is available there, we allow.

    And then the protocols that the API uses for security—so, SSL, the encryption, all of that is supported as well, so.

    Ashley: I think an advantage you have, since you’re not pulling the data out of those systems and storing it somewhere else, it’s still data that’s living there—

    Johnson: Right.

    Ashley: – all the security systems, the access controls permissions, policies, et cetera, are still within those applications, however they’re managed, either standalone or collectively across those. So, you’re not having to devise some new data permission scheme from that, right?

    Johnson: Right, right.

    Ashley: That’s gotta be a huge plus.

    Johnson: Yeah.

    Ashley: Cool. What do you see as—while we have some time left, here—I’m interested in what you see as sort of emerging applications. You know, we’ve seen a lot of acceleration with digital transformation.

    Johnson: Yeah.

    Ashley: Digital engagement with customers, automation—there’s many more things happening, and of course, those both need data and create data.

    Johnson: Yeah. So, you know, I think one of the things that we’ve seen of late is just this migration to the cloud, where everything is in the cloud, your data’s in the cloud, you’re doing BI in the cloud. So, through products like Tableau Online or the Power BI service, instead of Power BI Desktop, Google Data Studio, AWS QuickSight, whatever the case is, you know, you’re working with data from a cloud platform now instead of something on premise.

    So, what we’ve created is, we have a cloud platform that creates a cloud to cloud connection. A lot of the tools that exist today, you know, even if you wanna go from a cloud platform to a cloud data store, you’re still required to put a gateway on premise somewhere. You know, this is the case with a lot of the Power BI connectivity. And, you know, if that doesn’t—why would you go down from the cloud, to on prem, back up to the cloud in order to work with your cloud data? And so, that’s—the CData Connect Cloud Platform is what it’s called, but it allows live, real time cloud to cloud connectivity. 

    And so, you know, that’s one of the, kinda the emerging trends that we’ve seen is people wanting to just do everything in the cloud. And it makes sense, especially—you know, I think about this past year, right? Everybody’s working remote, you know, you don’t have an on premise server sitting somewhere that can run your platform, you have to move it to the cloud so that everybody that’s working from home can access it, and that’s just one example of this cloud migration that we’ve seen.

    Ashley: Nothing like a pandemic—I say that knowing the human tragedy side of it, all due respect, but—

    Johnson: Yes.

    Ashley:  – to really force some very aggressive changes in our business and how we operate and some really interesting things. Is there a particular area of, you mentioned cloud and more usage of cloud services—what’s sort of the next frontier, if you will, that CData is tackling of how to make this data problem easier?

    Johnson: Yeah, so, I think—you know, we’re thinking about that cloud integration problem and trying to look for ways to help that. But you know, an area that we’ve started pushing into recently is kinda low code developers. So, I had mentioned you have your IT teams and your full stack developers that are used to working with data, that are used to writing code. But something else that we’ve seen crop up is this low code application development—whether that’s in a cloud platform or an on premise platform. And it’s great. You can build a workflow or an app using a drag and drop menu. These platforms tend to be intuitive. And now, your citizen analysts can build a workflow to combine data to get what they need into their BI tool.

    The problem that we’ve seen there is connectivity to data from these platforms, and so, that’s kind of an area that we’ve been pushing in an integration kind of marketing side is reaching out and trying to connect with low code and shoring up our integration with these platforms.

    Ashley: Yeah, and by the way, that happens to be an area of research that we’re working on with CData, and we’ll talk a little bit more about that here coming up in a few weeks—some really good, interesting findings from that research.

    And that was really interesting to Accelerated Strategies, the analyst firm that I run, because there is so much interesting in low code/no code right now.

    Johnson: Yeah.

    Ashley: And of course, it’s so broad of what that means. It could mean a spreadsheet to somebody, you know, as well as low code or platform, you know, there’s a number of platforms for creating applications and accessing data through a CData kinda combined platform. So, it’s really interesting, to me, of kinda who is using low code technologies to create applications.

    And I think the world used to view it, or maybe currently views it as, those are the business users, non-technical. That’s certainly a population, but it’s more and more coming into IT is what I’m seeing.

    Johnson: Yeah, that’s cool. I mean, as somebody who was a developer, was a support engineer, it’s fascinating for me to get my hands on a low code platform and figure out, you know—well, what exactly can I do with this?

    Ashley: Mm-hmm. Yeah, it’s interesting technology. Another way to solve problems, another technology, right, to build the applications.

    Johnson: Right.

    Ashley: How about the mobile side of this? With so many more mobile apps, we’re almost in an era, maybe we’re in the era of, “I’d like fries with that, I’d like a mobile app with that.”

    Johnson: Sure.

    Ashley: Or maybe it is mobile first. Does that change the dynamics of some of the data needs or challenges?

    Johnson: So, I think once you start looking at mobile applications, you’re looking for lightweight applications, right? You can’t—I mean, phones are impressive now, right? Like, I think about the amount of data that I can store on my phone versus the first smartphone that I got, you know, the amount of space that I have for apps. But at the same time, you know, embedding a software library or a driver or whatever the case is into your app, it doesn’t always make sense. Especially if you’re building an app that supposed to be able to connect to hundreds of different data sources.

    Ashley: Mm-hmm.

    Johnson: You know, are you gonna install 100 different 7 megabyte drivers with your app? Like, is that really the best way to go? And that’s another place where our cloud platform makes sense. So, you can be on your mobile app, you can connect—you can build an application that connects to a cloud platform that then allows users to connect to data from anywhere.

    Ashley: Mm-hmm.

    Johnson: So, you know, using the same technology that we have, it’s just consolidated into one single platform. So, you hit that platform and now, you know, you can pull in Salesforce data, you can write back to HubSpot, you can dump a report as CSV into AWS S3, all through one platform.

    Ashley: And you know, so many of those apps aren’t necessarily greenfield apps, right? All that data, maybe even the transactions processing, much of it is happening in other apps, other cloud locations.

    Johnson: Right.

    Ashley: So, when you’re building a mobile app, you know, you’re not inventing everything from the bottom up, right?

    Johnson: Right.

    Ashley: You’re merging a lot of existing resources—functionality as well as data. So, it seems like no better—what better of a kind of application where making it easier to get the data? Because, you know, mobile developers don’t like writing database access code, right? They like building interfaces and doing cool interactions and useful interactions with customers.

    Johnson: Right, right.

    Ashley: So, when you can let them focus on that and really create great experiences with that data, that’s a win/win for everybody, it seems like.

    Johnson: Yeah, no, I agree.

    Ashley: Well, cool. I really enjoyed talking with you, and where can folks find out about CData? What kinds of abilities do they have to check you out, from free accounts or sandboxing or things like that?

    Johnson: Yeah. So, CData.com is our website, and you’ll find all the information that you need there. For any of our installable products, we offer 30-day free trials, and they’re fully functional trials. You know, we’re not rate limiting, we’re not doing anything like that. And then with our trials, you get access to our support team, which we’ve been called world class, we have testimonials on our website if you really wanna dig into those.

    Ashley: Comes from a man who was on the support team, so.

    Johnson: That’s right. [Laughter] 

    Ashley:[Laughter] No, I’m sure it’s really great.

    Johnson: And then, you know, for the Cloud Platform, I think we offer a two-week trial, and so, you can kinda kick the tires on that as well. So, CData.com/drivers is where you wanna go if you’re interested in an installable driver. CData.com/connect is where you can go if you’re interested in that Connect platform, that Cloud Platform for connectivity. And then, you know, you can find us on LinkedIn, you can find us on Twitter, we’re @CDataSoftware. You can find us on Facebook. A lot of our posting there is upcoming events or recent articles or other news announcements, so.

    Ashley: Yeah, and I have checked out your drivers, and you know, an analogy like a Swiss Army knife falls apart very quickly, because you have so many technologies, so many platforms that you interface with—it’s about 50 Swiss Army knives. [Laughter] 

    Johnson: Yeah. So, I’m just gonna plug this—so, I think we’re 250 plus different data sources across 11 technologies. So, somebody out there is doing the math right now in their head to figure out how many SKUs we’re sitting on right now.

    Ashley:  The number of permutations—well, good. It’s really been good talking with you, and I look forward to having you all on again and talking some more, I think, about the low code/no code space and some things that are happening there, so we’ll look forward to that.

    Johnson: Yeah. Alright, yeah. Thanks, Mitch, it’s been my pleasure.

    Ashley: Great. Jerod Johnson, who’s Technology Evangelist with CData.

  • DevOps Chat: Maximizing the Benefits of DevSecOps

    DevOps Chat: Maximizing the Benefits of DevSecOps

    When discussing security in DevOps, we often focus on the security tools instead of the DevSecOps process itself. In this DevOps Chat, ZeroNorth CEO John Worrall takes us to the root of “why” DevSecOps, focusing on the business benefit, gain and measurement of what we seek to accomplish through DevSecOps. John advocates we concentrate on the process and data enabling us to assess risk, prioritize the most beneficial security work and for decision making to creating business value.

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

    Transcript

    Mitch Ashley: I have the pleasure of being joined by John Worrell, who is CEO of ZeroNorth. Welcome, John, good to be talking with you today.

    John Worrell: Thank you, Mitch. Good to be here as well.

    Ashley: And we’re talking about security and DevOps, DevSecOps. But before we get to that topic, would you tell us a little bit about yourself, let our audience know a little bit about ZeroNorth, too?

    Worrell: Sure, I’d be happy to, Mitch. I’m John Worrell, CEO of ZeroNorth. We’re in the DevSecOps space, maybe with a different approach that, a lot of times people focus on tooling. We believe that you need to kinda build a process out first for DevSecOps to actually have business value, and I’d like to maybe talk through that with you, Mitch.

    Ashley: That’d be excellent. I’m all about the business value, too. [Laughter] So, let’s talk about that. So, usually, when you say DevSecOps, it’s about shift left, how you need to get to the security people working with the software folks, how do you help developers write more secure code? You get to the tooling conversation.

    So, I think you’re talking about—well, let’s stop for a minute and ask why are we doing all that stuff? Yes, let’s create better app security, but why do we need to make this a process that produces, maybe, some business value, measurable results, those kinda things?

    Worrell: Yeah, you bet. That’s exactly right. We’re all for the tooling, we’re all for building the bridges between security and the Dev teams. But you have to have an objective in mind, and you have to have some help along the way. You have to have some data along the way that’s gonna actually get you there to pull all that together.

    One of the best quotes I ever heard that got applied to this was channeling your inner Deming, which is, you know, if you can’t describe what you’re doing as a process, you don’t know what you’re doing, right, and there is a real lot of truth to that. If you step back and look at AppSec over the years, it’s been very tool-centric, very sporadic, anything but a process. When you look at DevOps, it’s a process, it’s repeatable, it’s scalable. It’s kind of a self-learning or positive flow of information with telemetry so you can get better and better at it over time just by learning from your past experiences.

    And when you think about integrating security into Dev to drive DevSecOps, you have to think about it the same way, and I think that’s where it all starts. This is a process, this is not a tool selection, this is not just a scan or an integration, it’s that process that you need to build first, and then you can start building out your tooling, your technology underneath that.

    Ashley: You have a really good point, and if I’m being over general here and generalizing this, as security professionals, we kind of think of, “Let’s buy boxes, let’s buy software, let’s put functions into the network, into software, and not into the software development process that will solve our security problem.”

    But security is not just people attacking you, it’s also how you do your work and making sure you create a secure environment, you operate securely, write secure code. So, I think you’re spot on about the process and how you can do that consistently, referring back to Deming, right?

    Worrell: Yep.

    Ashley: You can’t manage what you can’t measure, your adaptation of that phrase. So, talk to us a little bit about how do you make that real? When you talk with people, how do you help them sort of elevate the conversation to that and then get on the right track?

    Worrell: So, I think it starts out with that process conversation and whichever analogy you’d like to us for that. Think about it this way—the process, in our view, works like this. You’re gonna set some kind of a governance standard for your organization. You can’t have each Dev team setting their own or each business unit setting their own, you’re gonna wanna try to get global visibility so you can actually have effective global risk management. And we’ll start that as a kinda catch-all for the business objective—but in a sense, that really captures what we’re trying to do with DevSecOps. You need global risk management across your organization. That means you have to have some visibility into it, but you have to have a way to impact your current state to make it better, and you need a process to drive that in a continuous way.

    It starts with setting some governance standards and saying, “Okay, what is our ideal objective for our top tier applications? What is our ideal objective or governance model we wanna put around our mid-tier?” or whatever the application categorization might be. Then you wanna make sure you’ve got a continuous process to build the data that’s gonna inform you, whether or not you’re actually meeting those objectives. You have to look at performance reporting so you can measure how you’re doing against that. 

    And then you have to be able to action that intelligence to say, yeah, that data is helpful to me for a number of reasons. Number one, I get visualization of risk, I can get prioritized remediation if I do this right so my developers can make intelligent business decisions about which vulnerabilities get fixed now before we progress the build and through the build. The third piece of that is, which teams need what kind of training on security coding, good security coding practices? Instead of trying to treat everybody the same, use this telemetry to say, “You know what? Team A is struggling with cross-site scripting. Let’s go do a lunch and learn with those guys and watch the immediate impact we’re gonna get from that” and then let the process continue and go all through. There’s a lot of technology in there, there’s a lot of things in there, but it starts with the process.

    The next piece that’s really critical is the data that comes out of that, right?

    Ashley: I was just gonna ask you about the data part of it. [Laughter] 

    Worrell: [Laughter] That data drives everything. It drives so much. You know, we had talked about this idea that you’ve got different tooling—well, sure you do. You want the best tool that you can get, you want best of breed. But trying to pull those tools or the data from those tools into some meaningful, actionable intelligence is a key step in the process, right? You wanna take different data points and put them together so you get a complete view of what the risk posture is for that particular target or entity or application you’re working with.

    We talk about the analogy of the blind man and the elephant. You have four blind men all experiencing an elephant from different places, and they all can come up with a different understanding of what they’re really touching and trying to investigate. And it’s a perfect analogy for a multi-tool environment when you’re scanning across the pipeline that, if you just look at one experience or one tool, you’re not gonna get a complete view of what’s going on.

    Imagine the difference of being able to just do static scanning and realize that you’ve got all these highs and criticals, but not compare that with your dynamic. So, a lot of those highs and criticals may not be exposed in my environment, right? I wanna pull those together.

    I’m trying to understand, number one, where the risk is, but I’m also trying to optimize my developer productivity and making sure they’re not fixing a bunch of stuff that doesn’t need to get fixed, if I’ve got a compensated control in place or it’s just not exposed already. That’s not high on my list. I want to really focus in on what’s valuable.

    So, that data can be used for making good business decisions on risk. It can be used for prioritizing remediation. That data can be used for, you know, call it the wall of fame, wall of shame. It’s how do you really measure and incent and reward your business units for meeting their risk management targets, right? Again, how do you help those that are lagging behind, how do you help them get better?

    And that, to me, built into this process, is where you get real business value. You’re getting the faster delivery of software, you’re getting the better developer productivity out of this, you’re getting that risk management layer and visibility you need, but you’ve got it as a process, and you can measure week to week, month to month, quarter to quarter, how much better you’re getting at it. That, to me, is a real business solution.

    Ashley: You know, you described a lot, so let’s unpack some of those things. The third piece of it usually is, you know, you talk about people process and technology people. What are the kinds of roles of people who are gonna be using that kind of information, that kind of data? Because we’re often talking about getting security information into the developer’s hands so they can fix things, but you’re also talking about, “Well, what should we fix? Let’s not waste our time on things that don’t matter, right? The environment secures against cross-site scripting, so let’s not worry a much about maybe that as something that can be exploited.” Who uses that information?

    And then I guess the third part of it is, it’s about continuous improvement, that’s a cyclical process of, “Are we getting better? Are we getting value? Is there benefit to the work we’re putting in on this?”

    Worrell: You bet. So, you’ve actually said a lot there, too, so, I’ll try to—

    Ashley: I did. I’m just following your lead, John. [Laughter]  

    Worrell: Yeah. [Laughter] Good, we can confuse each other in this whole process.

    So, you know, if we start with this idea of the continuous improvement, just kinda going backwards here, the whole goal is to have that process, which is a continual healing process, if you will, you’re always gonna get better. DevOps does that with telemetry about, “What is the productivity of my developers? What are my key metrics on how many story points I’m taking down, how many am I delivering, and am I getting better, sprint after sprint after sprint?” All great stuff—the same model plays out in security.

    That ties back to one of your comments about the role of the CISO. You mentioned, you know, typically, security guys, via technology, they deploy it. And that works or a proactive control, which is what security’s been doing so much for. My days of running the product for RSA SecurID and working at CyberArk and any kind of blocking technology or control—it is. You buy it, you deploy it, you set it and forget it, for the most part, and it works, right?

    By the same token, this isn’t really responding on the SOC side, either, right? This is not responding to an in process attack, this is a different approach to security. And I think the reason that’s important is, number one, businesses are demanding more business metrics, business telemetry out of their security programs, what am I getting for my investment? How do I know I’m investing in the right things? Am I spending in the right places? All of those things are really important, right?

    And the role of the CISO, by definition, is evolving as well. And you can see the people that were running security teams 10 years ago are very different than the model who’s out there now. Many people have grown into that role. Other people have come from the business side of the house, and they’re not the technology experts that were good at configuring firewalls that were really trying to deliver business value to the organization. And if you’re gonna step from infrastructure into the world of application security, you need to be able to have value to the business, and this data is a great way to deliver value to the business.

    Ashley: Really important point, because the CISO role is evolving, and oftentimes, it’s becoming a CIO/CISO kind of role, which means you’re getting into the application stack, not just the network stack. Not saying that they weren’t worried about the app stack, but now you’re getting much more into the nitty gritty of it. And are your security people software people? Well, not necessarily, but they are very accustomed to getting data and responding to that data, and in this case, maybe helping development teams, developers, others with understanding what the true severity, not what some scanning tool might say, right?

    Worrell: You bet.

    Ashley: Which is sort of our history with vulnerability management, [Laughter] to really help them understand, “Okay, great”—and then demonstrating to the business, to compliance, to whoever you may need to be reporting to, it could be customers as well, to say, “Here’s what we’re doing. Here’s the actions that resulted from investment in these tools, people, and processes.”

    Worrell: And that customer angle is actually really important. And I hate to use the word SolarWinds, but I’ll use it. It’s just put, yet again, a big spotlight on software supply chain, software security, and how critical that is. And so many organizations now are asking of us, as well as our customers, “What is your software development process? Prove to me you’ve got one.” Right? Great use of this data.

    When you think about your business line risk owners, the people that are actually responsible for data, they work for the GM or the SVP of that business unit, they’ve got the risk management challenge. They need this data to do their job well. If you take that data to the board, our data is being used as part of the quarterly board package to talk about how they are addressing and how they are improving the risk posture of the organization.

    And then, I wanna go down, really, one level deeper. Because when you think about this, you know, integrating into the DevOps process means that it’s not necessarily just about the developer making that independent decision. Typically, there’s a product owner in there some place that’s gonna be making some decision about what’s gonna get done now versus what’s gonna get done later, right?

    So, being able to feed that product owner with the data they need to help do the triage and make those decisions, that’s another great use case of this data we’re pulling together.

    Ashley: You know, you mentioned a lot of roles, too, including the product person. In your experience with ZeroNorth—and I really appreciate your background in security, too, so we can relate about those days as well—what’s most often, when people come to ZeroNorth and say, “Hey, we need your help, here’s what we need your help with?” Is it the software team, is it the product team, is it the compliance group, is it the CISO/CIO? Usually, what’s that initial driver for engaging with you.

    Worrell: Yeah, there’s probably two different ones we hear most commonly. One is, “Hey, I’ve got a somewhat mature program, I’m running two or three different tools. I can’t make heads or tails out of the data, or if I try to do it, it’s manual, I can only do it once a quarter or once a month, it’s just too labor intensive. So, I think I’m getting good, I’ve got a decent process right now for scanning, but I wanna start pulling that data together.”

    The second use case is those that wanna start out on building what we would call a federated or a shared governance model, and it’s led by the security team, perhaps, but they know they’ve gotta bring in the business line owners into this process, or business line risk owners into the process. And they say, “Hey, can you help me get data out there so I’ve got a single source of vulnerability truth or my applications?” And I’m looking at the same data that they’re looking at, we’re all making decisions off that same set of data so we can build a governance model that makes sense. 

    The security guys wanna work in partnership with the business owners and the people that are actually doing the software development and risk owners in the business. But that relationship is gonna get built on having really good data and everyone using the same data. I think that’s another use case.

    The third one, which is a variation of that, is people that are coming in and really saying, “Hey, listen, I need to go to full DevSecOps right away. I know that I can put this layer of reporting and analytics on top of my current tooling and that’s a great start, and I’m gonna build this over time.” It’s a fine strategy. Other people are coming in because they’re just getting started or they just have a business imperative to do it and they’re saying, “We’re going to DevSecOps right now, and we wanna do the pipeline integrations as well as the reporting and analytics that we’ve been talking about so that I do get that data in real time, I do have a consistent scanning process, it is automated, I don’t have to worry about the developer forgetting or not doing it, and I’m gonna get that data value out of this in that particular way.” 

    Ashley: Yeah, “Help me accelerate through the learning curve instead of making all those mistakes myself to get to DevSecOps, if you will.”

    Worrell: You bet, you bet.

    Ashley: That second example especially kind of is a multiplication of the first one, which is, you have Dev teams with all this data, maybe it’s the primary group—usually, it’s multiple, right? How do you pull it together into something? They can’t make sense of it. How do you do that across the enterprise to meet compliance requirements or even just your own internal assessment and reporting up the management chain maybe to the board.

    Worrell: You bet. If you step back, the biggest concern we get out of just about everyone we talk to is a CISO or a Risk Manager saying, “Hey, help me, I’m flying blind. I don’t know what highs and criticals I’ve got in my production environment right now. I just don’t know. I don’t have visibility into it. And for me to get it, it takes too much effort, and once I get it, it’s outdated, because it’s 30 days old. I’m pushing code every day” or every week or whatever it might be.

    And that is the primary motivator or so many people who just say, “Gimme that visibility, and that’s the starting point. And then at least I know what I’m dealing with and then I can start building out a program that’s gonna help me address that over time.”

    Ashley: You know, you brought up SolarWinds, so I’ll bring up COVID. What have you seen happening over the last 12 to 18 months with the acceleration to the cloud, acceleration of digital transformation projects? Has it taken these same issues and just made them even more visible critical to address, or have new problems emerged?

    Worrell: I think it’s more of an acceleration of the entire process. In general, COVID has driven people to be more comfortable or more reliant on relationships with their customers, with their partners, with their employees. And that means more software, by definition.

    So, as digital transformation accelerates because of more online interaction and new business models that this opens up, it’s just really accelerated the pace and some of the maturity of people coming. The types of questions we’re getting from our prospects now are much more advanced than they were a year ago. And that just shows that the market is really getting smart about this and they’re kind of moving beyond the tool only approach to say, “Okay, how do I get some business value out of this that can really, really help us move our risk management program forward?

    Ashley: That’s one of many indicators I see, kind of data points that are saying the technology groups, the software groups are getting out from under, looking at themselves and starting, trying to get aligned with the business and meet where the business is headed.

    Worrell: And as a big consumer of software, as we all are in our lives today, I’m really happy to see that, right? I mean, that’s what I—I know it’s gonna take bringing the two together and working cooperatively in that federated or shared model to make this work, and I’m really happy to see that kind of a progress. Because, like you and everybody else, software just drives so much of our daily experience.

    Ashley: It is. Can’t do much without it these days. Well, it’s been great talking with you, John. Where can folks learn more about ZeroNorth?

    Worrell: Well, that’s easy, ZeroNorth.io. We’d be happy to talk to you. Take a look, see what we have, and if we can help you out or you wanna hear more about it, we’d love to chat with you. Thank you very much.

    Ashley: Yeah, I think we’ve had a great conversation. Hopefully, that’ll spark some folks to elevate that conversation with you and the ZeroNorth team, so take care, we’ll talk to you again soon.

    Worrell: Thank you, Mitch. I appreciate it.

    Ashley: You bet.