devopsy.kinsta.cloud

Category: DevSecOps

  • DevSecOps: Bringing Compliance to DevOps

    DevSecOps: Bringing Compliance to DevOps

    In today’s fast-paced business environment, the division of DevOps and SecOps must be bridged to create DevSecOps

    Now that the “X-as-a-service” model has taken hold, enterprise infrastructure, integration and solution delivery has accelerated rapidly. Waterfall methodology has given way to the Agile framework of rapid, continuous development and delivery. This necessitates the use of automation to speed QA and change management.

    In the midst of all this change and activity, a deeper goal is to make security and compliance part of the dev process from the ground up. For this to succeed, teams must take on a DevOps mindset regarding these aspects—one that places a priority on fast delivery and automated workflows.

    The tricky part is that DevOps and SecOps/compliance thus far have had different priorities.

    DevOps focuses on things such as policy management, monitoring, code inspection and risk mitigation. SecOps needs to anticipate risk and ensure controls are retroactively mitigating compliance and security risk. The inherent conflict comes from a traditional view that security review should come after software development as a final check, but instead ends up becoming a fractious process of reconciling necessary controls into the release cycle.

    Because there is a natural tension between DevOps and SecOps, as they have different charters and cultures, bringing about the idea of shared responsibility can be difficult. DevOps can be seen as more of a do culture (Atlassian calls this a “do-ocracy”) and SecOps can be seen as a control culture and they are inherently in conflict. To fulfill the promise of teaming for shared responsibility, DevOps and SecOps should align on three key objectives: collaboration, communication and integration.

    The Benefits of Collaboration in DevOps

    Emphasizing collaboration between an organization’s operations, development, testing and support teams is what DevOps is all about. The focus is on reducing time to market and improving agility through rapid development and rollouts. However, before the process of development can begin, you need to start with a plan. At the planning stage of development is where security and compliance can start to be incorporated.

    Organizations need to build a system of record that can implement and orchestrate the SecOps portion of the development plan. Policies and controls can be widely disseminated across product and engineering teams to document the intention of controls, define their implementation and enable teams to collaborate with comments and feedback in one hub.

    Closing the DevOps Communication Gap

    There exists a communication gap between the security function and the rest of the dev organization, and it is critical that security practitioners bridge that gap. Compliance and security can be viewed pejoratively by other teams because people don’t understand them or see their relevance to users’ lives. But this, too, can be changed.

    For instance, it’s better to talk about a security risk in terms of project delays and unplanned, unscheduled work rather than talking about a breach or a vulnerability. When speaking to operations teams, it’s better to talk about availability and user privacy requirements as correlated with mean response time or system uptime rather than a data breach. To succeed in a world that’s moving at the speed of DevOps, security groups need to be able to articulate control requirements in both the language and tools that DevOps lives in, such as Jira and GitHub.

    Integrating Sec Into Dev

    For security practitioners, the most radical process departure here is often the high degree of automation and workflow tools in DevOps. The critical success factor for integrating security and development operations is to make control implementation easy and clear for developers to follow. For example, if the team is working toward a SOC2 security certification, then a clear control framework broken down into tasks and issues will ensure a smooth integration of security into the dev cycle. A SOC 2 attestation will also require evidentiary verification that controls are implemented throughout the software development life cycle (SDLC), including release cadence. The final critical piece to achieving readiness for a security certification is to have integrated risk assessment, controls gap analysis and audit-ready evidence for your observation period in one central place.

    DevSecOps: Greater Unity, Stronger Security

    In a world where everything is offered “as a service,” the pressure is on to iterate quickly and non-stop. To make this possible, the DevOps methodology relies on the speed that comes through automation. But security is sometimes overlooked in favor of speed. That means security needs to automate, as well, to keep pace with continuous delivery. The division of DevOps and SecOps must be bridged to create DevSecOps.

    Understanding the benefits of this collaboration will go a long way toward easing the transition, as will learning how to communicate those benefits in a language that appeals to all stakeholders. What will enable the collaboration is an orchestration and demystification of security and compliance for the entire dev team. When DevSecOps is straightforward and simple for developers to integrate security, there won’t be a reason not to, and your product and organization will be more secure.

  • Shifting Left and Static Code Analysis with Perforce

    Shifting Left and Static Code Analysis with Perforce

    Perforce Product Manager Stuart Foster, and Evangelist Steve Howard, join Mitch Ashley to discuss the importance of creating security software from the beginning of the development process. We discuss shift left, SAST, source code scanning and other pursuits towards this goal.

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

    Transcript

    Mitch Ashley: I’m pleased to be joined by Stuart Foster, who’s product manager with Perforce, and also Steve Howard, who is static code analysis evangelist, both with Perforce. Welcome, gentlemen.

    Stuart Foster: Hey, Mitch, how are you doing?

    Ashley: Very good. How about if we—let’s start off with just a little bit of an overview of Perforce, and then, Steve, why don’t you do that and also tell us a little bit about yourself, and then we’ll toss it over to you, Stuart, to give you introduction.

    Steve Howard: Right, yeah. Well, here at Perforce, really, our role as we see it is to help developers write better code more efficiently and more quickly. So, these days, we tend to talk about DevOps and the whole idea of developer operations and how they put that code together, how it’s constructed, how it’s managed, how we control the processes around it as well, of course. There’s more and more regulation, it seems, these days in software development and we’re making that whole process from start to finish, of writing code to delivering it, that whole cycle. It’s hopefully being made easier, more comfortable for our developers that use the products.

    So, that’s really where Perforce sits, and we think of that is really enterprise DevOps, and doing it at scale in large scale organizations.

    So, my role, really, is specific on the Static Code side or Static Code security testing side, SaaS tools, if you will, trying to make sure that that piece of writing the code, actually developers writing the code itself is done to the highest possible standard from both the security and the quality perspective and also, at the same time, getting maximum productivity from our development teams.

    Ashley: Wonderful. Stuart, introduce yourself?

    Foster: Yeah, absolutely. I’m Stuart Foster. I’m the Product Manager or Perforce’s Static Analysis products, both Klocwork and Helix QAC. So, I work with Steve, he’s kinda my partner in crime, amongst a number of other sales engineers and developers and everything, and we’re just out to produce a really solid static application security testing tool.

    Ashley: Excellent. Well, one of the great things about talking with you both is, since you have products in market, you talk to a lot of customers, especially in an evangelist role, too, Steve. It really helps us kinda get an idea of where the state of security is in applications, what people are doing today. The whole idea of shift left, I think, has evolved a great deal. I think when I first heard it was “move left in the workflow.” And then it became, “Well, move the when the security people get involved.” And you’ve really taken it much farther than that to really thinking about how we start writing secure code.

    Maybe one of you could kinda give us an idea of where you think we are as a community on getting to that point of when the code’s written, it’s written securely.

    Foster: Yeah, so, I mean, from my perspective, you know, you kind of look historically at people using the term shift left and, you know, from our perspective, that would’ve been, you know, doing some sort of code analysis on a server and then moving that left in terms of the software development life cycle into the developer’s IDEs.

    What you see nowadays is that, you know, historically, a lot of those responsibilities would’ve been siloed. You’d have a security team, a QA team, various other teams that, in many ways, because they’re siloed and in different stages of the process, you’d run into kind of bottlenecks. What you’re seeing a lot more with the concept of DevOps, DevSecOps, a lot of development teams themselves are becoming owners completely of the code that they write. And what I mean by owners is that, you know, they are writing unit tests, they’re writing more functional tests, they are ensuring that it’s part of their responsibility that the code is secure. 

    So, that’s a shift left, but then you have to think how developers work—they’re working in IDEs, they have their own CI/CD pipelines, they may be using cloud services, various containers that are all getting spun up and broken down. So, it’s not just, to me, shift left any more, it’s analysis anywhere. It’s basically having something that can work anywhere in a workflow, right? And in this sense, you know, the Security teams still exist, the Quality Assurance teams still exist, but what it really is, is a culture of security collaboration that are coming together, right?

    Steve, I think you may have a little bit of a perspective on this, too.

    Ashley: Yeah, I’m interested in your from the field perspective, too.

    Howard: [Laughter] Yeah, no, it’s—well, it’s exactly that. I think it’s a really good point that no, we’re not just talking about moving to the desktops, we are talking shifting left throughout the whole cycle. I think that is a key point. And it is really an opportunity using tools like ours in Static Analysis security testing, it’s about being able to enforce the requirements and the needs from that expert security team where there were bottlenecks previously, trying to put that into rules and regulations that we can then push down to the development tasks and processes that are to the left of that kinda final sign-off.

    So, yeah, that—in that form, very much, I’d say it’s shift left, and it’s about that optimized process now where we can be doing that checking all of the time. So, it’s making sure we’re continuously compliant to those security requirements or quality requirements, as the case may be, yeah.

    Ashley: You know, it’s interesting, we talk about the workflow and we think about the whole tool chain and pipeline, but if you really break it down into much more granular pieces, developers are working on a linear piece of development, right? They’re in multiple places jumping back and forth, solving bugs, adding features, developing new capability—whatever it might be. So, the ability to concentrate on any one aspect of an application, sometimes, is not even possible, right?

    So, you need an environment where you’re aided in how you write and create secure code as well as think about writing secure code. You agree with that?

    Howard: Yeah, absolutely. I think that’s the point. We’re trying to make sure that all of those pieces that they’re working on at different times and, you know, our colleagues in the Version Control System team know this very well, but obviously, there are tens or hundreds of branches running in parallel, as you’re sort of saying, and developers are jumping between, you know, fixing problems on the current release, maybe, and then carrying back on with their feature work for the next release as well. 

    And all this time to try and manage what security requirements each one of those had or quality requirements as well would be a really nightmare without sort of tooling and regulation around that, around the whole process, which is a significant part of developer operations as a whole, the idea of automating a lot of that and building it into the system. So, I think it’s just enforcing that with making sure we’re adding all of the extra pieces that we can also include in those processes.

    Foster: And also, if you think about those developers, too, they’re experts in their fields or experts on some of the functionality that they’re developing, but they’re not also necessarily experts as a security team might be, right? So, part of the trick, too, is to offer kinda help, knowledge, learning via the tool set so that, you know, the developers can keep the velocity up and develop to those standards more easily. 

    And I think Steve mentioned a little bit of a buzzword that kinda we like to think about is, it’s continuous compliance, right? It’s having this throughout the process and enforcing it and continuously monitoring, remediating, fixing, and reporting that become important for these processes to run really cleanly.

    Ashley: You know, it’s interesting, there was—kinda stepping back in time, and again, I think about the myth of developers don’t wanna, don’t care about writing secure code. Well, of course, they do. They don’t wanna write insecure, vulnerable code. But I think there’s a period where we thought training was—you know, let’s teach them about how to avoid writing code with vulnerabilities in it.

    But when you talk about a continuous governance environment, you’re kinda talking about a whole layer of things, right? It’s from the person doing the work to the environment that it’s being checked in and integrated and being tested into the workflow, and then really, the data, the information about that, that’s happening on a continuous, ongoing basis. And that’s really your data set for producing the compliance information, right? We don’t have to go ask you or check your code, it’s already been done, it’s done every step of the way all the time, and here’s the evidence of it, and here’s what we learned from it and here’s where we’re doing well and here’s maybe where we can improve. 

    That’s how I think of continuous compliance. Yes, it shows up in a report down the road, but it’s continuous, because we have all that data.

    Howard: Yeah, I think that’s a really important point from the efficiency as well. I mean, the Security team or the Development Management that want to know when this product or project will shift obviously need to know where they are relative to that compliance requirement. And if we can keep it compliant from day one, we don’t ever have that risk of building up technical debt at the end of the process that we then have to solve, and I think that’s a really important evolution that we’ve seen over the last few years, that we have that knowledge to hand immediately at our fingertips, as you say. So, that’s a really important piece.

    And the other point you made there about the developer education, I think, again—yes, you can teach developers and I know myself, in the past, I’ve learned the right way to do things, wrong way to do things, but there’s nothing quite as good as actually showing the examples of when things are potentially risky within the code you are writing, because you really understand, at that point, what you’re writing and how this could then be a problem, and it is the classic on the job experience that you really want for a perfect education, almost.

    Ashley: Let’s take—I’d love to hear your kinda definition or how you describe Static Code Analysis SaaS to people about, if you’re embracing that, what does that mean to a development team, to a software project team?

    Howard: I think from my perspective, it’s the idea of having an automated code reviewer, almost, looking at the work you’re doing in a fairly pleasant and passive way. [Laughter] Not being critical in any way, shape, or form as well. So, from a cultural point of view, I think the developers perhaps accept it more when it’s from a machine rather than a colleague that perhaps is picking holes in the code they’re writing, which is another good point about having a computer do that initial check.

    But yes, it’s like having that guard at the end of the process, and then we often joked historically about the value of the tools and saying, “Well, you know, if you had two developers that were both going for the job, you know, you’re advertising for a new development role, and one of those developers is, you know, the cost of the license is more, but they never make a mistake in the code, they check in clean, compliant code with every commit, whereas the other developer, they both have the same experience, they’re both writing good code, but the other one could make mistakes and could check in, potentially, security vulnerabilities. Which one would you pick as a manager?” That’s quite an interesting way of looking at it, but of course, you would always want to have that assurance that, essentially, it’s clean code from day one.

    Foster: Yeah, and also, you know, in terms of the perspective, Steve talked a little bit about the developer perspective or the hiring perspective. From the business perspective, you have to think about the costs of reputation, lives, revenue, anything of a product being in the field and discovering an issue. You know, the costs to fix a bug exponentially gets more expensive as you go further down the software life cycle, right? So, it’s cheapest to fix it then and there, right at the start. And, you know, in terms of kind of pain points that the software is trying to fix is, you know, providing that knowledge, providing that quick remediation as developers are working, ensuring the velocity stays up, ensuring that the continuous compliance enforcement throughout the process means that there’s not a heavy lifting of work later in the process, because you know, you weren’t reaching compliance requirements. 

    You know, the ease of using the software however a developer wants to work, it’s all about velocity, you know? And in terms of the business having that oversight and understand, you know, what are our risks, and how soon are we gonna be able to ship this product? Because, you know, we know with many products, the faster to market you get, you know, you have that first mover advantage, and that’s what’s needed in this fast-paced software market.

    Ashley: Well, that’s very tough to recovery from reputation damage and quality issues or perceived quality issues around your products, too.

    You know, one of the ways that I explain it to folks outside of being a developer or within the security world is, it’s kinda like taking your spell check of a document and adding in the grammar checking—so, this is the higher order, more complex, specific things around grammar. In this case, it’s around security and helping you as you’re developing or creating code, right, make sure that you do it the best way, you know? Avoid introducing security issues.

    I know that’s a gross oversimplification, so don’t worry, I’m not saying Perforce is like a grammar checker. [Laughter] But that is sort of a non-technical way of describing what we’re doing. I mean, we want it to be that natural, as part of the process.

    Howard: Yeah, absolutely. And I think that’s very true. I think, you know, we’ve seen the evolution of Static Analysis tools very much in the same way we’ve seen the evolution of things like the Microsoft Word, you know, spell checker to grammar checker and so on, and it’s kind of evolved to be more and more all of the time, you know, of the systems similarly.

    But on top of that, there’s also the opportunity, then, to, what we find quite interesting is to write your own checkers and rules that are specific to your application. So, we can find in some places where there have been security problems in a certain application for some special reason—not necessarily related to the constructs of the code, as most of the coding standards check, but something that’s specific to the project because of the way the project has designed all the code, and that project interacts with outside external interfaces. 

    And it has been interesting to work with customers in some cases. I worked with very large telecom customer on one occasion and he said, “Well, you know, we have this translation module between sort of the application and the platform, and nothing should ever, you know, go direct between the two unless they’re going through this one piece in the middle.” And it’s kind of the golden rule we’ve taught to all the developers from day one and nobody will ever break this rule.

    So, you know, obviously, I was slightly challenged by this and said, “Well, it’d be nice to check the rule. Let’s put that enforcement in just to see if we can, you know, use a custom rule to see if there are any cases and, of course, as you say, it should be clean.” And obviously, you know, a couple of hours later, once the analysis is run, it’s a very big system, we found a couple of cases—only a couple, but there were a couple of cases where exactly what they said should never, ever, ever happen for the security of the entire system, it happened. 

    And so, we were able to then remediate those problems and keep that rule in for future development, and of course, it will always be enforced. So, that was a really interesting case where there was also that, where you have something specific, it’s not just generic grammar issues, if you will, or spelling issues, but something very specific to that document.

    Ashley: Mm-hmm.

    Foster: Yeah, you can imagine some of these things coming out of requirements or an internal coding standard or things that a Development team might be following and be able to enforce these. Especially when you start looking at legacy code, giant monoliths, you know, that have been around for 5, 10, 15, 20 years, decades, you know, and you don’t have those original people who are developing, right?

    So, you know, it’s—we sometimes think of our tool also as, you know, kind of like a quality assurance on a product or a code base that, you know, it’s legacy and all the new people have no idea how to use it, but you need to expand on it, you need to develop it, because it’s valuable IP, and how do you manage developing new functionality and moving forward when, you know, it could be as brittle as a glass house, right?

    So, you know, that’s the other benefit you get out of being able to enforce and write your own standards, I’ll call them, and rules, yeah.

    Howard: Another classic case there, Mitch, is—and you’re well aware of this as well from the field is, this system was never intended to be connected to the Internet, you know? This was something that—

    Ashley: [Laughter] You’re guaranteed it will be, then.

    Howard: Yeah. [Laughter] It was an embedded system that was entirely supposed to run in an embedded environment with no connection to an outside world at all, and all of a sudden, you know, it or something around it that’s connecting to it is now connecting to the outside world and there’s open attack interfaces, and now we have to make sure that they’re not gonna compromise the original legacy code base.

    Ashley: Mm-hmm. Yeah, there’s just sort of the rule of unintended uses always occur, right? The thing we don’t want to happen is usually what happens. [Laughter] So, yeah, the demo becomes the production system is another great example.

    I’m really interested in your perspective on where you think we are. If I made an analogy to the network security world, the best time to be a network equipment or network security salesperson is the day of or the day after a compromise, and automatically, you’ve got budget and we need to solve this problem. I mean, I think we’re well past that in most cases, but where are we in the software world? Do you see this as a, it’s just a natural thing, “Okay, what’s our SaaS strategy, how are we gonna be doing security within the application, what tools should we use for that?” Or is it something where you have to mature to a certain point or have experienced some issues before you’re really gonna take it seriously? 

    Where are development—and I’m asking for a generalization I know, but what’s your sense of where people are today?

    Foster: I’d say, you know, in general, it seems as though most people don’t take these kinds of things seriously until it bites them. I think, you know, there’s some kind of safety feelings of some types of products that you can use where, you know, you find out about a security vulnerability or intrusion and you’re using a piece of software that basically just tells you that, you know, the barn doors have been opened and all your horses are gone, right? But that’s too late in the process. I think we all need to understand that, right?

    So, the point of dealing with it sooner and using tools like security application and security testing tools like Klocwork or QAC is that, you know, you’re trying to build the risk reduction, the known unknowns that you can at least deal with sooner, right? So that, you find out later, in the worst case, that the doors were open, but, you know, nothing happened, you still have your horses, because the stables didn’t open at the same time or whatever, right? Just to make a kind of analogy to it, there.

    Howard: Yeah, I think in the—obviously, we do a lot of work in the embedded space, and in that area, having seen it over the last 10, 15 years, I think, you know, there was a time where we were educating people a lot more about what it was, you know, what it was that we could do with Static Analysis to actually find some of these problems. Whereas I think—and there’s a lot more awareness now of the risks in the security field and, obviously, what Static Analysis can do to help. So, most people are starting to think about it if they’ve not already got it built in.

    So, I’d say it is becoming more of an expected insurance policy against those kind of things within the tool environments. And obviously, the other kind of driving force there is the regulation. So, we’re starting to see standards themselves creeping into the market like the new ISO 21434 standard for automotive, for example, where they’re actually going to require some level of looking at the security of the system and making sure that we’ve done some of those things correctly and, you know, probably that will include what we expect it to include, some level of Static Analysis and coding standards and so on and so forth.

    So, that stuff is really becoming almost regulated into the process just like functional safety regulation has been in that process from the beginning.

    Ashley: Definitely.

    Foster: Yeah, you’d imagine—

    Ashley: Sorry, go ahead.

    Foster: I was gonna say, just on that topic there about cyber security for automotive, you think about it, the cars are effectively rolling entertainment systems, right? So, there’s a lot of new kind of vectors for attack, right? An insecure Bluetooth module inside a car and its infotainment system that is also connected to the bus controller that’s driving all the data from every sensor on the car that’s controlling your fly by wire driving and your fly by wire steering and all those things, right? It’s very important—very important.

    Ashley: And usually, you have, I believe, you know, both cars and trucks that have starters can start by Bluetooth as one of the mechanisms. So, yeah, you have potentially the same attack vector, you need to be able to isolate that, and now you’re into the function of the engine versus the entertainment system, and there’s a lot of work going in, I know, to the automotive systems. They’re very complex. I mean, just as complex as many, you know, many business applications—maybe even more so because they’re integrated from so many different suppliers, and they are, of course, largely based on, built on embedded systems.

    It seems like embedded systems, though, are much more accepting of an update process, of keeping the software current and requiring some way of being able to update software in an embedded system or maybe making it an automatic process so it’s kind of touchless. Is that your experience as well?

    Howard: Yeah, I think so. I think that is coming into many systems now. I mean, there are certain manufacturers driving that kind of process—automotive, for example, is a prime case. And it is interesting, because if you go back 10 years, that just was never even considered. You know, once you kind of flashed that system, it was staying as it was until you climbed up the mobile phone master or whatever it was that the embedded system was doing and flashed it again with the latest version. So, yeah, it is, the over the air updates is creeping in, and that will lead us to a more continuous delivery type architecture with the delivery of the software as well, that we’ll be able to go to that.

    So, yeah, it’s gonna be an interesting time. And as part of that, I guess now the focus has moved slightly from the cost of fixing an issue out in the wild to just, we don’t want to have the issue because of the potential impacts on having that issue even for a day, you know? [Laughter] The idea that a car might be possible to take control of from an external source, for example.

    Foster: Yeah, and I think you’re seeing a lot more emphasis on the security around a lot of these embedded systems because a lot of them are so, you know, requirements driven, compliance driven. They have ISO requirements that are needed to be validated by external bodies to make sure that these things are safe to use, because you know, a lot of our infrastructure is built on the backs of these things, that they’re, in some ways, leading the charge of seriousness for these reasons, right?

    Ashley: Mm-hmm. And it seems, also, that industries like, I mean, we were talking about the automotive industry, are putting together their own standards, I think in part of fear out of, “We don’t want government standards to dictate to us, we’d rather us solve the problem, you know, industry solve it” in a way that they’re more accepting and flexible to them. But do you see more regulation coming at a kinda geographical country, government level? Is more of that happening? You talk about ISO standards, of course, being more industry.

    Foster: Yeah, I’d say so [Cross talk]—

    Ashley: You see it happening? Like, our privacy standards, now we’re talking about software security standards?

    Howard: [Laughter] Well, yes, there is that as well. Perhaps in the European level, for example, of something we see on this side, but yeah, mostly, it’s industry standards, from what I can tell that we’re experiencing and seeing come downstream at the moment.

    Ashley: Mm-hmm. [Cross talk]

    Foster: Yeah, I think it depends on the level of kind of sensitivity of the data. So, you do see requirements as they relate to finance and, like, PCI, DSS, and things like that. You see security in terms of—I’m running a blank, here, but they typically come from when the data is so sensitive, you know, the U.S. government has their STIGs, DISA STIG rules.

    Ashley: Mm-hmm.

    Foster: So, it tends to come down from the level of sensitivity. I wouldn’t be surprised if we do start seeing more requirements, perhaps, for public data, but right now, we have things like the HIPAA compliance and things like that, as they relate to very, very sensitive data.

    Ashley: Yeah, the defense industry is also a good one to start to drive standards, too, and I know they’re doing a lot in security.

    So, just to change, shift focus here, we have a few minutes left. We were talking earlier about where people are in their maturity level of adopting SaaS and writing more secure software using those kinds of tools. If you were someone leading a project, maybe an architect or a lead developer or somewhere in the management chain that said, “You know what, we’re almost there, I just need to do a little bit more convincing, or I need something else to help my organization get there to see why we need to do this, and I’d like to do it before we have a major incident”—what’s your best suggestion for kinda doing that? I don’t know if it’s internally selling or if it’s demonstrating the value of it or how do you see people successfully getting the organization to begin to support adopting it?

    Howard: Hmm. I think that’s a tough question, just because there’s so many industries and so many different kind of topics of particular interest, it always helps to have experience of a well-publicized kind of issue [Laughter] that’s gone out into the—

    Ashley: “We don’t wanna be like those people.”

    Howard: Exactly, yeah. That always helps drive things a little bit when you’ve got something tangible to say, “We don’t want to end up there.” I think, again, the regulation piece is where I see a lot of that being driven. You know, the industry bodies are actually saying, “As a whole, the industry doesn’t want to end up there. That’s not somewhere we can afford to be, and so let’s try and make sure we get this right from day one” and that trickles down into individual projects and so on. [Dogs barking]

    Ashley: Well, speaking of dogs [Laughter]—okay, hold on.

    Howard: Okay. Yeah, so, that’s really where we’re—

    Ashley: Okay, just start your answer again.

    Howard: Yeah, so, that’s really where we’re seeing it, predominantly, from the—you know, first of all, we don’t want a case where there is an incident, because, you know, if we can  use that as a tangible case and say, “We don’t wanna be like those guys, because that didn’t end well for them.” So, that’s, obviously, always a good driving force. But then it’s regulation from the perspective of the industry bodies themselves getting together and saying, “We really can’t afford for this kind of thing to happen, and we want to make sure that, you know, across the industry, we start to follow a best practice that’s gonna do our very best to prevent that,” I guess, is a good way of describing it.

    Ashley: It seems this is also an area where security team CISOs can be a real colleague asset for making the case to the rest of the organization, because if you’re _____ on the software team, you have one set of justifications or definitions for why you need that. Another is, there are corporate—you know, the CISO is trying to accomplish these goals, these things with the organization. And it’s always easier to fit your objectives within a larger objective and get that supported and get funding—that kinda thing. So, that’s another suggestion I would throw out there, too, that also helps folks—and plus, it brings security and software teams closer together.

    Howard: Yeah. [Cross talk] Sorry.

    Foster: Yeah. I think we do see—we do see, we do have, you know, security evangelists that are, as you just said, who are championing it, right? And when we talk to those people and we go over Static Analysis with them and this is the security focus, right? It comes down to, you know, being able to help understand their size of team, what kind of current development practices they have, and what that means and how you can deploy, roll out the tools and, you know, not slow down that velocity, because that’s always the goal. Don’t slow down the velocity, but add more value. 

    So, that’s what we try to help them with, help them understand. And also, you know, help—sometimes, you know, Steve is sitting with these people and we almost help them mature in their software development process to, you know, move from a couple guys who are just doing nightlies and they have no version control, they’re not using quality gates, they have no type of automated pipelines to setting them up so that they can scale their development groups, they can speed up their testing, their development processes, and that all comes out of engaging with vendors like us.

    Ashley: Great. Well, gentlemen, this was a lot of fun. I really enjoy talking security and creating secure applications and, you know, it’s something that I think everybody wants to improve at to different levels and degrees, and hopefully, before those bad things happen. It’s always better to do it before, but if you have to do it after, you do. Maybe sometimes that’s what it takes.

    So, it’s been great talking with you. Again, this is Stuart Foster, who is Project Manager with Perforce—thank you, Stuart—and Steve Howard, Static Code Analysis Evangelist with Perforce as well. Take care, gentlemen.

    Foster: Great, thank you.

    Howard: Thanks, Mitch.

  • XDR: The DevOps Transformation of Security Infrastructure

    XDR: The DevOps Transformation of Security Infrastructure

    eXtended detection and response (XDR) is a security technology that unites multiple security systems into one. Organizations are transitioning from traditional systems such as endpoint detection and response (EDR) and security and information event management (SIEM) to XDR, in a move that is analogous to the transition from agile to DevOps work processes.

    XDR can detect threats quickly by automatically collecting and combining information from across the IT environment—endpoints, servers, email and social media messages, cloud and application workloads—giving security analysts the context they need for fast investigation and response.

    In many cases, attacks occur in the borders between security silos. Each silo may be adequately protected by a security solution, but in between those silos, attacks remain evasive because security analysts have a limited view on the environment, determined by their security tooling. XDR connects silos with a unified threat identification and response strategy.

    Just like in the past development and operations teams were responsible for separate silos, with independent tooling and split responsibilities, security teams are split into silos, with limited communication between them. Security threats that cut across silos are difficult to mitigate. XDR enables new organizational structures in which security teams work together, with shared responsibility for mitigating threats, no matter where they occur in the IT environment.

    Benefits of XDR

    The purpose of XDR is to promote the visibility of threats and security incidents throughout an organization’s ecosystem. Its key benefits include:

    • Centralized monitoring and management – XDR solutions provide a single pane of glass for security incidents happening across the corporate network, endpoints and workloads. Consistent security rules can be implemented across diverse IT infrastructure, both in the cloud and on-premises.
    • Unified visibility – XDR integrates security visibility  across endpoints, cloud infrastructure, network traffic, etc. This allows security analysts to understand potential security incidents without having to learn and use other platforms.
    • Fast ramp up – XDR offers built-in integration with an organization’s IT infrastructure, and uses multiple threat discovery mechanisms from a variety of security technologies. Because analysts only need to learn one platform, time to value dramatically increases.
    • Increased productivity – XDR eliminates the need to manually switch between multiple dashboards or tools to collect security data. This allows analysts to more effectively detect and respond to security threats.
    • Low Total Cost of Ownership (TCO) – XDR provides a fully integrated network security platform. This can reduce the costs associated with purchasing, configuring and integrating multiple solutions.
    • Analyst empowerment – XDR provides a shared workflow for all tiers in the security organization. This reduces the need for training and allows Level 1 analysts to perform more in-depth analysis, reducing their need to escalate to higher analyst tiers.

    XDR is designed to give security teams full visibility into an organization’s endpoints and network infrastructure. Increased visibility has many security benefits:

    • Unified detection and remediation – XDR provides centralized and integrated incident response capabilities across all corporate environments. This allows security personnel to quickly identify threats, mitigate them and recover, all using the same platform, reducing the impact on the organization and overhead costs.
    • Better understanding of threats and attacks – Attack indicators are rare and far between, and each one on its own may not be enough for analysts to identify the threat. XDR collects these signals from multiple sources, across environments and over time, helping analysts identify threats that would otherwise remain invisible.
    • Threat hunting – With unified visibility and data analysis accessible to everyone in the security environment, all analysts can carry out proactive analysis to identify threats that have already compromised the corporate environment.

    How Does XDR Work?

    What is the real difference between an XDR system and the traditional toolchain of endpoint detection and response (EDR), security orchestration, network protection and data analysis tools?

    The answer is the language it uses. An effective XDR system should provide a unified, abstracted language to describe security signals, data and security controls. This language clearly specifies the potential security associations of each data point, by adding the concept of an “attack history.”

    The XDR security language removes certain non-essential information, but suppresses noise, revealing high-risk attacks. It does not require expert manipulation, so security analysts do not need to be interpreters anymore—they can spend their time actually mitigating attacks. It is easy to understand, rich with context and content, based on advanced technology, but generating straightforward outputs that make an analyst’s job easier.

    This unified security language is new, because the technology needed to enable it was not available until recently. Here are some of the advanced technologies that have recently matured and power the XDR information experience:

    • Threat intelligence feeds – Now delivered in real-time and with more data and context.
    • Next-generation machine learning – Multidimensional traffic algorithms that take into account signals from many independent data sources, unlike traditional systems such as user and event behavioral analytics (UEBA), which had a narrow set of inputs.
    • Natural language processing (NLP) – Algorithms that can be trained to draw conclusions from security rules, revealing information about threats, security alerts and how they interact with security controls.
    • Reasoning mechanisms – Algorithms that identify causal relationships, allowing the system to aggregate data points and automatically generate an attack story. This is a dynamic analysis, not based on predefined rules as with old-school security information and event management (SIEM) systems.

    Mistakes to Avoid With XDR Platforms

    While XDR is widely believed to be the future of EDR and network security, it is a new technology and there are several pitfalls you should try to avoid in your implementation:

    • High integration complexity – Check the cost and effort involved in integrating the XDR solution with your environment. Maintaining this integration is also costly. For example, if your organization already has a SIEM, integrating it with the XDR system is non-trivial.
    • Time to implement – The adoption time required for an XDR solution is crucial. Organizations are transitioning to remote work, and attackers are using remote workers, unsecured remote devices and networks, to gain access to sensitive data. A detection and response solution that takes weeks or months to successfully integrate into the stack is risky.
    • Limited automated analysis – Some XDR solutions do not leverage the full power of AI-driven analysis, limiting themselves to initial data processing and correlation, which may be better than existing systems, but still require manual work from analysts.
    • Operational complexity – The promise of XDR is to simplify workflows and improve productivity. If the XDR solution itself is too complex or requires analysts to learn new skills, adoption may be difficult and the total cost of the solution increases accordingly.

    An Enabler for DevSecOps

    XDR is not just a technology platform, it is a new organizational model that will help security teams work more closely together, focusing on threats rather than on specific tools or IT systems.

    This ties into a broader movement in security organizations to transition to DevSecOps models, in which developers, security and operations work together to shift security left and integrate security into all parts of the development life cycle.

    XDR technology will make it easier for security teams to act as a whole, and apply security tooling and practices consistently to a variety of environments, from a developer’s workstation to a full production environment. Thus, XDR may become a key enabler for the easier adoption of DevSecOps methodologies in highly secure environments.

  • Speed and Security: How to Find a Balance in Development

    Speed and Security: How to Find a Balance in Development

    Time management can help developers realize the necessary combination of security and speed in application development

    As software continues to create competitive advantages and market differentiation for organizations focused on successful digital transformation, developers will continue to be measured by how fast they can develop and release code. Business leaders encourage DevOps teams to push the pace of innovation to deliver features quickly while leveraging the newest technologies to gain any available advantage in the market. As a result, development and operations teams work at breakneck speeds to meet the deadlines of short and frequent development life cycles.

    Security teams, however, are not measured by speed but rather by certain metrics of success, such as whether they achieve a certain security rating or reduce the number of incidents. Traditionally, security sets corporate standards and best practices centrally and tries to enforce them across the enterprise. With DevOps teams becoming increasingly distributed and decentralized, these conventional security methods no longer work and have actually slowed down security and/or blocked the software development process. Security tries to keep pace, but with numerous disparate reports to review and too many results to manage, they inevitably fall behind. In the rush to catch up, either critical vulnerabilities are overlooked or frustration sets in when releases are delayed.

    Developer and security teams both know the importance of delivering secure software but struggle to find the right balance. Let’s take a look at some strategies that can help ease the tension between DevOps and security teams and create a happier work environment, where safer code is delivered to the market.

    Incorporating Time Management for Speed and Security

    Consider implementing the following time management strategies to make life easier for developers:

    Integrate AppSec in the DevOps Pipeline: Application security scanning should be incorporated early and often within the DevOps pipeline. While this statement may sound like a broken record, the days of running scanning tools independent of your pipelines are gone. Studies have shown the earlier you detect an issue, the easier it is for developers to fix—with as much as 50% time reclaimed over late-stage remediation. By including AppSec in the pipeline, you ensure all issues are identified as quickly as possible. This effort will not only improve the quality of your software but also free up more time overall for developers to write code and create cool features. Sounds like a win-win for both teams.

    Incorporate automation as much as possible: DevOps teams should look to leverage automation when implementing application security wherever possible. Many of the steps for securing your software development process are repetitive. For AppSec to be successful, the steps must work within the developer’s world and along with the other tools developers love. Developers look for tools that help them move faster.

    Here are some areas where application security automation can unburden developers from repetitive tasks:

    • Use AppSec tools that can be easily tied into your DevOps toolchains. As a matter of fact, a developer may not even need to know what security tools are being run, only that they are executed on every run of the pipeline.
    • Automate the ingestion and correlation of the security findings. There will often be a boatload of redundancies between the findings from different security tools (i.e. SAST versus DAST versus SCA) and the potential compression ratios can be in the order of 10-50:1. There are tools to automate this process and dramatically simplify making sense of all the data. The onus shouldn’t be on the developer.
    • Once a security issue has been identified, it should automatically create a ticket in the ticketing system that developers use today. We all know developers don’t like being forced to use a new tool. Give them the findings in the system they are already familiar with.

    Tailor security training for your teams: Security training is a great way to reduce the number of security findings within an organization, which in turn frees up developers to work on other pressing issues. However, most security training is ad hoc and not tailored to meet the needs of the development teams. Even the most basic security testing can provide baseline metrics that enable security teams to recommend tailored training for development teams. These sessions can focus on areas that teams struggle with or areas known to be susceptible. Training is also a great way to develop security champions within the development teams, dedicated professionals who have shown to improve the overall security posture and awareness of organizations. Security champions—and the programs they advocate—have the power to improve both AppSec and relationships among people, a sentiment endorsed by 84% of industry professionals.

    Summary

    Developers know the importance of security and truly want to deliver safe code in the timeframes they are being judged on. By incorporating the strategies outlined above, they will have a fighting chance to reach the lofty goals set by the business, while releasing higher quality and more secure code. Security teams need to meet the developers in their world and help enable application security to be automated and work at the speed of DevOps.

  • Data Security in the Cloud with Imperva

    Data Security in the Cloud with Imperva

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

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

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

    Transcript

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

    Ron Bennatan: Thanks. Glad to be here.

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

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

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

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

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

    Ashley: Excellent.

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

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

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

    Bennatan: [Laughter] 

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

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

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

    Bennatan: It never goes away.

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

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

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

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

    Ashley: Mm-hmm.

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

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

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

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

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

    Ashley: Mm-hmm.

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

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

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

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

    Ashley: You have data in databases inside containerized—

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

    Ashley: Mm-hmm.

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

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

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

    Ashley: Mm-hmm.

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

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

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

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

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

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

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

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

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

    Ashley: A lump sentence, but [Laughter]—

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

    Ashley: Mm-hmm.

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

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

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

    Ashley: Mm-hmm.

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

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

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

    Ashley: When do you get the luxury, right?

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

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

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

    Ashley: Mm-hmm.

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

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

    Bennatan: Yeah.

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

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

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

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

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

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

    Ashley: Mm-hmm.

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

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

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

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

    Ashley: Mm-hmm.

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

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

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

    Bennatan: Yeah.

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

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

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

    Ashley: [Laughter]

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

    Ashley: Mm-hmm.

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

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

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

    Bennatan: Yes.

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

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

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

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

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

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

    Ashley: Best [Cross talk].

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

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

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

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

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

    Bennatan: Yeah.

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

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

    Bennatan: Yeah.

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

    Bennatan: Yeah.

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

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

    Ashley: Exactly.

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

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

    Bennatan: Yeah, yeah.

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

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

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

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

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

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

    Bennatan: [Laughter]

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

    Bennatan: Hopefully. Thanks, Mitch.

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

  • Dynatrace Adds Security Module to Observability Platform

    Dynatrace Adds Security Module to Observability Platform

    Dynatrace announced today it is adding a module to provide continuous runtime application self-protection (RASP) capabilities to its observability platform.

    The Dynatrace Application Security Module leverages existing Dynatrace tracing and artificial intelligence (AI) technologies to detect threats in real-time and then apply appropriate policies to automatically secure applications.

    Andreas Lehofer, chief product officer for Dynatrace, said that with the rise of highly dynamic microservices-based applications, the time has arrived to extend the company’s platform into the realm of application security. In contrast, there aren’t typically as many changes to monolithic applications to justify adding a security module to an application performance management (APM) platform, he said.

    Lehofer said the Dynatrace Application Security Module has also been designed to reduce false positives by only surfacing alerts concerning code that is actually running. Rival RASP platforms will detect modules and start generating alerts about libraries that may be present in an application environment but are not actually employed, said Lehofer.

    The Dynatrace Application Security Module working with the Smartscape topology mapping and PurePath tools for analyzing code also make it possible for DevSecOps teams to better understand dependencies between microservices, he added.

    At the core of the Dynatrace approach to DevSecOps is its OneAgent software for application instrumentation, which collects data and feeds it back to an observability platform that includes an artificial intelligence (AI) engine dubbed Davis. As the Dynatrace Application Security Module continues to evolve, IT organizations should expect Dynatrace to apply AI capabilities to application security more broadly, Lehofer said.

    The ability of DevSecOps teams to automatically remediate applications that are discovered to have significant security issues depends on their ability to roll back applications after they have been deployed. Most IT organizations at the moment still have to manually roll back an application after it’s been deployed, he noted.

    Longer-term it’s not clear to what degree AI might advance DevSecOps; however, the more automated the process of identifying vulnerabilities becomes, the easier it should be to automate remediation.

    In the meantime, as the observability capabilities of platforms such as Dynatrace extend into application security, the easier it should become for organizations to embrace best DevSecOps practices by employing a module that is added on to an existing APM platform.

    Dynatrace, of course, is betting microservices-based applications will increase the adoption of its observability platform. Historically, IT teams tended to employ an APM only to instrument their most mission-critical applications because of the costs involved. However, as IT environments become more complex in the age of microservices, platforms that can observe all the dependencies that exist in a distributed computing environment are now critical. Extending that platform to include application security further extends the economic case for investing in an observability platform.

    It may be a while before most organizations reach a level of DevSecOps maturity that requires continuous observability, but as responsibility for application security continues to shift further left, it’s now only a matter of time before more automation is applied.

  • Integrating Security in the Development Process With DevSecOps

    Integrating Security in the Development Process With DevSecOps

    Occasionally, it’s worthwhile to reflect on how we develop and deliver software during times of rapid change and significant disruption. In those moments of reflection, we learn from the exciting trends and changes that are taking place. Recently I had the opportunity to commiserate with two technical thought leaders at Perforce: Stuart Foster, product manager, and Steve Howard, static code analysis evangelist.

    The disruption caused by COVID-19 goes much deeper than just the rapid shift to work-from-home. Development teams are being asked to keep up developer velocity, while the organization as a whole accelerates digital transformation projects, shifting priorities and emphasizing investments needed to successfully navigate difficult and uncertain economic and market conditions.

    In our conversation, we note how investments already made in shifting to the cloud, remote and cloud-based development, automated testing and pipeline automation and security tools are helping organizations today. We also explore how current conditions influence product roadmaps, causing software teams to take a holistic look at their development processes and tools, and organizations to rethink how to take their software delivery capability to the next level.

    Stuart and Steve share their software best practices on collaboration, automation, security, standardization and more.

    Explore our conversation in more depth by viewing the video and transcript below.

    Transcript

    Mitch Ashley: Well, I’m happy to be joined by Stuart Foster, who’s product manager with Perforce, and Steve Howard, static code analysis evangelist, and I think a lot of other things, too—does a lot with Perforce. So, welcome, gentlemen—good to be talking to you today.

    Stuart Foster: Thanks, Mitch.

    Steve Howard: Hello.

    Ashley: You know, we’re talking about—you know, Perforce does a lot of things, and I think we’re just kind of focusing on what maybe some of the current conditions, current best practices are. There’s a lot happening right now in everybody’s world—a lot of change, a lot of disruption.

    But before we get to that, could I have you both introduce yourselves? Maybe Stuart, would you start first?

    Foster: Yeah. Hi, everybody, I’m Stuart Foster, I’m Perforce’s product manager for our static code analysis products.

    Ashley: Great—Steve?

    Howard: Yeah, and I’m—well, I have, as you say, many jobs and roles within the organization, but primarily focusing on the evangelism around using static code analysis for both of our products, Klocwork and QAC, here at Perforce, yeah.

    Ashley: If you’re working with developers, you gotta be doing evangelism, right?

    Howard: Yeah. [Laughter] 

    Ashley: They expect you to give them support, and be talking to them, in a different kind of way. Tell us—would one of you tell us a little bit about Perforce and what all you all do?

    Howard: Yeah, sure—well, I’ll take that. So, Perforce is an organization, obviously as, you know, originally comes out of the version control software. But really, it’s about developer tools and how we can help make the developer’s life easier in the day to day tasks. So, whether that be trying to prove compliance to standards or just trying to get the stuff out the door in the first place—anything that we can do to help make that process smooth and reliable is kind of where we are. And, you know, these days, that has a bit of a—a buzzword, if you will, around the DevOps tooling ideas, but essentially, it’s developer tools and making their life more comfortable.

    Ashley: That’s great, because you all fit into a number of places in the sort of tool chain, pipeline, workflow process across the development life cycle.

    Howard: That’s right, yeah.

    Ashley: So, that’s awesome. Well, let’s get into this. I’m really curious about what you’re finding in market, and one of the things we like to do when I’m talking with experts like yourself is, let me just try to share some of the things that we’ve experienced within the past, but also kinda recently that it’s happening, because we’re all dealing with economic change, disruption, COVID, work from home, all of those kind of things, but you know, we’ve done some research at my company and there’s a lot—of course, a great, great emphasis on acceleration of digital strategies and, of course, that puts a lot of pressure and emphasis and people are betting money on software being the answer to helping them implement their strategies.

    Are you seeing the same kind of thing, that acceleration of digital transformation and software—elevation of software projects?

    Foster: Yeah. We’re seeing that across the board, even in our own company here. You know, a lot of us have transitioned to work from home, and then you have to start thinking about the considerations for that, right? 

    And what we’re finding ourselves and working with our customers is, a lot of people are shifting more technological tools, right, to be able to better produce workflows and code reviews, how to—working from home, security, right? How secure are your remote development work stations? How is security being built into your software and your workflow? So, tools are being used across the board for that. Just being able to rely on a piece of software versus in-office workflow has become more and more important. And amongst all that, then there’s the goal to, you know, keep development velocity up, which could be a challenge when working from home, right? So, we’re seeing a lot more DevOps automation of, you know , a lot of workflow process and things like that.

    Ashley: Yeah, there’s no more popping over the edge of the cube or to the table next to you, right? Somebody sitting there at the café, in the office, or down the street. It’s a fully digital world, right? You’re not sitting with people very often.

    Foster: Yeah, we’re relying on Slack, we’re relying on Slack calls, Zoom videos, everything to just stay in touch and work and collaborate with one another, yeah.

    Ashley: Steve—yeah.

    Howard: But I think that’s where—yeah, so, I was gonna say, I think that’s where those centralized processes that we’ve kind of all been working towards, luckily, for the last few years, are really gonna pay off. Because how do we not have that? If you imagine how things were maybe five years ago, it would’ve been a much bigger transition to get to where we are now, whereas it was almost like most of our organization was kind of ready to go. We were already there, just—you could call foresightful, but really, it was a little bit of chance, I think. Yeah, those processes have held things together remarkably well, and we’re very lucky for it.

    Ashley: You know, nobody would wish for something like COVID or a pandemic on any of us, but if you look back, you know, I think back when we were virtualizing things and developers were starting to be able to just create a fully self-contained environment to develop on their laptop—I saw people working on planes, right? First time I saw somebody writing code on a plane—that’s awesome.

    But so many things, and then of course, adding the cloud and all the services and software and tool chains and pipelines that we can create now, it—I mean, I think we’re lucky, if you were gonna have something like this happen, now is the time where we can actually continue to be productive, and put more emphasis or pressure on ourselves to deliver software. Do you agree?

    Howard: Yeah.

    Foster: Yeah, absolutely.

    Howard: Yeah—sorry, Stuart.

    Foster: [Laughter] We agreed at the same time, that was great.

    Ashley: [Laughter] 

    Foster: But you’re right, I think, like, some of it—you know, it’s a little bit accidental, but as you mentioned, setting up the development workflow to be able to do it on a laptop, people are shifting their hardware, they’re removing their hardware and going to the cloud, right? So, it’s kind of been like an expansion and a reduction, all—just naturally, but also, you know, you think about DevOps and there’s also, you know, cost savings to be had by not having to have this footprints, not having to worry about these things.

    So, this could be, in some ways, pretty revolutionary or changing for development costs for a lot of companies.

    Ashley: Steve, you were gonna jump in there—anything to add?

    Howard: Yeah, no, exactly the same. I think the fact is that we—you know, a lot of that infrastructure is being built up and the idea of being able to run our development pipelines kind of in a cloud environment or whatever and having that all ready to go just meant that we didn’t have to pick up ginormous work stations. I remember back in my days of developing in aviation software, we used to literally have, you know, Unix boxes stacked up on the side somewhere that we had to go and log in on each one and run our testing for each single one. It’s just unthinkable. It would never have been possible.

    Ashley: That would be insane today. You would never. I mean—

    Howard: Yeah.

    Ashley: – if you have a choice, you would never do that, right? [Laughter] 

    Howard: Well, exactly, and the very fact that, you know, 10 years ago, we still had to do that, how could we have transitioned? It wouldn’t have been possible. And so, it really is testament to how far we’ve really come in 10, 15 years to see where we are with our testing processes, the fact that we can do, you know, 99 percent of it, if not all of it can be done completely with no connection to the physical space.

    Ashley: Mm-hmm.

    Howard: It’s all—and that can even mean, you know, in the cloud completely, so it’s not even within our organization. It’s securely being done off site somewhere in the ether. [Laughter] 

    Ashley: Yeah.

    Howard: And that process is still completely manageable, it’s something we can all see as developers, everyone can get to see where we currently are with that process, you know, what the latest test run gave us across the whole—

    Ashley: I’m really curious—yeah, I’m really curious what your experience in market is. Do you see more people who are kinda doubling down and getting even more serious about their DevOps implementation and taking it to the next level, or do you see more people coming to you that maybe are relatively new to DevOps and are looking for tooling and looking for ways of helping them, you know, not just get started and learn all the problems themselves, experience them themselves, but looking from the experience of a software provider like yourself, or is it a little bit of both?

    Howard: I’d say a little bit of both. I mean, obviously initially, there was such a lot to do already and everyone kind of had no time to really think—understandably, but probably within, you know, since the end of the summer, maybe, things have started to come back and people are actually going, “Well, hang on a minute. We’ve got a process, but now, how can we actually make this a lot easier for ourselves?” and looking to improve that.

    And I think, you know, for a lot of the organizations where, perhaps, doing things off site would never have even been considered. And I think this was to Stuart’s point—that kind of, that’s been forced upon people and it’s almost gonna change the way we develop forever now as a result of that, because we have now, we’ve done it, we’ve experienced that it’s possible, and it’s safe and it’s secure. 

    How can we now make that better and make our lives easier by not having that massive footprint that Stuart was mentioning? We’ve actually got something that’s very, very lean, it’s in the cloud, we’ve got machines when we need them, but not when we don’t need them, and how can we really make that process as efficient as possible from the results side, you know, making sure we’re doing what we’re supposed to be doing as quickly as possible, but also actually trying to reduce our footprint on process and power, for example? You know, the development time that’s involved in that, how can we make that as efficient as possible?

    Foster: Yeah, and I also think what we’re seeing, too, is, you know, our existing customers, they’re doubling down on their tools, you know, because they need to rely on something, right? And that’s also, what it’s done is also, I think, is changing some of the roadmap items that all products are looking at, right? There’s a whole new—not a whole new paradigm, but you know, there’s a little bit more seriousness being taken in terms of some of these features and functionalities of being able to work remote, or the requirements for more cloud usage, right? We’re talking ease of use, we’re talking about things that are, you know, related to workflows to make working in these conditions—not just in these conditions. Assuming you get back to the office, just more efficient as well.

    Ashley: Mm-hmm.

    Foster: So, we’re seeing that at the same time, too. And then, you know, from the perspective of new customers coming in, they’re almost expecting these things to already be there, right? Because they’ve run up to these problems as COVID has created and they’re trying to find the solutions that are gonna be kinda turnkey out of the box.

    And also, I’ve done, I’ve been talking with various analysts related to our product, but it seems as though the analyst community itself is, they’re seeing the requirement for, you know, ease of use in DevOps becoming more important as well at the same time.

    Ashley: Mm-hmm. I think that may be also, in part, the expansion of DevOps into the organization. They may have had a core group of teams that were really taking the challenge of DevOps and implementing it and now, how does the rest of the organization do the same thing, but accelerate their adoption of it?

    Foster: Yeah, and I think also, a lot of development groups within a single company—you know, you may have a security team, you may have a development team, you may have a LiveOps team—they’re starting to recognize that there are choke points in the development processes.

    Ashley: Mm-hmm.

    Foster: And so, how do you unblock that? How do you make it more easy? How do you offload some of that choke point onto a broader group, right? A lot of the idea of DevOps, DevSecOps, whatever you wanna call it, right, is that developers are owning the code that they produce in more broad ways. That’s writing unit tests, that’s making sure they do the QA on it, right? That’s when they’re, you know, they have to implement the security requirements then and there, right? They need to ensure the traceability is done, right? They have to—they’re taking that into their hands. It’s becoming not so much that there’s a DevOps group that magically handles all this infrastructure, it’s becoming part of each developer’s responsibility as well, right?

    Ashley: Hmm. Interesting. You know, I know, as you scale things out and you adopt new tools, tools do a lot of things for you, but there’s oftentimes, there’s approaches that you need to adapt into your tools, things like what are our coding standards, what are our testing, what level of testing do we do? How do we break it into chunks? When do we do security testing of our code?

    And that’s part of that learning curve to is, how do you adapt a tool set to both what your requirements are, but also, you would like it to kinda take you to the next level. What are some of the things that really can help people kind of propel their expertise in the organization’s ability to deliver software more effectively?

    Howard: Yeah, that’s a really good point. So, one of the things, you mentioned coding standards there, but obviously, you know, those can come from multiple sources, they can be something that’s actually being required by a standard, for example, if it’s in a safety critical, security critical world. It could be something that’s actually demanded by the organization itself—they have their own rules or there’s certain things in any particular project that, if you do things in a certain way would make, you know, it would be dangerous or insecure or something. So, they have some controls, as well, of that.

    And what we do see is, the more that we can get that information out to our developers, for example, the more value that has as well. So, yes, we can help enforce coding standards, for example, with our Static Analysis tools. But that’s only half the story. Enforcement is one thing; actually getting the developers to understand what the problems are as they’re creating them and to have easy access to the help and the quick feedback of those problems makes it much more powerful, because it gives them, (a) you know, all the resources they need to deal with the problem quickly and to not perhaps find it a challenge to have to deal with, but also, they learn. 

    And so, the next piece of code they write doesn’t generally have the problem. So, there’s a developer learning element there as well, which we can control centrally, and then spread out to all of these remote workers working—you know, without that team collaboration that we used to have, we’re still able to do the same things. So, that’s become something that’s really focused people’s minds on the capability there in terms of what that means. And as I say, that applies to security standards that are well known or requirements for quality that we have to work to for a security or safety standard—

    Ashley: Mm-hmm.

    Howard: – but also the company’s own rules.

    Foster: Yeah, and I think, you know, outside of just simply the tools, development teams are, you know, taking a step back and re-evaluating or thinking more about what their software development process is, holistically, right? You know, Steve mentioned there some of the tools, best practices, but you know, you also have to think what kind of, you know, software development methodologies might you be using. You know, sometimes it doesn’t matter whether it’s agile, waterfall, whether you’re using Scrum or Kanban, you know, I think it’s giving people a moment to think about what’s the most important kind of Dev process that is gonna fit this team or how you have to work now, how it fits the businesses. 

    And then implementing processes to ensure the organization, communication, and what systems need to be put into place to help prevent any problems that arise during development and kinda identifying and understanding that. Then you’re picking the tools, you’re building your development workflow, whether it’s in environments, it’s setting up DevOps pipelines to ensure that everything’s followed correctly. It’s the tools, but it’s the process, and that’s changed, too.

    Ashley: That’s interesting. You know, we’ve done some research about the influence that developers have had on the organization, too. Even outside of development teams, you’re seeing DevOps and agile kind of principles, even though they aren’t calling it that—daily standup meetings, shorter intervals of deliverables, more kinda asynchronous communication tools and collaboration kind of tools, which really makes it easier, I think, for the development teams, the product teams—you’re a product manager yourself, Stuart.

    Foster: [Laughter] 

    Ashley: And beyond—operations, security—everyone is kind of forced to work a little bit differently, but also can benefit from what each other knows about how to do that more effectively. And we seem like we’re at this sort of serendipitous time of being able to leverage that, which fits right into the tooling approaches that we can take.

    Foster: Yeah, and you know, when you look at it, like, it always just ends up communication. Whatever the communication is, whether that’s the workflow, whether that’s in-person, whether that’s meeting, whether that’s documentation, it’s all about communication, and that’s true not for just development, but for business, right? Developers working, you know, with other groups—marketing, sales—everything, it’s all communication. It just keeps business running. And that’s kinda the funny kinda perspective that may not necessarily be outright visible by simply saying, “It’s communication.”

    Howard: What’s interesting is, that’s also kinda mirrored in the tooling, because a lot of the work we’ve been doing recently is about how to make sure the tools have all got open interfaces to communicate with the next thing in the pipeline or to feed that data back up to some dashboard that’s gonna be shared with the rest of the team.

    So, yeah, it’s kind of an interesting point, but that also applies with the tooling that we’re trying to build around that.

    Foster: Mm-hmm.

    Ashley: Mm-hmm. A really great point. So, to give you fair warning, I’m gonna ask you your three recommendations on best practices in the current climate, so be thinking about that.

    I was thinking about your comment, Steve, about being able to better integrate tools together and then taking the data from the tool sets, the pipeline of the process that we’re going through and the pipeline of work—there’s so much value in that data that sometimes ends up as exhausts or on the cutting room floor, right, to use two different metaphors. But that information could be extremely valuable, putting it into dashboards, feeding it into continuous improvement processes, shortening the window for getting feedback for, “Here’s a security vulnerability or a coding standard” or some kind of an error that you can fix in minutes instead of days and weeks and sometimes months, right? The security audit at the end of the release is much easier, because you’ve already gone through so much to it. Those can all be things that can help us.

    So, I gave you a little bit of time there to think about your three best practices. I did my best job of stalling that I could. So, who would like to go first? What would you recommend people consider today?

    Foster: Yeah, I’ll go. Just, I want to reinforce that message of,  you know, figuring out how you’re going to work as a development team, develop that communication, right? And that’s using your tools.

    I think in the world of remote work from home, having kind of a common language—again, back to communication—of how, you know, each developer’s system is set up. So, common environments, they should be using as close to the same setups as possible so that, you know, when one of you is running into an issue, it’s easier to get that information across, right? You’re not gonna have to install something obscure because somebody’s using something obscure. You should all be trying to talk and use the same tools so you’re all speaking the same language. That allows you to have that velocity that you could otherwise lose.

    And in this world, too, security hasn’t been more important than ever—security is more important than ever. So, think about securing your Dev processes, developing secure software, it’s gonna be very important. And those are kinda my three.

    Ashley: Okay, great. All good ones. Steve?

    Howard: Yeah, I’d answer—so, my three would be, first of all, to automate; take the process away from the day to day effort of the development teams and organizations around them. So, yeah, that’s the first one.

    Report—so, that’s the communication piece, I guess, but get the information to the right people at the right time and hopefully in the right sort of time window.

    And then shift left. So, then, we make it more efficient. Then we look to where we can try to remove the fat in the process and take away the time that was wasted and try and move it to the right position in that process. So, yeah, those three, in that order. [Laughter] 

    Ashley: Great. Excellent, excellent. I’m curious what you both think will be some of the things that will stay with us, the things that’ll last past a forced work at home, forced work remote. Maybe people are returning to the office, maybe they aren’t. What do you think are some of the things that will stick with us? Because it wasn’t like we were doing this for two weeks and then we’d just go back to the office—this is an extended period, we’re developing new habits, we’re changing how we’re working. Why go back, sometimes, right? What are your thoughts?

    Foster: I think you’re gonna see a lot of these workflows stay around. I think that the reliance on the numerous tools to keep velocity up and reduce and automate are just gonna stick around. You know, you don’t want to be wasting time on trying to get something to work. It’s easier to just simply automate it and get it out of your hands so that, you know, at least from a development perspective, you can just focus on what’s important, which is, you know, coding, the feature, getting the product out the door, right?

    Those are gonna stick around, and I think the tools, over the course of time, are just gonna keep reinforcing and strengthening that kind of automation pipeline.

    Ashley: Good.

    Howard: Yeah, no, and I think, from my perspective, just to add the one small piece there is, the cloudification, essentially, of the processes. So,  I think, you know, people will stop having the premises to host great, big server racks in, and that’s just all gonna move off site, off premise, outside of the organization, for sure, yeah.

    Ashley: Yeah. To kinda add what you both have said, which I think supports your thoughts on this is—you know, as we change to whatever we’re gonna go back to, I don’t think it’s gonna be back to what we were doing. But it’s gonna be a hybrid, right? I can’t imagine everyone shifting back to a different way. It’s—some people are still, maybe even more percentage of our teams are working remotely, never going back into an office, but we may have some that do.

    We’ve broadened the reach across the globe of people that we’re working with, the product and vendor, tool vendors that we’re working with. Those things aren’t gonna change, right? 

    Howard: No. No.

    Ashley: We’re gonna stay doing that. If we’ve found something that works better, you’re gonna stick with it, right? So, you’re gonna stick with—you’re gonna stay in the cloud, push more in the cloud, right? And leverage some of the automation, the processes that you talked about, Stuart.

    Well, this has been really fascinating. Would love to have you both back, have you guys back and we can talk some more about—I’m gonna delve into static code analysis evangelist, your role, Steve, get into some of that, which I know you all have some of your products do and to security and to some other areas within the software pipeline, but this has been really great. I’ve really enjoyed talking with you both.

    Howard: Yeah, it’s been a pleasure.

    Foster: Great. Thanks, Mitch.

    Howard: Bye bye.

    Ashley: You bet. We’ll see you soon.

  • How to Foster Collaboration Between DevOps and Security

    How to Foster Collaboration Between DevOps and Security

    DevOps is on the rise. Back in 2018, MarketsandMarkets wrote that it expected the DevOps market to grow to $10.31 billion by 2023. That’s up from $2.90 billion in 2017, with a compound annual growth rate (CAGR) at 24.7% projected for the forecast period. Demand for DevOps solutions and services in response to the need for fast application delivery capabilities would likely help to drive this increase.

    Even so, security issues are introducing some challenges for organizations. A study conducted by the Enterprise Strategy Group and commissioned by Synopsys Inc. found that 48% of respondents had knowingly pushed out vulnerable code into production due to time pressures. Patrick Carey, product marketing director for the Synopsys Software Integrity Group, noted that about half of those respondents had done so “because the vulnerabilities identified were discovered too late in the [development] cycle to resolve them in time.” Such weaknesses elevate the risk of a data breach, and they potentially carry reputational costs for organizations that don’t plug those gaps before they release their products into production.

    These findings beg the question: Why are organizations struggling with their security efforts for DevOps? What’s not working for them?

    This blog post will explore these questions in terms of a cultural divide that exists between DevOps and security teams. After exploring where each team is coming from, this blog post will provide recommendations on how organizations can work to foster cooperation between their security personnel and DevOps teams.

    The Great Divide: Understanding the Issue

    The cultural divide alluded to above boils down to a false understanding of security and its impact on the development process. DevOps personnel are required to work within short development cycles to meet their employers’ evolving business needs. Subsequently, some organizations might interpret security as an opponent to their developers’ speed and respond by sacrificing security for the sake of speed. This decision enables misconfigurations, vulnerabilities and other security weaknesses to make their way into production.

    However, this interpretation overlooks an important reality: Many DevOps teams view security as a nuisance that gets in their way and slows down their work. Retroactive fixes ultimately take time and effort. In response, organizations might hold back on investing in the security of their DevOps processes, thus creating “technical debt” in the event that the work doesn’t get done.

    With that said, organizations have an incentive to rethink how they conceptualize security so that they can avoid these costs and keep their development processes running smoothly. But this raises an important question: How can organizations go about doing that?

    How to Balance DevOps and Security

    First, organizations should work to foster a culture of communication through which security personnel and DevOps team members can learn from one another. One solution to start with is having leaders from both teams “walking in the other team leader’s shoes,” thereby allowing them to share information and discuss their perspectives.

    Such communication will be effective only if personnel understand where the other side is coming from, however. That’s why organizations have an obligation to make their security policies and development workflows as understandable and implementable as possible. With this transparency, security and DevOps can begin to craft a way forward.

    Organizations can help out by encouraging both security teams and DevOps personnel to expand their knowledge. With respect to the former, security personnel have an interest in learning how to frame their message in the right language. It’s important to acknowledge that security teams can speak of potential security issues burdening projects with unexpected work and/or threatening operations’ availability with longer mean response times.

    Of course, security teams need to have a basic understanding of where developers and operations personnel are coming from. They can do this if organizations support them in learning about programming languages and how applications are developed. Subsequently, security personnel can use this knowledge to hold more credible discussions with their Devs and Ops counterparts as well as to properly configure their organizations’ Kubernetes.

    StackRox emphasizes the importance of administrators using automation to review their environments for possible misconfigurations:

    That’s because in a sprawling Kubernetes environment with several clusters spanning tens, hundreds, or even thousands of nodes, created by hundreds of different developers, manually checking the configurations is not feasible. And like all humans, developers can make mistakes – especially given that Kubernetes configuration options are complicated, security features are not enabled by default, and most of the community is learning how to effectively use components including Pod Security Policies and Security Context, Network Policies, RBAC, the API server, kubelet, and other Kubernetes controls.

    As far as DevOps personnel are concerned, training is key. Organizations should specifically consider training their DevOps teams in secure coding practices and educating their employees about attackers’ tactics. These individuals can then incorporate that knowledge into their coding practices and development processes. Additionally, organizations can uphold this security mindset among DevOps personnel by assigning security responsibilities to an individual on the DevOps team or to someone in a new position. They can then overlook security protocols among the DevOps personnel.

    Positive Focus Goes a Long Way

    The key to making security and DevOps teams work together is not taking their collaboration for granted. Like any relationship, organizations need to foster this cooperation by using positive focus and work to bring these two groups together. In that way, they can enjoy both the speed of DevOps as well as the security to stay safe against evolving digital threats.

  • Why Secrets Management is Critical to DevOps Pipeline Security

    Why Secrets Management is Critical to DevOps Pipeline Security

    While valuable, secrets management also can be difficult for DevOps teams to employ. Here’s what you need to know

    Business is all about speed. Companies want to innovate and deliver functionality faster to remain competitive. This explains the increasing popularity of DevOps as a go-to model for rapid application delivery. A recent Gartner report indicated that DevOps adoption is a growing alternative to traditional waterfall and agile development methodologies, but also pointed to key challenges with security and compliance.

    For example, the report noted that DevOps practices encourage automation to achieve scale, but that security is traditionally manual, gate-driven and heavy on processes. In addition, the majority of developers have zero knowledge of secure coding, even many who are well-versed in agile and DevOps.

    But there is another critical component of data security for DevOps teams: secrets management. In DevOps, “secrets” are typically authentication credentials used in applications and services. This may include usernames and passwords, either system-to-system or database; API tokens; SSH keys; encryption keys; and so on. Secrets are the keys to your data and, when handled casually, can open the doors to a serious data breach or intellectual property theft.

    Secrets Management Presents Challenges

    Developers often inadvertently leave behind sensitive pieces of code embedded in applications, files and code repositories. One real-world example is the way in which some developers use GitHub, a hugely popular source-code management system and the largest source-code repository in the world. Most developers seem to use GitHub casually, leading to increased risk of insider threats and hacking incidents. In one such incident in 2016, hackers penetrated Uber’s source code repository via GitHub, accessing intellectual property, AWS credentials and the personal data of more than 7 million Uber drivers and 50 million customers.

    There are three main reasons why secrets management is challenging for DevOps teams:

    1. Secret sprawl. Increased adoption of the cloud-native development model and the emergence of multi-cloud infrastructures has led to a proliferation and decentralization of secrets. If left to their own devices, these secrets can sprawl over time, leading to data breaches and privacy concerns.

    2. A disparate set of tools. Many DevOps teams use different sets of tools for different phases of the development process and often struggle to have a centralized system that can integrate with all these tools and systems. Cloud-native secrets management tools are limited to the specific cloud provider and may not be effective in a multi-cloud scenario. An effective secrets management strategy should be able to integrate and work with every tool in the DevOps workflow and across cloud providers.

    3. DevOps blind spots. Most enterprises are unaware of where their secrets are located, who has access to them or whether the secrets have been changed. This lack of understanding of the functioning of the DevOps pipeline often increases the risk of an internal data breach.

    Today, most enterprises use containers to package and deploy applications. Gartner estimates that by 2022 nearly 75% of organizations will be running containerized applications in production. Oftentimes, in a container-driven environment, the groups responsible for developing applications are distinct from the groups in charge of deploying applications. Furthermore, database administrators by and large have (or should have) access to the keys, tokens and secrets.

    In this setting, a major challenge is how to enable application development and deployment in the presence of this segregation without compromising secrets. If a developer has a piece of code inside a container that requires access to a secret key, then this secret value can be hard-coded into the code itself or included as part of the container image. But both of these options have detrimental security implications because they expose secret values to all those who can view the source code or deployment parameters, thereby violating the principle of least privilege.

    Instead, secrets can be securely passed to the containerized code during actual runtime. Using a utility based on a container-orchestration system such as Kubernetes allows the secure transmission of secrets at runtime, meaning the secrets don’t need to be exposed while building or deploying the application. Rather, the utility can monitor the environment in real-time and inject secrets at runtime only when they are required.

    3 Things to Look for

    Regardless of the tools used in a development pipeline, protecting credentials and API keys from compromise is critical. Simply put, secrets must exist outside of the source code. When considering a secrets management solution, there are three things to look for:

    • A flexible deployment model, whether on-premises, natively in the cloud or any hybrid/multi-cloud combination.
    • A solution secured in a way that goes beyond a simple key-value store.
    • The ability to connect to other applications and services through open standards such as OAuth, OpenID (SAML), LDAP, Trustworthy JWT and PKI.

    A secrets management strategy that takes these factors into account maximizes an organization’s opportunities for success. And with the DevOps model as prevalent as it now is, it’s absolutely vital for teams to do so to significantly reduce the likelihood of breaches and ultimately improve business agility.

  • DevSecOps Implementation: Dynamic Scans

    DevSecOps Implementation: Dynamic Scans

    This is the third installment in this series on DevSecOps. Read the first installment, on static analysis, here and the second installment, on source composition analysis, here.

    One weakness of static analysis is its failure to account for environment and use. Running static analysis on a code base as the only check before production deployment is akin to looking at the engine of a VW Golf before assembly and pronouncing the vehicle fit to use. The way a vehicle runs after assembly, and the way it is—or, more precisely for dynamic scans, could be—used, matter to any product. That is where dynamic scans come in.

    Exercising the product as it runs is a big deal, and that is what dynamic scanning attempts to do. Automating the testing of applications by exercising inputs and watching the results, dynamic scans can detect a variety of issues that static analysis simply cannot. These tools are the source of a lot of the noise in DevSecOps because they’re testing a variety of scenarios with each run, and things that a dynamic scan sees as vulnerabilities might very well be known to not be a risk at all by the dev team. As with static analysis, this has been improving over time, and they’re well worth a look at this point.

    The best use for these tools is as gateways—before going to test, in test and before going to production, set a policy for promotion requirements and then run dynamic scans to determine if the application meets that policy, needs remediation or needs approval to go live with possible issues known.

    With all of that said, here is a starter list of things to look for when considering using dynamic scans:

    • Production Safe: These tools run tests that try a documented vulnerability to see how the application responds. The thing is, if you’re not very careful, this can cause serious problems in production. Since long-term the trend is to eliminate a pure test environment for all but the most stability-conscious organizations, knowing that the product you choose can run in prod without causing outages is an important step.
    • Vulnerabilities Tested: Most vendors offer a list of what they look for. Compare these lists to your organization’s needs and other vendor’s lists. Since choosing a product is unique to each org, I don’t have much in the way of buying advice, but here I will say if the product does not support at least the OWASP top 10, look elsewhere, simply because OWASP is both a recipe for you to prevent attacks and a handy list of easy vulnerabilities for attackers to look for. All of the vendors we looked at for our ASG work do support OWASP, so this might be non-advice.
    • Integration: Dynamic scans need to be run after the product is fully assembled. This is not to say complete, but the various pieces need to be together—the scans generally look at an application, not pieces thereof. This means they can be spawned at any point after build—or, more specifically, after post-build deployment to dev/test/prod. Make certain there is a place in the toolchain to call the scanner from and proper gateways to suit your organization’s needs. Part of that evaluation is how the application is kicked off: Can your build tool call it directly? Is it deeply integrated into your chosen environment, or will you have to do work?
    • Reporting and Gating: What level of reporting is available: Can dynamic reports and static reports be integrated to show that a potential problem reported by static scan is found to actually be a problem by the dynamic scan? Can an overall status report be found (à la C-level dashboards) to show the security posture of a given application? Can alerts be configured for apps that fail certain tests (so you can make informed decisions before going to production, for example)?
    • RBAC: This is applicable to all scanning, but I’ve chosen to include it here because for dynamic (and interactive), it’s a bit more important. Can you limit what an individual can see/do? In the end, dynamic scans are reporting on actual vulnerabilities in your codebase—only those who need to know to fix the issue should be able to see it; others should just see pass/fail overall for the app, not a list of known vulnerabilities in the app. The ability to run these scans should likewise be limited. Who/when is a corporate decision that is as much policy and process as it is the chosen tool, but if the scanner doesn’t support that policy, enforcement becomes more difficult.

    When you get to interactive scanning, it is time to consider how security issues traditionally have been handled versus how they should be moving forward. Most organizations hold security issues separate from other application development issues. It is time for that to end—and indeed, some organizations ended this process long ago, but too many are hanging on to the past. Security vulnerabilities that can result in a risk to the organization need to be run through the system as high-priority bugs. Because they are. We used to think that something making the UI look bad for 5% of customers was more important than a security issue impacting no one. A truly global internet and the rise of automation even among attackers make this a silly stance to take. No one is impacted by security issues at this second, but sometime in the next minute, everyone might be impacted. It’s like saying you don’t need scalability for Black Friday because the servers are handling traffic well right now (written in early November). The issues that dynamic scanners alert on are generally real (removal of false positives has come a long way in the dynamic space) and generally dangerous. If your scan tool can find it, assume attackers’ scan tools can, too.

    As with the other installments, I’ll thank you all for keeping the lights on in a really topsy-turvy IT environment—you are doing us all a service—and mention that all of your hard work is at risk if security at your organization isn’t taken seriously. We quickly identified the threat from the sudden opening of millions of RDP ports on the public internet, and most of you took steps to secure your own. Keep it going. Make certain the apps you are developing and deploying are as safe as you can make them. And keep kicking rear—you are the rock that’s keeping the suddenly dispersed company clipping along.