devopsy.kinsta.cloud

Category: DevSecOps

  • Approaching Security as a Fundamental Element of Software Development

    Approaching Security as a Fundamental Element of Software Development

    How we really integrate security into the SDLC? What are some of the best practices around secure software?

    In this episode of TechStrong TV, Jill Britton, director of compliance, and Stuart Foster, product manager at Perforce, joined us to discuss how to improve application security by making security a fundamental component of the software creation process.

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

    Transcript

    Mitch Ashley: I have the pleasure of being joined buy a couple of folks that I’ve talked with before on a webinar and a few other videos. Jill Britton and Stuart Foster from Perforce. Welcome to you both.

    Stuart Foster: Thanks for having us, Mitch. 

    Jill Britton: Thanks.

    Ashley: Let’s start off with some introductions. Since you’re ahead in the time zone here, Jill, how about you go first?

    Britton: Okay, thanks. I’m Jill Britton. I’m the director of compliance for static analysis tools here at Perforce. I look after areas regarding coding standards, functional safety standards, security standards, anything in that area.

    Ashley: Excellent. Stuart, you want to introduce yourself? Tell us about Perforce, too. 

    Foster: Sure, yeah. I’m Stuart Foster. I’m a product manager for our static analysis products, both Klocwork and Helix QAC. And a little bit about Perforce, we help with enterprise development and DevOps at scale. We have a lot of various tools that help accelerate development projects in terms of your planning. So we have project and portfolio management tools, requirements management tools. We have things that help in the create area of the DevOps infinity circle for issue management version, asset management, code review. We have static analysis. We have various functional test case management and things like that that also fit in the verify. And we have a lot of tools that are here to drive your product at a high quality to market. 

    Ashley: Excellent. Excellent. Well, very timely conversation at least here in the U.S. with security of software, in this case distribution with the SolarWinds situation. We’re not going to be talking about that, but strongly the topic of secure applications is right in there, right at the top of the list. Let’s first start, I know we’re going to get into some coding standards and some things like that to equip people with some things that they can use. Maybe we first start with DevOps is more than just – and shift-left is more than just, okay, let’s start having meetings or talk on Slack with the security people and then suddenly we’ve shifted left. You know, there’s a lot more to how we really integrate security into the process of creating software. Maybe, Stuart, if you want to start sharing some of your thoughts about that and of course, Jill, get your perspective as well. 

    Foster: Sure, yeah. I mean you think about DevOps, you think about agile development and it’s the ownership of code; but outside of simply delivering functional requirements for your products, your applications, you know, a lot of teams are just thinking about security. So there’s a necessary to build that in directly. And what that leads you in to is selecting tools, selecting processes to ensure that you’re kind of baking in the security into your pipelines and making it automatic. That starts with thinking about coding standards and things like that. So there’s plenty of secure coding standards that you can focus down on. I think Jill has a couple of words for that.

    Ashley: I’m sure you do. Go ahead, Jill.

    Britton: Oh, I have many, many words on that. The important thing is that you pick the standard that you are going to be comfortable with, that you are going to be able to apply. If you’re supplying a product to a supplier, you will probably be told which ones to use. But you’ve got I think that cert – oh, where, it’s from Carnegie Mellon University. They’ve been looking at security for many years now and it builds up and it also takes experience from both academia, tools, developers, actually anybody who wishes to contribute and then of course it is looked at all the contributions. So this good security standard because it is there.

    But connected to that you’ve got the Common Weakness Enumeration so administered MITRE, and that is actually just a collection of vulnerabilities that have been seen and proved in the field. So you’ve got this whole wealth of experience and you want to avoid doing what the problems other people have seen. That’s where these kind of standards come in. CWE I would argue isn’t a coding standard. It’s more a measure. You know, have I seen this problem? Have I got this problem? And there’s another related set of numbers, let’s put it that, which is common vulnerabilities and that’s even further down the line. Before you even get to see weaknesses, there are vulnerabilities and you just have to use this information in your own developments. Don’t do what somebody else has already done is kind of the way to look at it in security in particularly. 

    Ashley: It isn’t like we don’t know how to create secure software. We do but we kind of do the same thing over and over, the same mistakes, right? 

    Britton: That’s right. 

    Ashley: Sometimes just out of not knowing and sometimes just human error. Sorry, Stuart, you were going to jump in there too. 

    Foster: I was going to say, so effectively one of those, CWE is effectively describing issues that are not necessarily related directly to a language; and the other ones are specific rules that you follow to ensure that you don’t run in to these types of vulnerabilities or weaknesses, right?

    Britton: That’s right. That’s it.

    Ashley: Yeah, there are specific things that are in Java, PHP, you know specific languages that are very well used, very popular of course. Go ahead, Jill.

    Britton: No, the thing is when you look at the CWEs, they are categorized to languages or to systems or just to general sort of areas; but there are then what they call the lists. So you’ve got a list for C and a list for C++ and there’s a list for Java. Then you also have a top 25. Now a top 25 may or may not apply to your own product, but it’s always worth having a look. If those ones don’t apply, there’s another sort of secondary list. It’s emerging, and you could look there. There’s always something to check against for any sort of software.

    Ashley: Are most of the things on that list you find have been there for a while? SQL injection, buffer overflows, things like that? Or do they tend to be newer things? Are we seeing the same things over or would we find a lot of new things?

    Britton: It’s a variety. You do see the same ones over and over again. There are some weaknesses that were on the 2011 list and are still in the 2020, but there are new vulnerabilities as new types of development come in and you get more skilled hackers really. You’ve always got to consider that the hacker is always one step ahead.

    Foster: And you kind of see that these standards or these top 25 lists, they change after every couple of years and they spend their time kind of reviewing the vulnerabilities that have been found in opensource projects and other places and kind of give them a weighting. So while you may see the top 25 have a pretty similar overlap between multiple years, their rankings change. So it kind of shows to you that in general software is becoming more secure but not as secure in these new areas. So you see some vulnerabilities lower and the new ones come up at a higher rate. I think it also depends on where software development is currently is in terms of market. What’s the new hotness? Is it Internet of Things connected to software? Is there a new language coming out that has never been attacked? So you see the priorities change on these top 25 lists.

    Ashley: Let’s step back for a moment. How would a development team or developer – I assume most folks are probably familiar with at least CBEs or some things like that, but maybe they haven’t dived into the top 25 for CWEs. What’s the best way to do that? Is it just go out and read about them, educate yourself? Do people, do development teams like, okay, I’m gonna dive into this and research a little bit more and I’ll share with you or how do people apply this to their teams?

    Britton: Well, there’s several ways they apply it. Sometimes they just hear about it, something like we’re doing talking today; and they go, oh, is this going to be relevant to me. And look, it’s a few things. As I said, sometimes a supplier specifies the angles to have proof that you’ve checked against this. And of course the static analysis tool, we can map checkers and messages against these vulnerabilities and these weaknesses so that we can show your code is exhibiting these features. But it’s really important to know what you’re going to be looking for and then do something about it as the static analysis tools can show you, yes, you’ve got this vulnerability but really it’s not off point just leaving there. You must do something about it.

    Ashley: You know, it’s interesting. So many, not everyone of course, so many of the vulnerabilities are about input, right, to a user interface of some type, web, OS command, mobile device. It’s a lot about neutralizing, dealing with the input that you’ve received, making sure that they’re not injecting something that they shouldn’t, getting access to a directory, all kinds of things like that. So it’s things that apply across multiple technology stacks and multiple applications. So generally speaking it’s not like this is a skill you’re going to use on one app and then you have to relearn it for the next app. You carry that stuff with you. It’s part of your skillset you build as a software engineer. 

    Britton: Yeah, it’s education, isn’t it? You know, it’s just everybody gets more and more experience of this type of issue. It’s not that long ago that security wasn’t at the heart, but now it is.

    Foster: And if you think about it, you know there’s kind of different levels of maturity in terms of security, right? You start developing because you know you have some types of vulnerabilities and you start working towards that. But if you think more longer term about your projects and how they might be very important IP or pieces of software that are embedded over time, it becomes more important to think about security because, you know, being able to fix some issues that you know about versus following a secure coding standard to ensure that the reliability, the strength and hardening of your software to begin with means that years down the line when somebody has integrated your piece of software into some type of embedded system that can never be touched, then you’re lowering the risk of there being vulnerabilities permanently out in the market for a very, very long time. So that becomes kind of the second level maturity when you’re developing and thinking about developing more secure software.

    Ashley: Now you mentioned, I forgot which one of you mentioned something about you might encounter something under a contract with the customer that requires specific security standards. One example I know that you all deal with quite a bit is ISO 26262 for automotive industry. Here you’re dealing with safety of course as well as security. Talk a little bit about how something – do the industry-specific standards really kind of go off the reservation to do something really different or are they building on what we do generally in software and then applying it to their specific domain?

    Britton: We could take ISO 26262 which is for vehicles. It’s very much good practice. It’s nothing totally off the scale. They recommend for software the use of a coding standard. You are allowed to use any coding standard you like, but then there are specific categories of software violations that you need to be able to detect so whatever you do. MISRA is sort of the classic for 26262 because it was developed for vehicles. But you have other industries with very, very similar requirements from software and now we’re moving into the scale of security. Back to vehicles again, it’s ISO 21434 which isn’t out yet; but that also requires the use of a coding standard and the violations they’re looking for are still very, very similar. It’s the same type of things. Quality software is what we’re always looking for.

    Foster: Because as I kind of mentioned a minute ago, you think about a car, that’s a big rolling embedded system that’s more or less permanent once it’s complete and it’s really hard to fix later. So you can understand how security as an oops, we’ll go back and fix it versus security as a process becomes more important. That’s exactly why ISO 21434 is becoming a thing or will becomes a thing once it’s releases. But we already have customers in industries looking at it and following along and understanding what that impact is going to be because to connect the cars was a big rolling computer.

    Ashley: You know, this is a little bit kind of parallel to just creating software but not too long ago I went through a web trust audit and very much like a standard like you’re describing it is do you have a process, do you have something that you follow, should follow, and do you follow it and do you have evidence of that. So many of the standards are just the technical details of what you should do to write pure code. It’s do you have the processes around that and are you following those and in some cases you do an audit. Necessary if you want a WebTrust, for example, certification or others. So it’s not just writing secure code, it’s if you say you’re going to do it, then you have to do it and demonstrate that you’re doing it and have some form. So what I’m saying is it’s really an investment that you’re making by writing secure code following some of these standards, but then that’s going to help you down the road meet other requirements. 

    Foster: Yeah, it makes it easier when you’re trying to implement say ISO 27001 which is information management security management requirement compliance thing. And there’s controls in there and what you’re talking about per the audit is putting in controls for your business and there are various areas in those controls that in many ways relate to the software that’s developed within the company. So yeah, by following some of these security standards you’re in essence helping with those controls later when/if you go and certify your company as that type of ISO requirement.

    Ashley: You know, Jill, I know you deal a lot with governance and some compliance and things like that. What are some of the best practices around secure software? We’ve touched on quite a few already but are there some other thoughts on other best practices to help people move up that maturity scale?

    Britton: Well, it’s a very basic part of any process really. Choose your metrics. How are you going to actually measure and see how you are progressing through your process? And similarly to software weaknesses, when you get your metrics, what are you going to do with them? There’s no point in collecting a whole collection of them and saying, yep, we’ve got our metrics. What does it mean? Does it mean that we have got 27 security violations last week? Oh, great, we’ve got a number. But what are we going to do about those 27 or so security violations? Again, it’s back to process. What is your process? What is an acceptable level of these metrics? And you can have metrics working all the way through the cycle right from requirements to development and test. You can actually have measures of how you are progressing through your cycle.

    Foster: And also what you find when you look at a lot of these security standards and their vulnerabilities, they have kind of the impact likelihood, cost to remediate, potential issue or risks that you see in the market when one goes out. So alongside that, a lot of the standards as well have kind of a risk scale or a prioritization that helps you – gives you an idea of where to start. And then in terms of the process, it’s not always a matter of running a tool or trying to follow these standards and trying to fix all the bugs. It’s important to start somewhere. What we typically call it is baselining where you kind of know your current quality of your software as it is right now, and the point is to start following a security standard and stopping new vulnerabilities from being introduced, and then you can go back and start working on the prioritization of what to fix to start cleaning up. Right?

    And also when you look at it and it seems insurmountable, you might want to spend some time looking at your past kind of customer weaknesses that were found or bugs that were found and kind of understanding in addition to what the standard is important, looking at what types of vulnerabilities you’ve produced or have reported back and focus there. That’s a good start, you know? You know kind of what your developers’ training weaknesses are and then you can implement kind of teaching, learning, training processes as well to help getting your development team more comfortable, more experienced in dealing with these types of issues. 

    Ashley: Sometimes also building on what you said, it can help bring to light other issues along the process like, for example, we keep getting libraries introduced into code that we don’t realize are there and they show up as a security vulnerability. Okay, well, let’s go fix that part of the process too so we know that those things are there and when updates happen they go through some defined process. Another one might be it’s not just new things we find but also repeats, things we consistently find, occasionally over and over whatever frequency. Okay, if we’re fixing them but how do we stop introducing them? What are good ways to help that? It might be education tools, et cetera. Lots of ways to do that. So to both of your point, to your point too, Jill, don’t ask questions you’re not going to do something about the answer, right? 

    Britton: That’s right. That’s exactly right.

    Ashley: So you have to take action on it and of course that’s ultimately why you’re doing it. You’re not just going through the motions to meet some paper standard because that will catch up with you very quick if you do something like that. 

    Britton: _____. It will. You’re absolutely right.

    Foster: Just buying yourself technical debt and risk.

    Ashley: Yeah, exactly. And it will catch up with you. How do you introduce this to some people words like process, standards, compliance, audits, anything with an ISO in front of it? Those kinds of things just sort of kick up the you’re cramping my style here, right? You’re putting a damper on my ability to be creative and write code. I’m bring a little bit hyperbolic, but not everybody reacts to those things favorably. How do you position this with organization so that it’s not just a dreaded thing we have to do, there’s actually really business value to it and it’s good for you and your career?

    Britton: Well, the whole thing with following a process is the developers can be involved in this process and then go through their careers excel help develop this process. But the process shouldn’t be stifling. It should never stifle the creativity. The whole idea of the process is tell me what you do and how do you prove that’s what you do? Okay, that’s fine. Now maybe how can we tweak it and do a little better? It’s the pro thing of continuous improvement that comes up in all the audits.

    We’re actually ISO 9001 certified. So we’re all going through this on a regular basis. You know, but we’re not trying to stifle our developers. They will say, “Well, okay, we have this process. It’s not quite working for us. Can we make some modifications?” We go, yeah, looks fine. We talk to the necessary people and usually it’s absolutely fine. So we involve the developers all the way through and they will then follow it because it’s their own process. 

    Foster: Yeah, I think the goal is the least amount of friction and introducing it over time. And as Jill said, there’s continuous improvement, right? It’s a long-term goal. It’s not something that’s done once and you get over the big hump of pain and it’s a ton of crunch work. It’s just something that you do over time. You look at agile development, right? People do standups. There’s processes, you know. There’s a level of documentation and planning that isn’t overly annoying. You know, the goal of DevOps is to automate a lot of those finicky processes so that they’re fast, they’re repeatable, they give time back, right? They report information back as quickly as possible so that they can be resolved quickly, right? That’s just lowering the friction, the pain of going back and fixing a feature or some sort of development commit, right? And then you’re just layering on another check layer of security, right? And it should be painless. It should be easy.

    As you mature over time, then the quality is going to get better and that goes back to the metrics that Jill was mentioning, not just having a number but seeing that number go down. And then having your teams be able to see that kind of dashboard or information as a feedback mechanism to say, you know, you can visually see the qualities improving. You know, customer reports of issues from the field are going down because our quality is going up. Why? Not just because of security but because of all the automation and the unit tests and checks that you have written and you’ve made the effort to produce better quality code and it’s going to pay dividends. 

    Ashley: I like the idea of tying it a continuous improvement process whether you label that as quality or other things because you can apply that to your DevOps process, to your tool chain, to the quality of your code, safety, security, making compliance easier for you, just improving your overall how you write software, maybe workflows and things like that. So you can make some of these compliance activities or standards activities really part of just maturing your organization and getting better at what you do, working on the organization as well as in it.

    Question for you, how do things like the privacy laws, you know, GDPR, CCPA for California, do those fall into this realm as well? Do they impact the developers as we’re talking about the use of customers’ information and of course we’re handling that in the applications? Is that something developers need to be that familiar with or is that more of the marketing department that are sending e-mails to people?

    Britton: It’s not greatly down with the developers, but it really depends on the type of data that they’re handling. Looking at the tools that Stuart and I work with, we’re not getting/bringing in external tools because it’s a static analyst tool. So we’re not looking at that. But when you get to things in the field, the developers have to be aware if they are going to be handling personal information and they then do have to have GDPR and that has to be included into any process – how are we going to handle this.

    Foster: Yeah, and there are coding rules that, you know, try to help with these types of things. You know not having hard coded secure passwords, not using magic numbers, various levels of encryption that should be written, or warnings that you’re using an outdated type of like encryption in your software, the ability to handle unvalidated inputs and outputs. Things like that are going to help cover some of the requirements for GDPR. So you need to kind of understand how your system is interacting with other systems and securing your APIs and all things like that. So it’s not just your piece of software at that point. Your developers need to be aware as to how your software is going to be used and implemented and how it’s going to communicate with other pieces of software or systems. 

    Britton: That brings us back to the weaknesses we were discussing earlier because there are weaknesses that actually cover that type of data.

    Ashley: Exactly.

    Britton: What are you doing with it.

    Ashley: Vulnerabilities in our software could lead to the loss of data. That could be a violation of those privacy laws of course, as well as other impacts, whatever it was. Well good. This has been a lot of fun. I’ve really enjoyed talking with you about this aspect of creating secure software. We’ve mentioned static code analysis and tools a little bit. I know this isn’t a commercial about Perforce, but would one of you just kind of position for us where in the process of what we talked about today where Perforce really plays in kind of your specialty in this area?

    Foster: Yeah, sure. So in terms of our product which our static analysis products, both Klocwork and Helix QAC, we fit in many different areas of kind of a development pipeline and process. We exist to make sure vulnerabilities are found while the developer is currently typing their code on their desktop. We also fit in for gated checks and quality checks in your SI/CD pipelines so we can quickly report back issues and also your typical if you’re running a nightly on a server or if you’re deploying checks and building your software in the cloud and provision instances and any sort of thing like that. We’re basically available anywhere. So we help you shift left as far as you want. We provide those security checks anywhere just for the ability to drive what I would call continuous compliance. 

    Ashley: Excellent. Great. Well, Stuart, Jill, it’s been a lot of fun talking with you and hope everyone – wish you the best in your journey on creating even more secure software. We’ll speak with you again soon. Take care. 

    Foster: Awesome. Thanks, Mitch. 

    Britton: Thanks.

  • DevSecOps Implementation: Intrusion Detection

    DevSecOps Implementation: Intrusion Detection

    Originally, this series was just going to be four articles on the DevSec side of DevSecOps. There are many reasons for this, but primarily because that side is cleaner. The other reason is that these topics are beyond the work we were doing at Accelerated Strategies Group.

    But we’ve had a number of requests to continue, and I’ve used many tools in the space, so on we go.

    Intrusion Detection

    Intrusion detection (IDS) started because attackers were getting through firewalls, and, once inside, seemed to have free rein. Intrusion detection wanted to offer another option for detecting and stopping attackers by watching things inside the firewall for indications your organization had been compromised. Relatively quickly, intrusion detection was supplemented by intrusion prevention (IPS). The idea of prevention was to proactively make changes based upon known issues to keep intruders out. Intrusion detection offered information about what paths attackers were exploiting, and intrusion prevention would plug them. Note that IDS and IPS are often further subdivided into host-based (HIDS) or network-based (NIDS) systems. Since their role – detection of intruders – is the same, for this overview we will discuss them together. A serious deep dive into IDS/IPS should look at HIDS and NIDS separately.

    In the DevSecOps space, some have folded these into security monitoring, but they are still performing the same basic tasks – just much better. In fact, if you found intrusion detection to be limited and clunky to work with because of rules maintenance and fingerprinting issues, it’s probably time to take another look. Here’s why:

    Problems With Traditional Intrusion Detection

    The problems with pure rules-based intrusion detection were two-fold.

    First, rules were hard and fast.

    “Look for X and Y and Z. If all are present, raise an incident.” This tended to result in only two types of rules – ones that were too narrow, and thus brittle, or ones that were too broad and that buried IT/security staff in alerts.

    Second, those rules were outdated before they hit the network.

    The old adage “You are always fighting the last war,” (meaning you are doing what worked the last time you won) is more true in IT security than almost anywhere else. For a rule or a fingerprint to be assembled, it has to have been seen. That means we were perpetually protecting against previously successful attacks and doing little against emerging threats. Security vendors took a lot of steps before coming to our current solution, which is a great step in the right direction.

    Attacks against IT infrastructure share a lot of commonalities. Purely rule-based systems counted on tribal knowledge to code those commonalities into rules. It was clunky and imperfect. Templates helped, by adding common items based upon the type of rule you were creating, but, like rules, they tended to be static and old news.

    Enter Machine Learning

    Bright people with an eye on the ever-changing environment knew that we needed something that could adapt to multiple attack forms/vectors and draw the type of conclusions that security analysts were tasked with. The ability to reduce the number of alerts that get raised is pretty close to miraculous. Anyone with a web presence sees thousands of security events a day, as attack bots and scanners automate chunks of the attack matrix. Some kind of solution to weed out the false information is nearly mandatory, as no organization has the manpower to monitor at those levels and reasonably follow up on threats.

    Machine learning (ML) makes connections between alerts – that might not be a big deal in isolation – and other events that, together, make a case for human intervention. Added to fingerprinting and rules, it is a powerful addition. While a successful attack would require going through rules and making certain you covered the behavior/changes found in the new attack, ML can take that information in and adapt automatically.

    This is cranking through volumes of data we couldn’t even imagine a decade ago, and finding anomalous behavior, correlating it and alerting where necessary. How much it reports up the chain is generally configurable, allowing an organization to tighten the flow of alerts that analysts have to deal with.

    Go With the Flow

    More recently, flow evaluation has become a positive step in the monitoring process. If this connection/user moves from A to B to C, it might be an attack. This allows for another way to rate suspicious activity and raise it to an analyst’s awareness.

    An increasing number of vendors are moving the analysis portion of these activities into their hosted environment. This is a “great strength/great weakness” solution – putting the data points gathered from your system into their cloud allows them to correlate events and improve all customers’ responses. The other side of the coin is that you are paying them operational costs each month, and for most vendors, you’re charged based on how much of the service you use. This has budget implications. It also assumes you have connectivity to their service. If you don’t, for any reason, no analysis will be done on collected data. A careful rollout and contingency planning are in order for this scenario to be successful.

    Integration with security information and event management (SIEM) systems is ubiquitous. We’ll talk about SIEM next; I just wanted to include here that IDS/IPS vendors are feeding SIEM.

    IDS isn’t perfect, and there are a ton of other things out there to help, but it’s a step in the process, one you should consider as you gear up your DevSecOps to professional levels. Some of you are using the tools, but don’t have them integrated into your DevOps systems. This is a nudge to do so. If resolution of an attack automatically creates tickets for Dev to make the code (or ops to make the config) more secure, it absolutely is a plus to the organization responding proactively.

    Keep kicking it. These are just tools, and they’re useless without you. Figure out what your organization needs, and update those needs regularly as the environment (both attackers and architecture) continually changes around you.

  • BYOPC Solves Endpoint Provisioning Challenges

    BYOPC Solves Endpoint Provisioning Challenges

    For many cloud-first companies, workstation imaging isn’t “a thing.” The notion that an IT organization might need several days – or even weeks – to onboard a new employee by provisioning an imaged laptop with correct security policies and only approved applications on it is absurd. The constraints of operating in an admin-centric model for IT service delivery would completely erode the agility that cloud native engenders.

    But let’s say your company was born before the cloud era. Or, suppose your company operates in a highly regulated industry, like financial services or health care, for example. For your company, workstation provisioning may still be a very real thing, and it may be weighing you down. That’s why a bring-your-own-PC (BYOPC) policy could be the answer.

    Now, take that basic provisioning problem and multiply it by a few orders of magnitude. That’s what happened to many companies in the crush to support remote workers in response to COVID-19. Most weren’t ready for the scale of the problem, and some had no means to enable secure remote work for their privileged users. So, when it came time to pivot to a remote-first stance, many IT organizations were unprepared, unprotected and overwhelmed. Between budgeting, acquiring endpoints and the provisioning of those devices, many companies incurred enormous opportunity and financial costs.

    But what if that didn’t have to be the case? What if, instead, there was an option to enable every new employee or newly remote worker instantaneously? What if the company didn’t have to bear the capital expense of purchasing new laptops for each employee? And what if the company didn’t have to carry the operating expense of having an army of IT admins whose job requirements are little more than commissioning and decommissioning workstations as new hires come on, as existing employees pivot from working in-office to working at home, and as others leave the organization?

    Scaling and Simplifying Enterprise Endpoint Provisioning

    Companies can unburden themselves by instituting a bring-your-own-PC (BYOPC) policy. BYOPC allows companies to scale back on investments in new laptops while allowing them to scale up their support for remote work. BYOPC provides employees the freedom to work how and from wherever they want, on whatever endpoint makes them most comfortable. Allowing employees to use their laptop of choice also offers the side benefit of helping to maximize worker productivity.

    At the same time, BYOPC helps companies to reap significant capex and opex savings. Permitting employees to use non-corporate devices reduces demand on IT admins’ time while also avoiding cost attributed to the purchase and maintenance of corporate endpoints. BYOPC, then, is a rare win-win for employees and the IT organizations that must support worker productivity, as long as the IT organization can effectively operationalize it.

    Gartner recognizes that BYOPC is on the rise, saying that companies need to “… support BYOPC practice, as it will be necessary for a long-term work-from-home strategy.” Further, our own research bears this out: in a survey we conducted recently in conjunction with Team8, we found that more than three out of four companies (78%) allow employees to access corporate networks or applications from a non-corporate device.

    Pairing BYOPC with a New Model for Endpoint Security

    Of course, a company can’t simply institute or dramatically scale a BYOPC policy without deploying or commensurately expanding a robust endpoint security policy. And this is where things get interesting: according to Forrester, spending on endpoint security had been rising, year-over-year, even before COVID-19 pushed so many companies to expand their remote access policies. During 2020, that investment has soared. However, we also know that 70% of security breaches start at the endpoint. So, it’s reasonable to conclude that something in the endpoint security ecosystem has to change, regardless of whether companies institute BYOPC or stick with traditional provisioning of corporate-managed devices to provide secure remote access.

    Companies have traditionally relied on a variety of isolated workspace approaches to provide corporate security while permitting workers to download questionable applications or visit dubious websites. Think app sandboxing or legacy remote access solutions like virtual desktop infrastructure (VDI) or desktop-as-a-service (DaaS). VDI and DaaS separate desktop images and applications from the user’s device. The images and applications reside on servers that are usually positioned in the cloud.

    Authorized users access VDI or DaaS resources from thin clients, corporate-managed laptops or user-owned devices, leaving no corporate assets vulnerable on the endpoint. With app sandboxes, threats that come in from the sandboxed application are contained within the sandbox, preventing malware from affecting the operating system (OS).

    These isolation methods have provided some level of protection, but each has shortcomings that experienced bad actors are able to exploit. Likewise, browser isolation is yet another strategy that works well within its confines – blocking malicious web content – but browser isolation also leaves other vectors completely exposed. Given that each of these isolation methods has significant gaps that leave corporate assets vulnerable to attack, the isolated workspaces market has been ripe for disruption.

    That disruption has come in the form of OS-based isolation. OS-based isolation allows an end user to have multiple operating systems on a single endpoint, allowing unrestricted access to the internet, email and non-privileged information via an unlocked OS while reserving a second, privileged OS for accessing only high-value corporate assets, including sensitive data and other systems.

    This privileged OS restricts internet access, prevents the user from installing or running unsanctioned applications, and rejects all peripherals. Corporate data is encapsulated on the same endpoint in the isolated environment and cannot be exfiltrated.

    From an enterprise perspective, key attributes of an enterprise-grade OS isolation solution must include purpose-built tools to centrally manage isolated environments remotely, supported by a robust and fine-grained set of networking, clipboard and data security policies such as access control, application management and insights across the entire workforce. With OS-based isolation, breaches may still happen in the non-corporate environment, but there’s no possibility of exfiltration of malicious code, meaning the corporate environment remains protected.

    There were days when every employer provided its workers with company-managed mobile devices. In many cases, those days are long gone. It may still take a while before the expectation of working on a company-provided laptop becomes nothing more than a memory, too. But the time is right to give workers the freedom to use an endpoint of their choice without opening up the company to security threats. Doing so will make workers happy, relieve the budget pressures on IT, and still allow security teams to sleep at night. That’s what we call a win-win-win trifecta.

  • A Security Vulnerability Management Guide

    A Security Vulnerability Management Guide

    Living in a container-native world is not easy. Containers have a reputation for being a point of entry for security vulnerabilities for many organizations. In 2015, according to a research paper, over 40% of Docker images distributed through Docker Hub had high-risk vulnerabilities; at that time there were more than 95,000 container images hosted on Docker Hub. Today, there are over 3.5 million container images on Docker, and container security is of even greater concern. In a more recent 2020 study by a team of researchers at the Norwegian University of Science and Technology found container image vulnerabilities in certified and popular packages.

    This is just one example of one kind of security vulnerability. This article will share an introduction to security vulnerabilities and the role of vulnerability management for containers and other artifacts in a continuous integration and continuous delivery (CI/CD) pipeline.

    What is a Security Vulnerability?

    A vulnerability is a weakness or flaw present in software. Security vulnerabilities can be present in application dependencies or operating system (OS) packages. Common vulnerabilities include missing data encryption, buffer overflows, missing authentication for critical functions and insecure interactions between software components.

    There are different risks associated with different types of vulnerabilities. With critical or high-risk vulnerabilities, an attacker who exploits your software has the potential to seriously impact your organization. Risks associated with data breaches impact not only an organization, but also its end users and customers.

    Vulnerability Management Techniques

    Vulnerability assessment practices and tools exist to make detecting vulnerabilities simple, accurate and fast. Some of these practices include:

    • Penetration testing – Penetration testing, or pen testing, allows you to identify security vulnerabilities by attempting to break into your own systems to identify weaknesses.
    • Configuration management – Configuration management involves managing infrastructure configurations and identifying missing patches that leave your software service vulnerable to errors and risks. There are tools that provide infrastructure scanning as-a-service to help detect outdated or misconfigured instances.
    • Container and application Scanning – Allows you to detect vulnerabilities in deployable artifacts and running applications. Some available tools for container scanning include Twistlock, Clair and Trivy.

    These practices help build solid, repeatable vulnerability management techniques across your security and delivery teams. One way to scale these security practices is through security automation. Security automation is the use of technology that performs tasks with reduced manual assistance. It ultimately enables users to apply security decisions automatically and secure processes to deliver more robust applications and infrastructure.

    Security Practices in your CI/CD process

    Security automation is a core tenant of DevSecOps. DevSecOps is short for development security and operations, and it describes how organizations deliver and make security decisions and actions within the development life cycle of their valued deliverables.

    DevSecOps is a way of continuously integrating security in the software development life cycle. It’s a way of working and thinking so that security is at the forefront of how security teams deliver business value.

    One way to enable DevSecOps is through your CI/CD pipeline. Today’s enterprises can use CI/CD to accelerate better software delivery, but with that speed it becomes even more important to enable robust security. Vulnerability scanning improves software security while giving individuals across engineering and product teams accountability for each of the processes these teams own.

    Don’t let Security Vulnerabilities Ruin your DevSecOps

    This is a simple, basic introduction to security vulnerabilities and the risks they pose for your organization. There are practices and tools for detecting and reducing security vulnerabilities, and finding ways to incorporate those processes into a CI/CD pipeline is a great way to accelerate your DevSecOps.

  • Managing Data Risk in 2021

    Managing Data Risk in 2021

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

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

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

    Transcript

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

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

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

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

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

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

    Ashley: Mm-hmm.

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

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

    Bennatan: One problem, yeah.

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

    Bennatan: Yeah.

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

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

    Ashley: Mm-hmm.

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

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

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

    Ashley: Mm-hmm.

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

    Ashley: Mm-hmm.

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

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

    Ashley: Mm-hmm.

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

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

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

    Ashley: It does.

    Bennatan: There’s a lot of data.

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

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

    Ashley: Okay.

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

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

    Ashley: Mm-hmm.

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

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

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

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

    Ashley: Mm-hmm.

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

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

    Bennatan: Yeah.

    Ashley: What’s important to the business.

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

    Ashley: Mm-hmm.

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

    Ashley: Mm-hmm.

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

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

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

    Ashley: Mm-hmm.

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

    Ashley: Or protest, right?

    Bennatan: – protest, you know?

    Ashley: Moving of Facebook onto whatever.

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

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

    Bennatan: Yeah.

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

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

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

    Ashley: [Laughter] Yeah, I know.

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

    Ashley: Mm-hmm, mm-hmm.

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

    Ashley: Right.

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

    Ashley: Kinda behind the scenes with the cyber czar.

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

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

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

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

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

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

    Ashley: Mm-hmm.

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

    Ashley: Data retention requirements, yeah.

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

    Ashley: Mm-hmm.

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

    Ashley: Mm-hmm.

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

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

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

    Ashley: Mm-hmm.

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

    Ashley: Yeah.

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

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

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

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

    Ashley: Mm-hmm.

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

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

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

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

    Ashley: Mm-hmm.

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

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

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

    Bennatan: Exactly.

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

    Bennatan: Exactly.

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

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

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

    Ashley: Mm-hmm.

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

    Ashley: Mm-hmm.

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

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

    Bennatan: Yes, exactly.

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

    Bennatan: Hopefully.

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

    Bennatan: Yes.

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

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

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

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

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

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

  • Set DevOps Free With Modern Application Security

    Set DevOps Free With Modern Application Security

    Development teams increasingly use technologies like cloud computing and microservices, in conjunction with DevOps principles, to innovate faster and remain competitive.

    But such progress comes at a cost. The fast pace of DevOps has left security teams scrambling to keep pace and install appropriate security guardrails. Traditional security practices used to occur in the final stages before release. The rapid release cycles of agile software development often make this difficult, if not impossible.

    The speed of development is outpacing the rate at which security teams can check configurations and scan for vulnerabilities, especially as developers now outnumber security professionals 500 to 1 and modern application environments represent a vast attack surface.

    The pressure to keep up, and do so securely, has led to a gradual reframing of DevOps as DevSecOps, where security is “shifted left” and introduced earlier in the software development life cycle.

    Unfortunately, while most businesses understand the intent of DevSecOps, they are still unsure how to translate that intent into action. In fact, just 14% fully integrate security throughout the software development life cycle.

    Recent research also shows that, while 65% of security teams report shifting left, less than one fifth are doing the scans necessary to verify that shift is actually happening. The same report suggests that most security teams don’t have the processes in place to monitor and protect cutting-edge application technologies, such as microservices, APIs and cloud native/serverless.

    This lack of visibility leaves security organizations blind when problems surface in production. The longer vulnerabilities go undiscovered in the development cycle, the more costly they are to fix. A study by IBM System Science Institute suggests that fixing a defect found during implementation can cost six times as much as one identified during early design phases. A defect uncovered in production can cost 100 times as much. Even more disturbing, nearly half of enterprises admit to deploying vulnerable applications, just to meet tight deadlines.

    It’s clear that compliance and security oversight are often overlooked, and even deliberately avoided, in favor of faster, more frequent deployments.

    The Great DevOps-DevSecOps Divide

    One of the most significant issues lies with developers’ ingrained perceptions. In the past, teams worked independently, with rigidly scheduled handoffs between distinct phases of development. Security operations (SecOps) teams often introduced security functions during the final stages of the development and release process, which resulted in delays.

    Successfully putting the “Sec” into DevSecOps depends on changing older cultural biases, reinforcing the need to embrace security and empowering teams with the right tools and automation to make smarter decisions without slowing down the entire organization. In essence, DevOps and security teams are all aiming for the same goal – a high-quality, timely product. The difference lies in how they measure and define “high quality” and “timely”.

    The truth is, development won’t be slowing down any time soon. Thirty eight percent of developers now release monthly or faster, and 54% of containers live for five minutes or less. Viewing security as a separate entity bolted onto the code, instead of a key feature that must be embedded end to end, slows down development processes and reduces efficiency.

    Delivering Speed and Security

    The core questions organizations must answer to improve application security are: What makes it easier for DevOps teams and application security teams to collaborate? And what does built-in security really look like?

    For organizations that want to improve their DevOps security, here are some tips:

    • Automate security as much as possible. Invest in security solutions that can be automated and embedded directly into the CI/CD pipeline. This makes it easier to secure applications without sacrificing development speed for the sake of security. Adopting technologies like static code analysis, dynamic analysis and penetration testing reduces risks and alerts developers to potential problems. There will never be enough security professionals to handle all security issues on their own, so use automation whenever possible.
    • Build security as a guardrail, not a gate. Provide appropriate guidance and tooling, so that security becomes a guardrail rather than a gate. For example, ensuring that DevOps teams have access to templated policies enables them to align applications with security requirements from the outset, without adding unnecessary time to development. Applications and security policies can also be tested as part of the CI/CD pipeline, so they are checked like any other functional specification. In short, it’s important to provide developers with everything they need to create and test applications with the appropriate security controls applied, or they won’t do it. Empowering development teams with a better understanding of security and self-service compliance reduces vulnerabilities and risks to the organization. Developers always want to move faster, so make it possible for them to “speed” safely.
    • Enable more proactive responsibility. The average developer cannot be expected to have the level of expertise necessary to stay current with all the latest security trends—they have enough trouble keeping their programming skills up to date. Reduce complexity and make it easier to gain developer buy-in by selecting solutions that provide simplified, easy-to-understand insights within the CI/CD feedback loop.
    • Make security adaptable, scalable and reliable. Secure applications with solutions that offer consistent, centralized and self-service security for any environment. For example, AI-driven security policy engines are one way to enable the adaptability necessary to support rapid change in applications resulting from CI/CD methodologies. Being able to adapt security policies in response to the latest attacks and identify dependencies makes it easier to assess risk and take action faster.

    The dawn of frictionless and adaptable security

    Security can no longer be an afterthought, bolted on to a process. Today, integrated security must become a normal part of any DevOps implementation. Making security frictionless and adaptable enables development teams to power ahead without fear. Modern application security can be a robust support system that empowers organizations to reach their business goals securely.

  • How Managed Detection and Response (MDR) Solutions Benefit DevOps

    How Managed Detection and Response (MDR) Solutions Benefit DevOps

    Managed Detection and Response (MDR), a relative newcomer in the cybersecurity realm, is starting to have a noticeable impact on enterprises seeking to better secure their operations. Research giant Gartner notes that, “By 2025, 50% of organizations will be using MDR services for threat monitoring, detection and response functions that offer threat containment capabilities.” Despite rising adoption rates, though, much confusion remains about MDR and how it should fit into enterprise IT.

    MDR is typically defined as an outsourced security service that enables organizations to better detect malicious activity over the network. MDR is usually sold as a service, and vendors offer tools and technologies that integrate into a business’s IT to detect and mitigate network intrusions, malware attacks, attempted data theft and other malicious threats. MDR can be a powerful ally in the quest to contain cyberattacks, but only if deployed correctly and leveraged properly.

    Enterprise Benefits

    MDR offers obvious benefits for enterprises, but there’s enormous potential when MDR is integrated with DevOps. Many organizations are turning to DevSecOps methodologies to build cybersecurity into their development and deployment pipelines, and MDR can help.

    “One challenge is that DevSecOps is a term that is poorly defined in most cases, and misunderstood in many others,” said Dave Martin, senior director, product management – threat response at Open Systems. “Some people think of DevSecOps as an extension of a quality assurance department, which means that cybersecurity is mostly an afterthought, and not part of the development cycle. MDR, at least how we do it at Open Systems, brings forth a full-time security operations layer, which includes a security analyst, that can become part of the DevOps team,” Martin said. 

    Martin makes an interesting point. As more organizations attempt to implement DevSecOps, knowledge, along with action, are lacking. MDR has the potential to supplement knowledge and insight into the security posture of the code being generated. Many organizations leave cybersecurity to the network or operations teams, expecting endpoint or network security tools alone to contain threats. However, many threats in the wild may leverage older code, or target unpatched applications. MDR can enable DevOps teams to get ahead of the latest threats by keeping developers informed about evolving threats and vulnerabilities, as well as incorporating tools for continuous cybersecurity into the development and deployment pipelines. One of the core concepts of MDR is providing access to experts that can take action to mitigate an attack. This is an important consideration, according to the Enterprise Strategy Group, which reports that 51% of survey respondents face a problematic shortage of skills in the area of cybersecurity.

    What’s more, MDR becomes a tool to secure the DevOps environment, as well as a tool for developers to make code more secure. “It is critical to find advanced threats, ones that may have bypassed existing security controls, before those threats impact DevOps, yet people need to be made aware of those threats so they are not mistakenly included in the development pipeline,” said Martin.

    Choosing an MDR Provider

    With so many players in the MDR space, choosing a provider that fits into a DevOps and enterprise strategy can be daunting. According to Reports and Data, the global MDR market is expected to grow at a CAGR of 30.4% until it reaches $4.6 billion by 2026. Today, providers number in the dozens, and while many claim they have “complete” offerings, they may not consider the needs of DevSecOps along with traditional network operations concerns.

    There are some important considerations when choosing an MDR platform. For example, visibility of the attack surface is a critical concern. If an MDR provider does not have visibility into all potential attack surfaces, breaches and compromises may still occur. Also, adopters should be keenly aware of how false positives are contained, as well as the level of alert activity. Many cybersecurity solutions can introduce alert fatigue and obscure effectiveness. Automation should be a key part of any MDR solution, as it can help to categorize threats, initiate responses and identify the latest threat trends without human interaction. 

    “MDR should tear down many of the cybersecurity silos that businesses have today, and bring the various pieces of IT together into a unified cybersecurity sensitive culture,” said Martin.

    Ultimately, MDR is about people, processes and technology, and should bring these elements together to ensure success in the ongoing battle against cybercriminals. 

  • Windows Sandbox and Hypervisor-Based Isolation

    Windows Sandbox and Hypervisor-Based Isolation

    Completely securing the endpoint is hard. Securing it without sacrificing user productivity is even harder. Think of a modern laptop running a Windows 10 OS, for example. The OS consists of millions of potentially vulnerable lines of code. It has many legacy components written with old security standards in mind. The kernel is probably executing several third-party drivers that might also be vulnerable. Finally, there are dozens of daily-use applications. Some are provided, managed and patched by the enterprise, while others are installed on demand by users; the latter are not always from legitimate sources, making it harder to track and assess security. Timely detection and prevention of threats is a cat-and-mouse game, where a single win for the attackers is game over for the user.

    Consider, too, the rate at which organizations are moving to the cloud. For those using the endpoint purely as a browser, web isolation products can significantly enhance security by isolating browser access to risky websites and, sometimes, to risky email attachments, too. Using ChromeOS, an operating system built for the cloud with security in mind, can provide additional security benefits.

    But using only a browser is not yet practical for most organizations. Many legacy line-of-business applications are still being used daily. Workers install video conferencing applications to meet with business partners. Developers install and update software for their daily work. Almost every popular, modern cloud application (Slack, Teams, Office, etc.) comes with a full desktop client that offers superior features. For organizations looking to adopt these tools, web isolation solves only part of the problem.

    VDI or Desktop-as-a-Service (DaaS) solutions allow companies to shift corporate application workloads to the data center or the cloud. By limiting endpoint operations to that of a thin client, and only connecting them to this infrastructure, the list of potential attack vectors narrows and becomes very secure.

    But using VDI/DaaS for the entire organization becomes very expensive if massive numbers of users need remote access simultaneously. Further, the user experience and latency are far from ideal, and offline work is impossible. In terms of security, while the endpoint is now more secure, the threat still exists – it just moves to the data center or the cloud, where, in essence, a fat Windows desktop is running. With DaaS, security might be even more challenging when multiple users share the same virtual OS; a single threat can potentially compromise multiple user sessions at once.

    Hypervisor-Based Isolation

    The world trusts modern hypervisors to securely run servers, containers and other workloads in the cloud. Sometimes, multiple hypervisors run side-by-side on the same physical server, though they’re completely separated and isolated from each other. Unlike modern OS kernels, hypervisors are designed to perform a very specific task. Their code base is usually very small, well-reviewed and thoroughly tested, making it very hard to exploit. Empirically, it’s very rare to see a hypervisor-related vulnerability discovered or published.

    Is it possible to secure the endpoint with hypervisor-grade isolation? Imagine a “productivity environment” where workers can browse any website; open any email attachment or install and execute software, all without endangering the corporate environment or the organization’s crown jewels. Even better, malware or attackers who compromise this environment are trapped inside by strong, hypervisor-based isolation boundaries.

    Windows Sandbox

    Microsoft has been investing a lot in virtualization-based security (VBS) in recent years. Hypervisor-based isolation is a key element, whether it’s used to isolate LSA secrets with Credential Guard or to isolate critical Device Guard code. With the release of Windows 1903, Microsoft has introduced Windows Sandbox, describing it as a “lightweight desktop environment tailored for safely running applications in isolation.” Windows Sandbox enables users to spin up, almost immediately, a second, isolated instance of Windows with a click of a button.

    Windows Sandbox is based on the new “Krypton VM Containers” – Hyper-V-backed lightweight containers. The lightness is reflected in:

    • Reduced disk space: The container reuses the host’s binaries, reducing its disk footprint and making it easier to manage. This also means it remains as patched and secure as the host.
    • Optimized memory and CPU usage: The host’s kernel is aware of the container, and manages it as yet another application. That means improved CPU and memory allocation based on actual demand and usage.
    • Paravirtualized GPU: By enabling GPU acceleration inside the container, the CPU has less work to do.

    Unlike web isolation products, Windows Sandbox can isolate almost any application. With the Krypton optimizations, it’s fast and doesn’t place too many demands on hardware (any three-year-old laptop should suffice), making it dramatically more affordable than VDI. The virtualization layer is barely noticeable, making the performance superior to VDI/DaaS.

    The Missing Pieces

    Can Windows Sandbox enable organizations to provide an isolated “productivity environment” while further hardening and securing the host OS? In theory, it could, but in practice, unfortunately, it lacks certain capabilities necessary for enterprise environments:

    • Manageability: It’s hard to deploy and impossible to manage (policies, applications) Windows Sandbox with MDM systems such as Microsoft Intune.
    • Usability: Windows Sandbox is non-persistent. Applications installed by users or administrators are going to be wiped on reboot. User settings, cookies, and browsing history will not be saved.
    • OS integration: While users can install risky software inside the container rather than on the host, they are not forced to do so.
    • Security: While fully isolated in terms of code execution, Windows Sandbox doesn’t provide network isolation. Malware can access and attack other devices accessible by the host, even if behind a Network Access Control (NAC).
    • Software Compatibility: Some applications fail to run or to be installed inside Windows Sandbox.

    Hypervisor-based isolation has clear benefits over traditional security methods. By avoiding the cat-and-mouse game, and moving to “mitigation by isolation”, organizations can increase security and productivity, and reduce costs. Once some of the aforementioned gaps are filled, hypervisor-based isolation could become the future of endpoint security.

  • 7 Trends Influencing DevOps and DevSecOps Adoption

    7 Trends Influencing DevOps and DevSecOps Adoption

    Enterprise technology adoption trends can be broadly categorized under three pillars: infrastructure, architecture and technology. Let’s explore what these trends are and how they influence DevOps and DevSecOps adoption in tech corporations worldwide.

    Trends in Architecture

    In computing, architecture is the collection of protocols encompassing the utility, structure and execution of software applications. Architecture defines how an application works and determines the function of each component, such as data storage and computing capability, for example. Architecture trends directly influence how technology is developed, which also makes it influential on the field of DevOps.

    Trend #1: Monolithic to Microservice Architecture

    The shift from massive, inflexible systems that limit compatibility to lightweight, nimble software has increased DevOps and DevSecOps adoption. As architectures such as containers become mainstream, it is easier than ever for teams to code, debug and deploy software quickly, and work collaboratively. Microservice architecture offers the benefit of quickly being able to install, run and maintain systems, and is a catalyst to greater DevOps adoption, while containers spur DevSecOps adoption.

    Trend #2: Cloud-First Trend

    Mobile-first, cloud-first development has revolutionized data transportation, security and collaboration, and made development efficient, safe and transparent. This approach leads many organizations to adopt DevOps/DevSecOps.

    Trends in Infrastructure

    In IT, infrastructure refers to software, hardware, networking resources, systems and tools that allow companies to operate and manage their production processes.

    Infrastructure trends also heavily influence both the hardware and software tools companies use for tracking and manufacturing their products, and therefore directly impact their willingness to adopt DevOps and DevSecOps.

    Trend #3: Kubernetes Plus/Minus DevOps

    A significant infrastructure trend that affects DevOps is the increasing adoption of Kubernetes by global technology companies. Kubernetes is open-source software designed to orchestrate the management, deployment and scaling of containers, and  has seen widespread adoption in the tech industry. Kubernetes empowers organizations to be more productive, with an emphasis on security and collaboration. Containers in Kubernetes seamlessly allow multiple teams to develop a project simultaneously. Resource management and transparency are significantly enhanced, bugs can be fixed more quickly and work cycles can be shortened.

    Kubernetes and container management systems also reduce the need for human interaction and facilitate a fully automated, ‘NoOps’ scenario. Kubernetes uses a pipeline architecture approach that makes it easier for developers to use AI and ML tools to analyze, predict, and automate data and work processes.

    Furthermore, Kubernetes sets an infrastructure backed on logging, continuous detection, consistency, and self-healing, making it extremely easy and considerably faster for computers to make sense of the data, potentially eliminating human interaction. The infrastructure established by the trendy Kubernetes technology is both advancing and restraining DevOps adoption in companies worldwide, depending on how the companies implement Kubernetes into their work cycle.

    Trend #4: The Agile Infrastructure Trend

    Agile infrastructure for software development has become the standard for software development, and is perhaps the most influential trend impacting DevOps adoption. Agile, like DevOps, focuses on collaboration, organization, diversifying skill sets to achieve resilience, rapid iteration and self-improving work processes. Adapting to an Agile methodology means each team has members skilled in various disciplines that work in concert. Each product delivered is followed by a feedback cycle. Agile teams in an enterprise are transparent, collaborative and resilient to internal and external conditions.

    Trends in Technology

    Advancements in technology enable new ways of thinking and new best practices. As tech trends change, the work cycles, processes and mindsets also evolve.

    Trend #5: Release & Deployment Automation

    Manually moving software between testing and production environments is an inefficient, painful task that must be repeated every time updates are added, new versions are released or new features are built. But with the rise of release and deployment automation, software companies can entirely automate this process, saving time while boosting reliability. With the click of a button, test code can be automatically converted to production-ready work and deployed to version controls or hosting services. With this use of automation, DevOps adoption skyrockets.

    Trend #6: Site Reliability Engineers

    Site Reliability Engineers (SREs) are in huge demand as organizations strive to create highly scalable and secure software. SREs build robust, reliable software that leverages automation, create self-healing systems that focus on operations and align closely with business imperatives.

    Trend #7: Shift Toward AI/ML

    The evolution of artificial intelligence and machine learning is changing our entire perspective on the development and use of technology. With increasing automation, ML systems can process large amounts of data, make reliable predictions and provide extremely accurate analyses. AI can make use of this data and these predictions to determine what to do next, and create truly intelligent machines that can function with minimal human interaction.

    While this makes systems faster, more autonomous and reliable—which aligns with what DevOps promotes—it can eventually create a NoOps cycle that doesn’t require human intervention. In the short-term, this trend does influence DevOps adoption, but, in the long term, AI/ML could ultimately eliminate DevOps altogether.

  • Orchestration Emerges as Crucial DevSecOps Enabler in 2021

    Orchestration Emerges as Crucial DevSecOps Enabler in 2021

    As DevSecOps best practices continue to evolve and mature in 2021, security orchestration is emerging as a cornerstone of a solid defense-in-depth approach to application security.

    DevSecOps assumes organizations will shift responsibility for application security further left toward developers. If this assumption is correct, then developers clearly need access to a range of code analysis tools to achieve that goal. The challenge they face is incorporating tools from multiple vendors within a DevSecOps workflow. At different points in the development process, it may make sense to employ a static application security tool (SAST) versus a dynamic application security tool (DAST) that stress-tests the application just before it is deployed.

    Not surprisingly, providers of these tools are starting to align with security orchestration engine providers. ZeroNorth, for example, recently added ShiftLeft, a provider of a SAST tool, to the list of security tools that can be orchestrated via its software-as-a-service (SaaS) platform.

    Joanne Godfrey, director of product marketing for ZeroNorth, said organizations that have embraced DevSecOps are standardizing on two to three security tools. This mitigates the risk of becoming overly dependent on a single tool to discover vulnerabilities, Godfrey said. No single security tool can uncover every possible vulnerability in a timely manner, so DevOps teams must work to integrate multiple security tools into their workflows.

    Developers need tools capable of identifying vulnerabilities as they write code. They should also construct tests to proactively flag vulnerabilities before those are incorporated into a larger build. New vulnerabilities, however, are discovered all the time and it’s not uncommon for a container build deemed safe yesterday to suddenly need an update as quickly as possible. DevOps teams also need to secure the runtimes and hosts on which application builds are deployed, which typically requires more collaboration with the security teams usually responsible for managing platform security and DevSecOps.

    Despite this need to collaborate closely, the cultural divide between DevOps and cybersecurity teams is often wide. While there’s a lot of interest in DevSecOps best practices, developers don’t always prioritize application security when there are delivery deadlines to be met. This often results in security issues being addressed late in the application development process or, worse, addressed after the fact as part of an update delivered after an application has been deployed in a production environment.

    As application development accelerates, it’s imperative that the current divide between DevOps and security teams is bridged. Short-handed cybersecurity teams simply can’t keep pace with the rate at which applications are being built, deployed and updated. The need to shift more application security responsibility left toward developers increases daily.

    The challenge now is, rather than simply delivering an empty DevSecOps sermon, IT leaders need to practice what they preach and provide developers with the tools and processes required to secure their applications.