devopsy.kinsta.cloud

Tag: security

  • 5 Questions to Ask When Choosing a Cloud-Native Security Platform for DevOps

    5 Questions to Ask When Choosing a Cloud-Native Security Platform for DevOps

    If you work in DevOps, you’ve likely heard the mantra that DevOps success is all about the right people, tools and processes.
    Below, we take a look at how you can address the “tools” part of that equation when it comes to security. Specifically, we’ll discuss which questions to ask and what features DevOps teams should look for when choosing a security tool for today’s cloud-native infrastructures.

    What is Cloud-Native, and What Does It Mean for DevOps?

    Our discussion is informed by two main considerations. First, we’re going to focus on the security challenges that arise in cloud-native environments—which means those built with technologies that include, but are not limited to, containers, serverless functions and (of course) virtual servers.

    Second, we’ll focus on the security needs of DevOps teams. Although DevOps positions may not explicitly involve security, we now live in the age of DevSecOps, and everyone on the DevOps team has a role to play in keeping infrastructure and applications secure. In this article, we’ll consider which types of tools are best-suited to help DevOps teams do that, while also promoting the visibility and collaboration that are essential parts of a healthy DevOps strategy.

    So, those are our goals. Now, let’s look at the questions you should ask as you evaluate cloud-native security platforms for a DevOps organization.

    What Are You Actually Securing?

    This question may seem obvious—so obvious that you may not give it much real thought. But because today’s infrastructures and environments vary so widely, it’s important to step back and figure out what, exactly, you need to secure.

    Are your workloads running in containers? Are you also using serverless functions, or do you plan to add them? How are you orchestrating your workloads? (With the native orchestrator provided by your cloud vendor, Kubernetes running as a service, your own Kubernetes build or something else?) Which new cloud-native technologies do you expect to adopt in the future?

    Answering questions such as these is important to ensure you choose a security platform that can support all of your current and future cloud-native environments. In most cases, you’ll find that security platforms that are purpose-built to secure a range of environments (not just containerized ones, which are usually the focus of most self-proclaimed “modern” security platforms) are the best and safest fit for your needs.

    What Are Your Security Threats (and How Can You Stop Them)?

    This is another question that might seem overly obvious. But here again, the fast-changing nature of threats means that it’s worthwhile to take some time to assess what your threats actually are.

    Keep in mind, too, that the threats faced by your particular team, or the app you deliver, may be different from those that threaten other teams. This is one place where the DevOps principle of cross-organization communication is crucial for effective security management.

    Which Layers Does the Security Platform Secure?

    Scanning container images for known vulnerabilities is good. On its own, however, it hardly amounts to a complete container strategy. The same could be said for setting up a firewall or locking down access control.

    To achieve true security, you need to secure all layers of your infrastructure (including those managed by other teams) against all vectors of attack. For that reason, you want a cloud-native security platform that is designed for holistic security, not a tool that only secures one or two layers.

    Where Does the Security Platform Get Its Vulnerability Information?

    When it comes to identifying vulnerabilities, security platforms can get their information from lots of sources. They could look at a public CVE database or at a list supplied by the tool’s vendor.

    The best security platforms, however, will pull vulnerability data from multiple sources. After all, if you’re only relying on one data source to figure out where the threats are, you are unlikely to catch them all—and just like in the world of Pokémon, catching them all is one of your main priorities for DevOps security.

    How Automated is the Platform?

    Automation is the mother of DevOps (or something like that).

    What I mean is that without automation, you can’t do DevOps very effectively.

    You also, incidentally, can’t do cloud-native security unless you rely heavily on automation. That’s because the highly dynamic nature of containerized, serverless and other cloud-native environments means that trying to interpret all of the data they generate, identify vulnerabilities and react to them manually just doesn’t work. That’s why you want a cloud-native security platform that automates wherever and whenever possible.

    You should still expect to have to perform some tasks manually, of course (which is actually a good thing—if we could automate everything, DevOps engineers wouldn’t need to exist anymore). But to the extent possible, your security platform should automate your security-related workflows.

    — Sonya Koptyev

  • How Secure is Open Source for DevOps? 5 Considerations

    How Secure is Open Source for DevOps? 5 Considerations

    Open source libraries and frameworks have important roles to play in a DevOps culture that emphasizes shorter development life cycles, collaboration and innovation. However, it’s vital not to neglect the security of these open source components.

    This article discusses the use of open source in DevOps and gives you five things to consider in terms of the security of any open source project your teams might want to use in your software builds.

    Open Source and DevOps Overview

    Proprietary applications, many of which are developed within organizations that have adopted a DevOps approach, feature an average of 257 open source components per application. Furthermore, the average percentage of codebases that are open source within proprietary apps stands at 57 percent. It’s clear that open source fits well with DevOps in how it can help deliver quality software that can be rapidly updated and improved.

    In addition to the increasingly popular use of open source libraries and frameworks to deliver ready-made software components, quite a number of tools used in DevOps are actually open source. Examples of open source DevOps tools include Docker and Kubernetes.

    It’s crucial that development teams focus on security when using open source code, components and tools. Several of the most high-profile IT security and software breaches of recent times have resulted from vulnerabilities in open source components.

    To adequately combine security, open source and DevOps, there is a pressing need to shift left and secure the software development life cycle (SDLC), starting from the earliest stages of development.

    DevOps Open Source Security Considerations

    The Need For Security Automation

    An important driving force in achieving the aims of DevOps is to automate as much as possible. DevOps automation strategies include the use of technologies such as virtual machines and containerization to repackage applications into reusable blocks, many of which contain open source code. This high level of automation dramatically shortens the SDLC.

    However, because of this automation and the pace at which code changes and updates occur, security teams are easily left behind, and they might miss out on identifying open source vulnerabilities. InfoSec teams need to figure out ways of automating several of the most important security procedures, such as configuration checks, code analysis and vulnerability scanning. By introducing greater automation into security checks, it’s less likely that DevOps practices will lead to releasing software containing vulnerable open source components. Faster time to market combined with high-quality, secure code is the ultimate goal.

    Securing Open Source Using Open Source Tools

    Given that open source code forms the majority of the footprint of modern proprietary codebases, it makes sense to focus on the security of these libraries and frameworks first. Somewhat ironically, open source tools provide a good way to improve open source security in DevOps.

    For example, teams can use open source software management programs such as JFrog Artifactory to create binary local repositories of open source software libraries and code. These repositories give teams a single place from which they can use the latest versions of open source code that they have deemed to be secure.

    OWASP dependency-check is another useful open source tool for security teams that checks which components an application uses and whether such components contain known vulnerabilities.

    Incorporate Open Source Code-Checking Tools Into Development

    Part of the idea of shifting security to the left involves developers overcoming the inherent tendency to focus solely on application functionality without considering security. While training materials exist that teach the basics of secure apps, developers might find the material somewhat esoteric, particularly if it’s targeted toward InfoSec teams.

    One way to overcome developer resistance and shift security to the left is to integrate some open source code-checking tools into development environments. Tools such as Brakeman or Rubocop are freely available, and they can rapidly check code for common vulnerabilities.

    Hackers Targeting Open Source

    One of the difficulties with the increased use of open source is that hackers and cybercriminals are always aware of components that contain vulnerabilities. The hackers can then use this knowledge to specifically target companies developing software using those components.

    Cybercriminals know that DevOps emphasizes faster time to market, and they are always lurking to find those organizations that have become lax in their IT security checks. The Equifax data breach happened precisely because the company used a vulnerable version of the open source Apache Struts framework. The Equifax case exemplifies the potential danger of open source components in organizations where DevOps and InfoSec are out of sync.

    The Need for Policy and Governance 

    For DevOps and open source to work together to deliver secure software, there is a real need to create dedicated open source policies by DevOps organizations. When developers are given free rein to use open source libraries and frameworks without monitoring or documentation, vulnerabilities creep into applications and future trouble awaits.

    The first step is for organizations to recognize their reliance on open source before forming a governance policy that stipulates how to manage open source inventories to reduce security risks.

    Wrap Up

    Going forward, it’s clear that the open source model offers many advantages to DevOps teams in terms of achieving their goals.  Additionally, several open source tools can even enhance the security of the applications developed in DevOps. However, it’s prudent to understand the security concerns that lie at the heart of open source and shift security left so that any vulnerabilities can be found as early as possible in the SDLC.

    — Limor Wainstein

  • DevOps and Security: Focus on Importance

    DevOps and Security: Focus on Importance

    Why have I written “DevOps and Security” and not DevSecOps or one of the other names that floats around? Because this post is aimed to apply to everyone—not just those far enough along to have melded some of their security practices into DevOps.

    Note: After I wrote this article but before I posted it, Bill Doerrfeld wrote this excellent example/solution post. It’s worth a read.

    From the beginning, DevOps has struggled with a couple of touch points that don’t give themselves easily to the “frenetic movement” of DevOps. Security is one of those items. If your organization does manual vulnerability assessments, it is unlikely that this testing slips well into the DevOps process chain.

    Most organizations that are dead set on making DevOps their primary dev/test/deliver platform have simply put limitations on security—limiting what long-running processes can be part of DevOps or dropping unaccommodating processes altogether. Some spectacular failures have occurred because of this type of thinking—and more will come—but for many the benefits of DevOps outweigh the risks. Will I get flamed for this paragraph? No doubt. That doesn’t make it untrue.

    Given that IT has almost never given security the full leeway/authority that they want—and in shops where IT did, business often stepped in to say no—this really is not a massive change from how we have always done business. Just in the modern development environment, where a ton of libraries come from outside and configuration is software or data, there is a greater risk from running roughshod over the security team.

    So what can security do to minimize the risk? Start looking more at enterprisewide and architectural risk. Accept that app or app portfolio team X is not going to give you time/resources to thoroughly vet their product and focus on things such as configuration files and malicious code embedded in that external library “Bob’s Really Good GIF Drawer™” that the team insists on using. Focus on the database configuration being in GIT or a shared (public/private) repository and what mischief might come about should attackers get at that repository. Run some of the increasingly sophisticated checkers against external libraries and review the results. As has been the growing case for years now, use automation to at least minimally check apps for things such as SQL Injection, but focus actual man-hours in places that might impact more of the organization. It might be worth the fight to get a full-on security review for applications or an application portfolio that touches the customer database, but perhaps not so much for the app used to schedule a conference room, even if customers are using it (unless it touches the customer database, of course; then see the first part of that statement).

    Worry about network configuration as code, database configuration as code and the whole slew of unique security issues that come from public cloud. They’re manageable, and there are tools to help. Just make sure you have it down, because architecture is going to be the new target. A hacker doesn’t have to hack your DC if you left a public cloud storage bucket misconfigured and the data they want is in that bucket.

    In too many organizations, the CISO is increasingly treated as chief compliance officer (assuming compliance does not interfere with DevOps cycles) with less to do with security and more to do with legal protection should security fail. Don’t be that organization. Security doesn’t have to be perfect; it just has to make you a hard enough target that only someone who really has it in for your company will keep trying.

    As for Devs doing Agile and Ops doing DevOps, as has been true from the beginning, some of the security burden needs to fall to you. Security doesn’t have its hands in what you do every day, so ask them for guidance, learn from them; make it so they need to be active in every step, then include them in every step, because the security environment changes faster than almost anything else in IT. And when you are implementing monitoring, include security monitoring. In most DevOps shops, the question isn’t, “What can we monitor?” but rather, “In this wealth of data, what do we want to monitor?” Well, the answer should include, “What security thinks will help protect us and our customers’ data.”

    As automation continues to increase, this tension will continue to ease, and focus can increasingly shift to locking down the really important bits such as database configurations and repositories. Until then, keep fighting the good fight and protect your customers’ ass(ets).

    — Don Macvittie

  • 3 Tips to Build A DevSecOps Organization

    3 Tips to Build A DevSecOps Organization

    For organizations undergoing digital transformation today, modernizing the existing environment can present serious challenges when it comes to security. Whether you’re dealing with a transition from legacy to cloud or hybrid models, or shifting from ITIL and waterfall methodologies to DevOps, the increasing number of technologies and complexity mean you need to rethink your security posture. The traditional approach to security—that is, a static strategy that largely involves patching on piecemeal measures at the 11th hour—is simply not a winning formula anymore, especially when dealing with requirements such as privacy compliance or contractual agreements.

    DevSecOps represents a fundamental shift in which real business needs drive a dynamic, living/breathing approach to security based on continuously changing requirements. To evolve from DevOps to DevSecOps, an organization must focus on integrating security into the very fabric of the software development cycle, and work to increase intelligence, situational awareness, and collaboration.

    Here are three critical ways to consider to ensure your DevSecOps strategy is up to snuff.

    Create a Single Source of Truth

    When you have multiple teams trying to work at breakneck speed, having one absolute source of data is essential. Gone are the days when we could rely on static spreadsheets that lived locally on this or that person’s computer, and even communication mechanisms such as email are too manual and out of sync to be trusted. What’s more, it’s impossible to draw meaningful correlations and map trends if your data is sitting in silos across your organization.

    Creating a single source of truth will ensure the greatest accuracy of information for everyone. You need to pinpoint where your data is coming from, how it should be collected and how it should be shared. You’ll want to integrate your full tool stack and workflow, and harness automation to streamline hand-offs between collaboration tools, system updates, chatbots and more.

    Shift Left: Secure By Design

    Relying on firewalls and antivirus as your primary security measures is a bad, bad habit. The key is instead to shift left of these elements and work to embed privacy from the start. This is the new age of security, using a risk-based approach instead of a reactive one—that is, identifying what needs protection, why it must be protected and how you will do so. It’s also understanding that security should not be just an external threat perspective, but also having visibility into what’s happening internally.

    The key drivers of your secure-by-design approach for DevSecOps should be privacy compliance, contractual obligations and threat models, both known and emerging. The goal here is to be proactive and avoid spending valuable resources to address threats or vulnerabilities that could have been prevented. And in case you didn’t already know, properly written, patched and documented code accounts for about 80 percent of security!

    Understand Your Environment

    If your organization has embraced DevOps, then you’re likely aware of necessities such as process, collaboration and automation. However, these can sometimes come at the expense of other important things, including privacy and security. A lot of this is due to lack of oversight and poor visibility into change management.

    As organizations accelerate their adoption of cloud services, threat vectors are ever-expanding. As such, you need to have complete situational awareness of your organization. You need to know what to monitor for and when, and this cannot be limited to the events directly related to security. Instead, focus on extending your perimeter of knowledge beyond your DevOps pipeline and ensure you’re monitoring everything from operating system logs and directory systems to DNS and servers. Without all of this context, there’s simply no way to correlate security incidents with other data from your IT environment. This is the information you need to document processes, workflows and playbooks, and ensure your teams can communicate and collaborate rapidly to address issues before the business is impacted.

    Remember, when it comes to the ultimate big-picture goal of DevSecOps, it’s always about minimizing the financial impact to your organization. Whether we’re talking about your reputation or lost time and resources, the bottom line is dollars down the drain. And the data is compelling so far—in its “State of DevOps 2017 Report,” Puppet found that high-performing DevOps teams experience a 96X faster MTTR from downtime and a 5X lower change failure rate compared to lower-performing teams.

    This article was co-written by Domnick Eger.

    — Robert Hawk

  • Are Developers Your First Line of Security Risk or Defense?

    Are Developers Your First Line of Security Risk or Defense?

    Every organization on the planet, whether public or commercial, is facing an ongoing challenge: to exist in an increasingly digital space. Past products must transform to meet the digital expectations of their customers, and new products must be built with “digital-first” frameworks in mind. After all, if they fail to meet these expectations, there’s almost certainly a competitor ready to swoop on the opportunity.

    So, what does that mean for all these businesses, old and new? It means they are employing teams of developers to create line after line of the code that forms their digital product or service.

    In this fast-moving, high-pressure environment, CIOs have become the new innovators, and are in positions of immense influence. However, they face a strong demand to meet rapid speed-to-market goals, enhance product quality with each update and increase flexibility. This has led to complex, often fragmented development teams whose primary focus is on rapid development of features and functions, without consideration of the vulnerabilities they could be creating in the code they are so quickly churning out.

    If our data is to remain safe, we must implement a new way of working. Just look at the catastrophic damage Equifax faced following its recent breach: a disaster that occurred as a direct result of insecure coding practices.

    CIOs and CISOs need to consider carefully whether their development teams are in fact the first line of data breach risk in the organization or the security champions, their company’s true “first line of defense” against cyberattacks. If they’re not the latter, they certainly could be.

    Secure Coding Checklist

    Where does your own dev team fit? I have created this Secure Coding Checklist to help CIOs and CISOs identify whether their development teams are truly equipped to be secure coding champions, helping to innovate with faster, better and safer code (or, indeed, whether you’re in need of a more robust security program):

    1. Is there acknowledgment at your executive C-level that traditional network security is no longer enough?

    These days, securing the network layer using traditional security measures is simply not good enough (and, let’s face it, is rarely successful anyway) even against semi-professional hackers. Among many consistent reports, Verizon’s “2017 Data Breach Investigations Report” cites that 35 percent of data breaches today are caused by web application vulnerabilities.

    Web application security is equally as important as network security; ignoring fundamental, protective AppSec measures could leave you well and truly open to a breach.

    2. Are you considering security from the start?

    The current approach to application security utilizes tools that focus on moving from right to left in the software development life cycle (SDLC). This, by design, supports a detection and reaction outcome. This means that security teams search for and detect vulnerabilities code that is already written, then react to fix them. According to the National Institute of Standards and Technology (NIST), it is 30 times more expensive to detect and fix vulnerabilities in committed code than it is to prevent them as they are written in the IDE. This doesn’t even take into consideration the production delays, double-handling and time spent in remedying any issues. Secure code champions start at the extreme left of the SDLC, with a focus on continually training their developers in secure coding, so they can be the first line of defense in their organization, preventing common vulnerabilities from occurring in the first place.

    3. Do you actually make the effort to build security skills, or are you just feeding knowledge?

    The vast majority of security training solutions (online and in-classroom) focus on building knowledge instead of building practical skills. For developers to thrive and engage in writing secure code, they need regular access to hands-on learning that actively encourages them to learn and build their skills in a real environment. They need to learn about recently identified vulnerabilities, in real code, and be able to work in their own languages/frameworks. This learning experience should help them understand how to locate, identify and fix known vulnerabilities in the code they are actively working on in the course of their jobs.

    4. Are you measuring your secure coding skills with real-time metrics?

    A vital step in ensuring a security-first mindset is being built within a development team is to collect and review evidence. Metrics seek to prove to the developer and their organization that their hard work is paying off, and secure coding skills are improving. You can’t improve what you cannot measure. There should be relevant assessments, and these should help identify the progress of your development teams in real-time as well as benchmarking their secure coding strengths and weaknesses for continuous improvement.

    5. How sure are you that any outsourced vendors are actively using secure coding techniques?

    Many organizations decide to contract out development work to other development houses. Whether they exist on- or offshore, their general secure coding abilities and practices are a relative mystery. In the best case, the only form of assurance an organization will receive relating to security is a statement in the contract requiring the deliverable to be “secure.” Few companies actually take the step to verify the skills of these development houses upfront, thus winding up with software that has been built without following sound secure coding practices. Worse yet, if the company is not aware of them, it risks going live with a vulnerable application.

    The most common scenario is that any vulnerabilities get picked up by dedicated security specialists (that come at a high cost) and you are faced with a delay of your go-live date, and possible contractual discussions on who needs to pay for fixing these security weaknesses. However, if you’re smart upfront and assess the application security skills of the developers who are going to build your next application, you save a lot of potential delay, frustration and cash.

    6. Are your developers aware of the most common security weaknesses?

    More than 85 percent of exploited web application vulnerabilities are attributed to just 10 known vulnerabilities—the OWASP Top 10. At a bare minimum, your application security training must cover these, in addition to many more vulnerability types. The training challenges your developers contend with must be actively revised and updated on a regular basis, with new challenges for either new coding frameworks or new vulnerability types.

    7. Do you have in-house security champions?

    Every developer-heavy organization should invest in a security champion—someone who is going to take responsibility for a security standard within the dev team. Their purpose is to be a support point of contact for anyone with questions around security, as well as become the chief advocate for following security best practice.

    8. Have you invested in tools for your developers to make secure coding easier?

    If your organization is one in which agile development is practiced, or indeed you are faced with frequent updates to company-built applications, automating parts of your security is one of the only ways to keep up with the frantic pace and volume of work.

    There are tools available at each stage of the SDLC that will serve as advisers, quality gatekeepers or detection tools. Ideally, you should have IDE plugins that focus on certain types of security bugs and act almost like a “spell-checker” while developers are writing their code. There are others that integrate with the build process, detecting certain types of weaknesses as the code is being submitted to a code repository.

    In addition, some tools run automated tests over the code, simulating attempted hacking once the software is in production. All have their own set of benefits and challenges, and none can provide a catchall, 100 percent guarantee that no security threats exist within the application. The No. 1 preventative measure you can employ is that the earlier you can capture the weakness, the faster and cheaper it is to remediate it with the least impact on your business.

    CISOs and CIOs are essentially forced to quickly and aggressively build their enterprise agile capabilities. As such, secure coding skills will be a weapon—not a hindrance to—innovation, and foregoing them could spell the absolute destruction of company reputation and data. Think twice before you skip this critical capability.

    So, how did your organization fare against this checklist?

    — Pieter Danhieux

  • DevOps Chat: Managing Apple Devices with Fleetsmith

    DevOps Chat: Managing Apple Devices with Fleetsmith

    Managing Macs, iPhones, iPads and other Apple devices at scale is not something really native to iOS or OSX. Enter Fleetsmith. In sort of a Puppet-meets-Apple environment, the Fleetsmith team automates configuration, management and security of your Apple devices.

    In this DevOps Chat we sit down with Fleetsmith co-founder and CEO Zack Blum and company adviser, Puppet co-founder Luke Kanies, to discuss the mission and challenge in managing Apple devices.

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

    Transcript

    Alan Shimel: Hey everyone. Alan Shimel devopsy.kinsta.cloud and we are here for another DevOps Chat. Excuse me. This episode of DevOps Chat features an old friend and a new friend. We have, first of all, cofounder and CEO of Fleetsmith, Zack Blum, who is the new friend. Zack, welcome.

    Zack Blum:  Thanks, so much. Great to be here.

    Shimel: Okay. And then joining Zack is our old friend, Luke Kanies. And Luke really needs no introduction to our audience. Luke is the founder of Puppet.

    Luke Kanies: Famous on the internet.

    Shimel: Famous on the internet, but still puts a token in when he jumps on the subway. But anyway, Luke, welcome.

    Kanies: Thank you very much for having me.

    Shimel: So let’s get this out of the way right away. Luke, what’s your connection to Fleetsmith?

    Kanies: I have been trying to help Zack and his cofounders, trying to tell all the stories of all the ridiculous mistakes that I made in hopes that they make only new mistakes.

    Shimel: Wouldn’t that be a great thing? Man.

    Kanies: We can dream, right? We can dream.

    Shimel: Yeah. I was just going to say, if you can bottle that, man, you really would be famous. So Zack, before we even jump into Fleetsmith, then let – you know, Luke has told us what the connection is. Always interested to hear. How did you hook up with Luke and come about to – I’m going to assume you asked him to an advisor here.

    Blum:  Yeah. Well, it’s funny actually. Even before that, the interesting thing is Puppet itself was the inspiration for us starting Fleetsmith. So the connection goes really far back. I was the IT director at a company called wikia and we had this problem where we needed to manage our device fleet.  So I asked around my peers at IT and security and talked to a guy at Dropbox and asked how they did it internally. And it turns out that they use a bunch of open source tools traditionally used by DevOps pros actually to manage their laptops.

    So I went out and learned all about Puppet and realized, “Oh, my goodness. There is an amazing application opportunity here on the endpoint side.” So long story short, that guy at Dropbox, Jesse Endahl, became our cofounder and CSO; had a product. And Luke and Puppet were a major inspiration. So pretty cool.

    Shimel: Very cool. Very cool. So let’s address Fleetsmith, right? What is it you guys do?

    Blum:  Yeah. Thanks so much for asking. We do a few things. We are a modern Apple device management product. So we help companies manage their corporate Macs, iPhones, iPads, and Apple TVs. And we really try to accomplish four things for our customers. Number one is making on boarding new hires as seamless as possible. So employees ramp right away. We do that by automating new device set up. So straight out of the box, to have a computer set themselves up.

    The second one is we provide fleetwide device intelligence so that IT can see problems before employees get interrupted. We do that with really core reporting on exactly what’s going on out there. The third one is we provide employees with uniform, up-to-date computing environment. We do that through automating OS and third-party app packaging, patching, and the delivery of those as well as config for Wi-Fi printers and other tools.

    And the fourth one, the last one, is we decrease business risk for customers by allowing them to enforce, in an automated way, security best practice so features like disk encryption with automatic key escrow, remote lock and wipe. And so those are the four things we do; really try to help companies of any size, especially small and medium businesses, take those best practices and apply them in an automated way without huge teams and huge _____.

    Shimel: Excellent, man. You know, as crazy as it sounds, I almost feel like you serve an underserved business segment for first trillion dollar company ever, right?

    Blum:  Well, we think you’re right. Yeah unfortunately, too many of the companies that we come across have nothing in place at all; no visibility, no automation around this. Then there are a lot of companies who have something in place and it’s just incredibly tedious to administer. There are so many higher value things that IT and security can focus on than manual packaging of software updates.

    You know, providing great customer service to their employees, helping them do better work. So we are really excited.

    Shimel: You know, but this has always been a – I go back in my years in security. We – the company I helped found, kind of one of the pioneers in what we call the NAC market, the network access control. So it was a little different. As you would log onto a network, we would check your endpoint, whatever that might be, and make sure it conforms to whatever the policy that was set. And part of those policies were; were you up-to-date on your patches and your AVs and all that good stuff.

    Blum:  Right.

    Shimel: And even then – and by the way, this was for three letter agencies and U.S. Department of Defense networks. Even then, checking Macs was like a black hole. Right?

    Kanies: It’s always been that way.

    Shimel: I’m sorry, what?

    Kanies: It’s always been that way, for various reasons. And one of them is that they just haven’t been used as much. The second is that Macs have always been kind of cut out of IT policy. Either the Windows – the IT has always been run by Windows and they either say, no, you can’t have them, or, yes, you can have them, but don’t ever talk to us about them. So they’ve kind of always been out.

    In the last 10, 15 years, Apple has really done a great job of building a device that is better for actual usage. So it started out very much in the consumerization of IT, which is how PCs got started in the ’80s, course, as people bring their own computers in. What then they started bringing their own Macs in. Now you look at, especially small companies, and they’ve gone from, “I’ve got a couple of Macs for my designers.” To, “Everyone have a Mac and I’ve got a couple of PCs because my accounting people have to use the Windows version of Excel for whatever reason.

    Shimel: You know what? That’s exactly it. And it’s interesting that we get this kind of folks coming in. And one of my colleagues just joined here. I apologize. So when Macs were 2 percent of the market, maybe no one cared. But as we were talking off mic earlier, when you started getting to 20 percent or more of the market or thereabouts, that’s a number, right? That’s a sizable amount to worry about.

    But how much are the – and I will throw it both at Luke and Zack. How much are the guys – and due to Apple’s professed policy of not wanting to be in the enterprise or not wanting to be in that business market of being a consumer brand? Right? And as a result, you know, if it walks like a duck, it quacks like a duck, but it’s really not a duck. Right how much of that is to blame here for our, up to this point, neglect of managing Macs in the workplace?

    Blum:  You want to start on that Luke?

    Kanies: Sure. Honestly, I don’t think much is, for at least two reasons.  No. 1 is that it wouldn’t have mattered if Apple had decided they really wanted to be enterprise. They would have failed. We know that because of taking multiple cracks at trying to do enterprise stuff and all of them fail. If they are lucky, they deflate quietly and just get brushed into a corner. If they’re unlucky, they fail relatively spectacularly.

    So Apple has, in the past, fought against its own DNA and lost because that’s how it works, right?  And when you look at Microsoft today and they are resurgent. And one of the ways they are resurgent is that they are doing a better job of being who they are rather than trying to be who they are not.

    I think the second reason is that Windows was incredibly dominant for so long. The way in which Windows succeeded was very business oriented, very – and yes it was kind of user oriented at first, but that was long time ago. You know, when I came up and went to college in the 90s, my – first cut my teeth, I was a Solaris user. I was – back before there was Linux. So even then you wouldn’t choose between Windows and Mac and a corporate environment. You would choose between Windows and Solaris in a corporate environment.

    Shimel: Right.

    Kanies: And again, you had a couple of designers in the corner and they had Macs what they did was really specialized. But I don’t really think it had anything to do with Apple. If anything, Apple was struggling to hold on at all. It was less that they weren’t an enterprise company and more that, “Wow. We found like two people who can’t live without our product that we going to make sure we do everything you can to make them as happy as possible and we’re not going to worry about anybody else. ”

    And it was only when, kind of the world changed a lot, partially because Jobs came back. But partially because the world changed a lot, right? The internet came out. And the reason why you wanted a computer shifted from, “Because I need one for work,” to, “Because I need one at home.” Right? And if the iMac had been 10 years earlier, they wouldn’t have sold any because, why would you have a computer at your house in 1990. There was no – there is not nearly so much reason. But when you can dial-in, when you’ve got Internet, that really changed the world.

    Then the trends, the drivers of computing shifted from entirely business use cases to at least 50/50 personal, business use cases. And one can argue today that the majority of drivers of how people think about their relation to computing is mostly driven by consumer use cases and that pushes to the enterprise. And we’ve seen this consumerization of IT trend going back decades. It’s more of a treadmill or an escalator than it is a one-time blip. But to me, this really explains why it matters now and it didn’t matter before, because that consumer use case driving so much of the story.

    Shimel: Yeah. I mean, so Luke, I’m a little older than you, right? Solaris is … My first company, we ran you know, SPARC servers, UltraSPARC, actually. But –

    Kanies: They may be slow, but they sure are expensive.

    Shimel: Don’t even go there, man. But on top of that, I was an OS2 dude.  I loved OS. I was running OS2 really early on. I still don’t understand why Windows is here and not OS2. But that’s another story.

    Kanies: But you know, one of the things that I think has really enabled this is they used to be such a gulf, such a, frankly, a pain in the butt to move. If your colleague was on Mac and you are on Windows, you just had to give him a word file to use or spreadsheet or anything, for that matter. You know, reformatting discs and doing all that nonsense. Beyond the internet, interoperability between has really, I think forced it.  But that’s – you know, that, it speaks for itself, right? A lot of us are using Macs today. I’m on a Mac right now.

    Zack, one of the – and we shouldn’t just focus on Macs. We should focus on what the iPhones and the iPads and Apple TV and it’s is ubiquitous, man. Nothing drives security people battier then having sort of unknown devices or unmanaged devices or black holes in their network.

    Blum:  Absolutely.

    Shimel: And so I would imagine that’s the allure, if you will, of giving Fleetsmith a whirl.

    Blum:  Yeah, absolutely. And especially with the move to the internet of things. Even with computing devices like iOS and iPad, you had iPads, for example, in nontraditional computer roles like a front desk check in machine or the conference room calendar. Then you have, often, three devices comprising a conference room videoconference set up, right?

    So these aren’t as much for individual employees anymore. These are sort of use case driven, almost appliance type applications. So not only do you have these unassigned, if you will, devices floating out there, they’re just on the internet. The corporate network as far as computer management and security of devices is dead, we need to secure the endpoints wherever they are and provide visibility.

    So that’s one of the great things about a product like Fleetsmith is that we provide that things to security folks whatever network the devices on and whatever its application is. And I wanted to add one thing to what – continue Luke’s first point from before.

    Apple absolutely has been a consumer company and now that there is such a high enterprise market share, they’ve actually stepped up and are building a lot of really great management APIs, kind of recognizing that third-party providers of MDM like us are then able to run with that where that is in our DNA. We are experienced IT and security folks. So they are doing some really exciting stuff that’s enabling further penetration into the enterprise stream.

    Shimel: Absolutely. One other just question. This is something that’s kind of – it’s close to where I’ve come from in some ways. If I’m the IT guy or the security guy, I absolutely abhor having multiple management interface systems that I’ve got to work with. So I’ve got this to manage my Mac stuff and iOS. I got this to manage my Windows stuff. I got this to manage my Linux. I got my cloud management stuff.

    How – does Fleetsmith integrate with any of, sort of the larger Windows or other kinds of device management products out there?

    Blum:  Alan, you’re talking about the fabled, single pane of glass. I think that’s what I’m hearing.

    Shimel: Yeah. Well, the mythical single plane of glass, but okay.

    Blum:  That’s right. Well, you said it. To answer your question directly, we do integrate with G-Suite and Office365 so that when people adopt Fleetsmith they don’t have a ton of manual data entry for their inventory. But aside from that, as far as devices go, there’s kind of the suite – device management, there is the suite approach and the best-of-breed approach.

    Unless you have incredibly, incredibly simple needs, usually the suite approach, you know, these companies that build management for every single OS, really fall short in all but one. They really started as a signal platform and just tacked on a couple of checkboxes. So unfortunately, in today’s world the reality is that if you need zero touch deployment, you need to automate the setup of the devices and you need FileVault disk encryption with automated _____ _____ _____. You need to make sure everything is encrypted. You really need the best-of-breed solution.

    So we do all of Apple and there is some products that do all of Windows, a lot out of Microsoft. And past a certain point, those are pretty much just a requirement today.

    Kanies: I would go a little further and say I would add a different dimension that’s less platform because Puppet, for example, is promiscuously cross-platform, but almost entirely server-side. So you can use, as Zack found in the early days, you can use Puppet to manage your desktops. But what you will find is just a constant low-level of friction in doing so because so much of our workflow, so much of the experience is built around servers.

    You might say, “Why is it hard to – if you are servicing more complicated than desktops why is it hard to manage them?” The answer is, desktops are off all the time, laptops are off all the time, they check in from different networks all the time. You don’t get to decide when is a good time for the user to reboot their computer. The user really has to decide.

    You’ve got to build a completely different experience around the product. It’s something that could be done, but there was a lot of friction. So I would say that I agree with that point, that you got to pick best-of-breed. And part of that dimension is what platform you’re talking about managing. Certainly a Windows solution… A solution for Windows being used to manage your Macs is not a great idea. But also, I think a solution for servers, a solution for back in, is not a great solution to manage desktops and laptops.

    That’s really where you do need a different solution. And not that it’s impossible that you could have a company doing both, but it’s unlikely and it certainly hasn’t happened yet.

    Shimel: Got it. Got it. Got it. Guys, we are right on the top of the hour. Unfortunately, I need to end it right here. But before we do, Zack, really quickly, people can get more information about Fleetsmith at…?

    Blum:  Yeah, just go to Fleetsmith.com.

    Shimel: Okay. And you know what? Maybe we could follow up in a couple of weeks before the end of the year because I do think the whole issue of Mac management as well as non-computer – or nontraditional PC devices, whether they be iPads or some sort of IoT and whether they’re running, frankly iOS or some other non-windows, non-Linux – well, maybe Linux. The idea of keeping them compliant, with whether it be a security policy, access policies, what have you, is a really big problem a lot of companies try to tackle, but they tend to stay in the low hanging fruit way rather than maybe some of the corner cases, as bad as a corner case as it may be, you know, it’s still not the mainstream like that.

    Blum:  Yeah. Absolutely. I could talk about that all day. I would love to.

    Shimel: All right. We will schedule something. Hey Luke, I’m sorry we didn’t have enough time to really dig into what else you got going on. But maybe we can do a follow up at some point on that as well.

    Kanies: That would be great. I will warn you that most of what I’m doing next is pointedly not very DevOps. I took 20 years in one industry. It has been enough.

    Shimel: Thank you.

    Kanies: So there is a lot that I’m working on but it’s taking the lessons of the last 20 years and trying to use some of the same tools in different places with different people.

    Shimel: That’s not a bad thing either, my friend. As you said earlier, it’s life.

    Kanies: Yeah.

    Shimel: Good luck with it though, and we will be in touch. Guys, thanks for being our guests on this episode of DevOps Chat. Fleetsmith.com, that’s; F-L-E-E-T-S-M-I-T-H.com. If you’re looking to manage and secure your Macs or iOS devices, worth checking out.

    This is Alan Shimel for devopsy.kinsta.cloud. Until next time, everyone, have a great day. Bye-bye.

    Kanies: Thanks so much, Alan.

    Blum:  Thanks.

    — Alan Shimel

  • How DevSecOps Can Help Avoid Catastrophic Breaches

    How DevSecOps Can Help Avoid Catastrophic Breaches

    Earlier this year, Tesla’s Cloud was hijacked and used to mine cryptocurrency, exploiting a vulnerability in the company’s Kubernetes cluster. A mountain of FedEx data was recently exposed, affecting 119,000 individuals. The Equifax breach garnered international attention after an estimated 145.5 million Americans were jeopardized. In other news, we’ve reported on how the Vine Docker registry fiasco was hacked, leaving an embarrassing PR trail in its wake.

    What is common across all these scenarios? They arguably could have been avoided with basic safeguards underpinned by a healthy dose of DecSecOps. In hindsight, let’s see what specific strategies developers can adopt to avoid such horrendous leaks.

    Basic DevSecOps Can Prevent Vulnerabilities

    DevSecOps is described as placing security at the forefront of every action. Within the world of cloud tooling, this means instilling protection at every point of the build life cycle. You would think this equates to advanced container and orchestration security, powerful access management and establishing hardened oversight for internal applications, right? Actually, many modern exploits simply involve a lack of basic password protection.

    Case Study No. 1: Tesla Cloud Cryptojacking

    In mid–2018, Tesla’s Amazon servers were hijacked by malware and used to mine cryptocurrency for rogue agents. Similar cryptojacking has transpired at Gemalto, Aviva and others. According to RedLock’s report, the hackers infiltrated the Kubernetes console, which was not password-protected. In one pod, they found access credentials to Tesla’s AWS environment. The breach exposed sensitive telemetry data, though was limited to “internally used engineering test cars only,” according to Tesla.

    How to Prevent

    Password protection for Kubernetes administrative consoles is a readily apparent lesson here. All cloud accounts, even if used internally, must be better-equipped and access credentials sequestered. Surely, instilling a “security by design” mentality can help limit the number of such consoles left accessible.

    Case Study No. 2: Vine Registry Breach

    In 2016 a white hacker by the alias avicoder was able to infiltrate Vine, the video-sharing social network. The hacker used tools to discover subdomains and behind one—https://docker.vineapp.com—found an open Docker private registry that housed the Vine source code. Such a vulnerability could have been used to collect user details or inject malware for malicious purposes. Thankfully, no users were compromised, and the Twitter Bug bounty program awarded avicoder a handsome sum for the discovery.

    How to Prevent

    In this particular incident, there was nothing at fault with Docker or Docker containers. The service (which was meant to be private) was simply left public and devoid of access controls. The lesson is that URLs on the world wide web are just that—publicly exposed to the world. It does not matter if no documentation links to them; such subdomains are easy to discover with crawlers and will be exploited if found.

    Case Study No. 3: Equifax Exploits

    In the Equifax breach, millions of customer records were stolen. The Equifax report notes that hackers exploited a “website application vulnerability.” Further reports detailed that the 2017 breach utilized flaws in Apache Struts, likely through a zero-day exploit, according to the Apache Struts Project Management Committee.

    How to Prevent

    Some note that the deserialization of untrusted data inherent in Apache Struts applications leaves some major vulnerabilities and potentially malicious code execution.

    Containers, due to their short lifespan, are not persistent, therefore making consistent hacking harder. They can also isolate functionalities so as to decrease attack vector. Regarding the Equifax breach, Aquasec speculates that container usage could have lessened the impact:

    “… it’s likely that such a breach would have been more difficult with containers, and that if successful, it would have been less persistent, not as widespread, and mitigated sooner.”

    Some view containers as a formidable force if armed with behavioral analysis and firewalls for network connections. Still, others note flaws in assuming containers are safer.

    Regardless of architecture, In DevSecOps, security for customer data isn’t drafted into the background; rather, it is imbued into the entire tooling process and holds equal footing within each build.

    Instilling a DevSecOps Culture

    Instead of a build-now, secure-later attitude, DevSecOps seeks to elevate security into every decision. With each build, security is melded with greater forethought regarding the repercussions for how data is treated.

    Admin consoles for Kubernetes clusters must be armed and password-protected, and the same goes for private GitHub repositories or Docker registries. Any traversal of data through cloud SaaS services must have authorization in place. A most obvious lesson is to password protect those “hidden” registries with discoverable URLs.

    Bounty programs for white hackers continue to lead to successful bug detection. At least for these institutions, there is less evidence of compromised user data and remediation is quickened.

    Much of this can be distilled by due diligence and through breeding a culture of security. While that’s a little fluffy for some, it apparently still requires repeating for institutions that continually de-privilege these basic safeguards.

    — Bill Doerrfeld

  • Twistlock Releases Cloud Discovery Open Source Tool for Cloud Native Services

    A simple, powerful way for audit and security practitioners to discover all ‘unknown unknowns’ across cloud environments

    PORTLAND, Ore., Nov. 13, 2018 /PRNewswire/ — Twistlock, the leader in container and cloud native cyber security, today announced the release of the open source Cloud Discovery tool. Cloud Discovery gives enterprise infrastructure, operations, and security teams the ability to easily understand and quantify the size of their environment, and get a birds’ eye view of what cloud native services are running and where. The first release supports Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP), with more platforms to be announced.

    Cloud Discovery connects to cloud providers’ native platform APIs to discover services such as container registries, managed Kubernetes platforms, and serverless services, and requires only read permissions. Other key features include:

    • Network discovery to discover cloud native infrastructure and applications, such as Docker Registries and Kubernetes API servers
    • Instantly identify weak settings and authentication
    • Easily integrated into DevSecOps processes
    • Provided as a simple Docker container image that can be run anywhere and requires only read permissions to cloud accounts
    • Works well for both interactive use and automation
    • Outputs data into standard JSON for easy integration with other tools
    • Written in Go

    “In many organizations, IT ops, security, and audit personnel need to discover all the cloud native entities being used at their organizations,”  said John Morello, Chief Technology Officer, Twistlock. “This is often a result of development teams starting up resources and deploying cloud native applications, but the security or operations team may not always know exactly where they’re deploying them. We want to make that easy without creating any new security gaps.”

    “Since our founding, we’ve been committed to enhancing security efforts for the cloud native community through upstream contributions to open source projects,” said Ben Bernstein, Chief Executive Officer, Twistlock. “From creating the authorization framework within Docker and Openshift and secrets management for Docker Swarm, to the release of Cloud Discovery — open source is in our DNA. We hope Cloud Discovery helps the community and look forward to adding new features and components that benefit everyone.”

    View the Cloud Discovery repo (https://github.com/twistlock/cloud-discovery) on Github to get started or contribute to the project.  To learn more, visit Twistlock (https://www.twistlock.com/2018/11/13/open-source-cloud-discovery-tool/).

    About Twistlock
    Trusted by 25% of the Fortune 100, Twistlock is the most complete, automated, and scalable cloud native cybersecurity platform. From precise, actionable vulnerability management to automatically deployed runtime protection and firewalls, Twistlock protects applications across the development lifecycle and into production. Purpose built for containers, serverless, and other leading technologies, Twistlock gives developers the speed they want, and CISOs the control they need. For more information, please visit www.twistlock.com

  • DH2i Launches DxOdyssey for Zero Trust Hybrid/Multi-Cloud Security

    DH2i’s DxOdyssey Set to Disrupt the Multi-Billion Dollar Cloud VPN Market

    DH2i to Demonstrate New DxOdyssey Software at PASS Summit 2018

    FORT COLLINS, Co. – November 6, 2018 – DH2i®, the leading provider of multi-platform Software Defined Perimeter and Smart Availability™ software for Windows and Linux, today announced the launch of DxOdyssey™, its new network security software that dynamically deploys perimeter security where needed in order to isolate services for fine-grained user access, creating a Software-Defined Perimeter (SDP). The new DH2i SDP offering gives medium and large organizations the perimeter security model needed for Zero Trust network connectivity between on-premises sites and/or multi-cloud environments. In addition, the new offering addresses customer desire for a highly scalable, self-healing networking solution that is easy to configure and manage, with a high ROI. DxOdyssey makes the application infrastructure “always-secure and always-on”.

    Today’s medium and large organization security and network admins are well-aware of the difficulties that surround using traditional approaches such as virtual private networks (VPNs) for perimeter security to connect on-premises sites and/or multi-cloud environments. The issues include:

    –        Complex configuration requiring dedicated routers, ACLs and FW policies increasing risk

    –        Users get a “slice of the network,” creating a lateral network attack surface

    –        Inbound connections create attack surfaces (e.g. DDoS)

    –        No ability to reduce attack surfaces with application-level segmentation

    DxOdyssey cross-platform SDP software overcomes these issues without the use and security risks of conventional networking connectivity approaches. DxOdyssey SDP software delivers:

    –        Micro-Perimeters – Application-level micro-tunnels give network admins the ability to deep segment by application, not by network. Limits remote users to fine-grained access to specific services. No ACLs or FW policies to manage. Eliminates lateral network attacks.

    –        Discreet Invisibility – Randomly generated non-standard UDP ports for dynamic on-demand micro-tunnel communications.Servers are cloaked and secured with no open ports. Virtually eliminates network attack surfaces.

    –        Multi-Cloud Secure – Designed to enable secure communications “from any host, to any host, anywhere” with application-level DTLS encrypted micro tunnels and Public Key Authentication. Scales across environments to build a secure hybrid/multi-cloud distributed application infrastructure. No cloud vendor lock-in.

    –        Smart Availability – Dynamic movement of micro-tunnel gateways and application workloads with self-healing automatic fault detection and failover. The perimeter can be orchestrated to change dynamically so that micro-tunnels and workloads always find their best execution venue (BEV). The entire application infrastructure is “always-secure and always-on.”

    –        Lightweight software – Software-Defined-Perimeter solution. Just install on any host and connect.Integrates into existing network infrastructure. No network reconfiguration. No appliances to deploy, configure or maintain.

    “A ‘zero-trust’ methodology assumes that assets, users and resources are untrusted.  To achieve a zero-trust architecture takes an extremely focused and dedicated effort, but can strengthen most organizations’ risk posture,” said Eric Hanselman, Chief Analyst, 451 Research. “IT professionals seeking to secure today’s more complex hybrid and multi-cloud environments and build highly available, application-aware capabilities should consider offerings such as DH2i’s DxOdyssey to move beyond the complexity and limitations of traditional VPNs.”

    “Traditional perimeter security solutions are obsolete for the new IT reality of hybrid and multi-cloud. They weren’t designed for them. They create too large of an attack surface. One need only open today’s paper to confirm this fact. Customers need a new perimeter security model to support hybrid and multicloud computing,” said Don Boxley, CEO and Co-Founder, DH2i.”DH2i’s SDP solution, DxOdyssey, is purpose-built for this new perimeter security reality and is going to disrupt the multi-billion cloud VPN market* because it enables organizations to move away from using a traditional VPN and all of the associated issues for perimeter security. Instead, with DxOdyssey customers can build lightweight dynamic security perimeters to secure application- and workload-centric connections between on-premises and/or multi-cloud environments, with virtually no attack surface.”

    According to 451 Research’s Voice of the Enterprise: Cloud Hosting and Managed Services, Budgets and Outlook, 2017 survey of 644 enterprise IT decision-makers, 58% of organizations are pursuing a hybrid strategy involving integrated on-premises systems and off-premises cloud/hosted resources.**

    DH2i will offer live demonstrations of its new DxOdyssey networking security software, as well as its DxEnterprise multi-platform Smart Availability software for Windows Server and Linux Server databases and stateful Docker containers, at this week’s PASS Summit, Booth # 401 (November 6-9, Seattle, WA).

    Tweet this: .@DH2i Launches DxOdyssey for Zero Trust Hybrid/Multi-Cloud Security — See it live at #PASSSummit 2018 http://dh2i.com/press/ #ZeroTrust #SDN #SoftwareDefined #Cloud #VPN

    *Overall, the global VPN market is valued at $45 billion U.S. dollars in 2014 and forecast for $70 billion U.S. dollars in 2019 (Statista 2018).

    About DH2i

    DH2i Company is the leading provider of multi-platform Software Defined Perimeter and Smart Availability™ software for Windows and Linux. DH2i software products DxOdyssey™ and DxEnterprise® enable customers to create an entire IT infrastructure that is “always-secure and always-on.” To learn more, please visit: www.dh2i.com, call: 800-380-5405 or +44 20 3318 9204, or email: info@dh2i.com.

  • DevOps Chat: The State of Software Security with Veracode’s Chris Eng

    DevOps Chat: The State of Software Security with Veracode’s Chris Eng

    Every year CA Veracode publishes its “State of Software Security” report, chock full of research about how well software is being secured during development and beyond. It’s eye-opening stuff and definitely worth a read for anyone even remotely interested in helping make software more secure.

    In this DevOps Chat, Chris Eng, VP of research at Veracode, recently discussed with me this year’s report findings and some takeaways that are worthy of noting.

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

    Transcript

    Alan Shimel: Hey, everyone, it’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Joining us on this episode of DevOps Chat is Chris Eng of Veracode. Now I’m proud to say, actually, that I know Chris, actually, before there even was a Veracode. But – so it goes back a while. Chris, I don’t remember your exact title, but don’t you head up research at Veracode?

    Chris Eng: That’s right, yeah. VP of research at Veracode.

    Shimel: Yep. Welcome and good to have you back on, Chris.

    Eng: Good to be here.

    Shimel: Yep. So, Chris, you know, I’m gonna assume, if people wanna know who you are, it’s Chris Eng – E-N-G. You could look him up. He’s a bonafide cybersecurity warrior, with a long track record of accolades and just being a great guy in the community. On top of that, though, I’m gonna assume people know that Veracode, for the last couple years, has been putting out a report called “The State of Software Security.” In fact, this is volume nine, so which assumes there was eight before then, right, Chris?

    Eng: That is correct. [Chuckles] We do this every year and it gets bigger and better every year.

    Shimel: Yep. So volume nine, you know, it’s CA Technologies Veracode now, of course. Some changes. And, Chris, it’s kind of your baby, right? You shepherd this report every year, no?

    Eng: I’ve been involved in it since the first year we did it. I mean, certainly, going back to the early years, there were a lot fewer of us sharing the burden and doing all of the writing ourselves. And now, thankfully, we can spread that out among more people and get more eyes on it. And that’s actually one of the things that we did this year that was kinda different, is, in addition to ourselves, we worked with some data scientists, over at Cyentia Institute, to actually help us dig into some of the things we really wanted to probe, around remediation work and looking at different organization behaviors. And I’ll get into that in a little bit.

    Shimel: Absolutely. Chris, before we dive into maybe the specifics of this year, let’s just take a minute and talk about, look, nine years running, my god, how the world has changed in nine years. Right? I was talking to the CIO of Box, Paul Chapman, earlier today, and we were just talking about how the world’s changed, let’s say, in the last 20 years but even in the last 9 years. I mean, what we can – you know, security’s still security, and, unfortunately, we still have incidents; we still have vulnerable software; we still have buggy and have trouble closing up vulnerabilities. But the game has changed, though, too, has it, Chris? When you look back, what do you think that some of the biggest changes are?

    Eng: Yeah, it’s definitely undergone a huge evolution. When we started Veracode in 2006, application testing primarily was companies doing penetration tests, maybe once a year, against their most critical applications. And, if anything changed between those, you know, in that one year, you kinda only had a point-in-time assessment. You had a lot of applications, a lot of pieces of software, that were just never being tested at all. And, since then, companies have realized that, number one, they need to test more frequently. That’s the only way that they’re able to release software that is going to be secure and also be able to drive the speed that they want to release new features and new products. Right?

    The other, I think, realization is that you can’t just focus on the most critical applications to the business because attackers don’t really care how they get in, right? If they find a weaker way to – an easier way to get in, through some weaker application that’s not maybe core to the business but is still connected to the same infrastructure, well, they’re gonna go after that. So there’s been a realization that it’s important to understand everything that you have and to actually build software testing and security testing into all stages of the life cycle, right? Fix early and it’ll be a lot cheaper than fixing later on.

    And, you know, we were looking at some of our stats the other day – this isn’t in the report, but to do the first million application scan for our customers took 10 years; the second million scans took one year.

    Shimel: Wow.

    Eng: Right? So that huge rate of increase is just showing that, across the board, across all industries, company sizes, organizations are realizing that they have to scale their software security programs to cover all the bases. And they have to do it continuously, in order to not rack up security debt. So I think that would be the biggest thing that’s changed in how we approach the problem.

    Shimel: I agree. I agree. But, Chris, really, our time’s limited. Let’s jump into this year’s report. I’ve had a quick look through it, the executive summary and some of the other stuff. Boil it down for our listeners. What do you think are the three biggest kinda metrics or facts that jump out here, that they should be aware of?

    Eng: Yeah. Let me give you just a quick –

    Shimel: Sure.

    Eng: – review on – so, like I said, we do this every year. And we take about 12 months of data, so this is across all of the assessments that we do for all of our customers, and it’s anonymized down, of course, and then we look at trends and try and see what’s going on out there, in terms of application security. This data set is about 700,000 application assessments during a 12-month period, and the one big thing that we’ve been able to do this time that we weren’t able to do in the past is actually look at how long flaws are sticking around once they’re discovered. Right? How long is it taking organizations to fix these flaws?

    And so, when we detect something, we’re able to kinda track it across multiple assessments, so let’s say we scan an application today, we find a bunch of flaws, we fix some of them and not others, and then we scan it again in a week. We’re able to identify that certain of those flaws, the ones that we detect the second time, are the same as they were the first time. And so that allows us to actually track the life cycle of each individual flaw until it’s fixed, right? And so we’re able to look at “What does that flaw persistence look like?” Kind of a survivability analysis.

    And, if you look overall, just across all the flaws that we look at, the numbers are not great. It takes 21 days on average to close 25 percent of the findings, 121 days to get to the halfway point, and 472 days to get to the 75 percent point. So that’s a long time, right? That’s over a year, so it’s not a very rosy picture overall. And so we broke this down and, you know, once the report is out, people can kind of look at “What does that look like in terms of different severities, different industries? What kind of patterns do we see there?” But I think the most interesting one, and the one that’ll be most interesting to you, is around the effect of DevOps or DevSecOps on fix velocity.

    Now we don’t have an easy way of saying, for any given application, “Is this a DevOps shop or not?” Right? We can’t – we don’t have that information, so we have to figure out whether or not we think they are, and the proxy that we’ve been using for that is scan frequency, right? If you’re doing CI/CD, you’ve got your scanning baked into your build process or you’ve got it, some way, baked into your automation. And so, if you’re doing a nightly build, for example, you’re doing a test every night. And so we looked at scan frequency to identify that – you know, we think that probably these applications that are being scanned 300-plus times a year, those are probably DevOps shops, right? And the ones that are scanning one to three times a year, probably not.

    And so we’ve got this broken down into buckets. If you have this in front of you, you wanna jump over to page 39 – it’s Figure 43 – and this is what I really want to – this is sort of a – our hypothesis was like, “Yeah, I bet DevOps shops fix faster because they’re scanning more frequently and they don’t wanna rack up as much security debt.” And, in fact, it does show that. Right? We see this one line on the report that says, “Applications that are scanned 300 or more times a year are fixing – they’re getting to the halfway point of fixing in five days and they’re closing 75 percent of flaws within seven days.” Right? So that’s a huge amount better than those averages that I just described to you.

    And we have this broken down by bucket, right? So you have the 300-plus scans per year, you have 51 to 299, all the way down to one to three scans per year, where it takes close to four years for them to get to the 75 percent close mark. So I think that’s actually – this is what we hoped to see. This is what we expected to see. But it’s nice to see the data prove out that, in fact, yes, when you scan often, when you scan early and you stay on top of the findings, this is actually a very doable thing, right? To fix flaws in a reasonable time frame.

    Shimel: Absolutely. Two things there, Chris. No. 1, I would think hand in hand with the DevOps is automation.

    Eng: Yeah.

    Shimel: Right? I’m wondering if part of it is that, in DevOps-enabled cultures and organizations, organizational cultures, whatever – companies doing DevOps – are they automating the scan process and that’s why we’re seeing them doing 300-plus scans? Right? And then they’re deploying more and, if their MO, if their standard process is “Nothing gets deployed without first being scanned,” right, that’s where you start racking up 300-plus scans. Right? I mean, when you –

    Eng: Oh, yeah. Yeah, we’re –

    Shimel: – build that into your pipeline, right, you build that into your CD process, those scans get done.

    Eng: Yeah, we’re assuming that these – you know, we’ve gotten – I think, at the maximum point, there’s one app that was scanned over 1,000 times and, certainly, that’s – I mean, I really hope that’s not a human uploading something or pressing –

    [Crosstalk]

    Shimel: Right, _____ – hitting the “Scan” button –

    Eng: – a button every time, right?

    Shimel: – every time. You would hope not, right?

    Eng: Right. Right. I’m assuming that even the ones that are scanned 50 times a year, right, which I assume to be every week, I assume that those are also –

    [Crosstalk]

    Shimel: Are still better than once _____ –

    Eng: – _____ _____ through a build pipeline. Right? And, any time you can – I mean, and that’s been a big focus for us, just in general, is “How do we remove any human effort required to do the testing? How do you make it easier and more transparent and just remove any barriers to doing that?” And so –

    Shimel: No, heck, how do you – you gotta build it into your CI/CD pipeline. I mean, it has to be part of that. The same way you breathe air, right? If you stop breathing, you die; you don’t deploy software that’s not been tested and scanned. And –

    Eng: Right. Right.

    Shimel: You know, it sounds so simple, us talking about it, Chris, but here’s the fact, right? And not everyone listening to this in our audience has been in security as long as you have or even I have. And a lot of people see the reports, Chris, and they say, “Oh, my God, this is year nine,” and I forgot how many years Verizon is doing their report, and, every year, it’s hard to show progress in some things, right? We do show “Hey, if you scan more, you’re gonna have less vulnerabilities go out the door that aren’t fixed and that were at least – they don’t stay – you know, they get fixed faster.”

    Eng: Yeah.

    Shimel: But the fact is we’re still seeing – you look at the executive summary here, Chris, and it’s not a rosy picture, as you – I think those were your own words. And we still read about breaches every day and 30 million records here and 20 million here. You know, the non-security person says, “What are we gonna do? When does this fundamentally change?”

    Eng: Yeah, I mean, things don’t get solved overnight, right? I mean, if companies have only realized a few years ago that they need to kinda get a handle on all the things that they have and start understanding what their risk posture is, and they’ve got 10, 20, 25 years’ worth of software, thousands of applications, it doesn’t happen overnight; it’s baby steps. Certainly, starting any new greenfield projects with a proper SDLC that’s identifying and fixing issues early is gonna prevent them from building up even more security debt.

    But, yeah, a lot of these – the way I explain some of these things – for example, pass rates on OWASP Top 10 not getting a lot better or the prevalence of certain flaw categories, like cross-site scripting and SQL injection, staying relatively constant – is that some of the more mature apps that have been scanned for a while now, those are actually decreasing. If we sliced those separately, we would see the rate going down. But, when we look at it in aggregate, out of those 700,000 applications that are part of this data set, a lot of those are things that are just being scanned for the very first time ever. And so they’re gonna have a higher prevalence of some of these issues, that the more mature applications will have gotten rid of already. Right? And so they kind of balance each other out.

    And we see this every time. In fact, we should probably start to report on some of those things separately – it’s kind of a difficult thing to do – but I think what’s happening is some of the newer applications are bringing those numbers up and that’s why we see the lines staying relatively flat. There’s a long way to go, but we do see – you know, and things like the DevOps remediation case I just described. I mean, we see little points of optimism, where you can see a clear correlation between a certain behavior and a certain outcome. And so we like to focus on those things, and, yeah, it’s gonna take a while for most companies to really start to chip away at the legacy applications and getting those locked down.

    Shimel: Absolutely. Absolutely. Chris, we’re just about out of time. I should – we should put this out there: for people who are interested in really kinda digging in on the report, where can they get it from? Go to Veracode.com?

    Eng: It’ll be on Veracode.com, starting on October 24th, and, yeah, they can download it there. There’s a huge amount in here. We break it down into different flaw categories. We look at different industries against each other. There’s even a little geographic breakdown and then, of course, like I mentioned, a huge amount of data around flaw persistence and how long it takes organizations to fix flaws, which, I mean, ultimately, is what’s important, right? Doesn’t matter how often you scan if you don’t fix stuff. Right? You don’t reduce your risk unless you fix stuff. So there’s a lot of great data on that, that we’ve never been able to report out before, so we’re really happy to get those out there.

    Shimel: Absolutely. Well, Chris, you know what? I know I got a little hard on you about the – and it’s not your fault that the security industry – and it’s not the security industry ’cause, God knows, we wanna fix the issues and the problems that cause these breaches and things; it’s really just the state of software and where security lies as a priority in a lot of these organizations and managing their risk and so forth.

    But, by the same token, Chris, you know what? First of all, thank you, thank you, thank you, for being involved enough to do this report every year, and, whether the metrics paint a rosy picture or a sad picture, nevertheless, it’s a picture that needs to be told, right? We need this kind of insight; we need the metrics to understand where we are and where we need to be. And so great job, once again, in putting this together. You know, I think it’s as important for non-security people to read these reports as it is for security people. Right? To really –

    Eng: Yeah, we hope –

    Shimel: To –

    Eng: Yeah, we definitely hope people will get something out of it and, hopefully, kind of use that to think about how they are building their own programs, right – how they’re remediating, what do their numbers look like – and, hopefully, kind of informs how different organizations think about scaling up their programs. That’s what we’re hoping, anyway.

    Shimel: Good. All right. Chris, let’s call it a wrap on this; it’s a Friday afternoon here. And, again, thanks for your insight on the report. Thanks for managing this report year in, year out and being involved with it and helping. And we’ll see you soon. We’re coming into conference season; I’m sure you’ll be busy presenting and getting more –

    Eng: I’m sure, yeah. I’m sure we’ll be bumping into each other pretty soon.

    Shimel: Absolutely. Chris Eng, VP of research at CA Technologies Veracode, our guest on this episode of DevOps Chat. This is Alan Shimel, everyone. Have a great day.

    — Alan Shimel