devopsy.kinsta.cloud

Tag: security integration

  • The Security Pipeline

    The Security Pipeline

    Over the last few years, the ability to secure our applications has grown, and deep integration into the DevOps toolchain has, too. There are more tools doing more security checks protecting more of the infrastructure and source than there have ever been. The key is putting them to use intelligently.

    We now have the ability to secure the image an app is based upon, the images that are derived from that original—complete with supporting software. We can get feeds to tell us which bits of our included open source components are insecure and how to protect them; we can scan the source, the assembled application, the APIs and the network. We can put runtime protections in place in front of web apps and in front of APIs. We can even track the long-tail attacks like slow data extraction that are becoming more common as security tools master more obvious attacks.

    That is a great set of security capabilities. And automation puts every bit of it within reach. Your job is to pick the bits you need to increase the security posture of your environment and get them worked into your specific toolchain. This is not all that difficult, but nothing is free, so you will need at least some implementation time and some staff time to work through results. After all, no matter how automated, current solutions do end with a list of changes that need to be made to increase security. Some tools will put a runtime fix in place immediately, but honestly, that is a patch—it only stays in place until you can fix the underlying issue.

    Integrating all of the great security tooling with each other is another aspect that will require some time. Some vendors cover a massive amount of the security testing needed across markets and technologies. These companies show us that even if an organization would rather use best-of-breed, there is a lot of benefit in increasing integrations. For an easy example, consider this: If the software bill of materials (SBOM) generated during the build steps shows that a given framework is included in an application, then active testing via dynamic or interactive application security testing can include extra tests specific to that library.

    Integrations will take effort, but once they’re in place they will enhance application security. There is no perfectly secure application, but the tooling is available to make a given environment less of a target because it is too much work to attack. And that is what you should be shooting for.

    I’ve said before that making security part and parcel of your DevOps practices is mandatory at this point, but that was in reference to the great DevSecOps toolsets currently out there. I’m suggesting now that we include it all–from design to GitOps runtime drift management. Because we can, and the result is reduced risk to the organization.

    And keep rocking it. Honestly, you’re maintaining something worth protecting–that alone means you are successful, even if you aren’t aware of every issue that crops up. Issues are why you’re there, and the systems keep running because you are.

  • Enterprise Inertia Slowing Down DevSecOps Integration

    Enterprise Inertia Slowing Down DevSecOps Integration

    DevSecOps has become an increasingly popular topic as enterprises grapple with the continuing challenge of improving their cybersecurity infrastructure. As the first quarter of 2020 has come to a close, are we making significant progress in fully integrating the development, operations and security functions in the enterprise?

    The term “DevOps” was first used in 2009 by an IT consultant, Patrick Debois. Little more than a decade later, the IT industry is evolving to DevSecOps in response to the global cybersecurity threat and the realization that a more concerted effort is needed to effectively mitigate risk.

    One of the challenges is that DevOps itself is still not fully utilized in many enterprises, making those organizations more reluctant to embrace the idea of adding tighter integration with security teams and frameworks. Anyone who has worked in an organization knows implementing a cultural shift is difficult at best and not an overnight success. Moving from DevOps to DevSecOps does require such a shift.

    From Inertia to Integration 

    The Oracle Java 8 end-of-life story is a great illustration of the need to better integrate security into development and operations. Java applications traditionally were developed and delivered, and the inevitable security updates became the responsibility of the operations team to update the Java Runtime Environment (JRE) on each system that would utilize the application. This inevitably became a struggle of compatibility issues that resulted in exceptions versus resolving the security issues by updating Java.

    Java 10 resolves this struggle by creating a more symbiotic experience where the runtime components are baked right into the Java application as it is built. With this change, the dev team needs to take ownership of regular updates to the application to resolve security vulnerabilities, but this shift is slow in coming. Java 8 applications are still a critical part of many operations, even after the end of life of version 8, and companies now turn to OpenJDK and Corretto Java to continue in the legacy model.

    This is where inertia comes in. Enterprises stick to legacy systems, such as the Java 8 applications, and continue the cycle of compatibility issues preventing updates required to resolve security vulnerabilities. They have little or no attention from busy security staff, which long ago moved on to critical projects like protecting against the next WannaCry.

    Better integration–putting the Sec in DevSecOps more front and center–can be done.

    Here are some considerations to move from inertia to integration.

    Take Charge

    The concepts of ownership and responsibility need to change. A development team that has created a specific product needs to be responsible for taking care of future application needs, such as patching updates. The old-fashioned “We developed it; now we throw it over the wall to operations” doesn’t work in an integrated environment. The team needs to continue responsibility into the operation phase. This ends the volleying back and forth on who “owns” updates, and makes bugs, fixes and patching the DevSecOps team’s responsibility. 

    Get Your Track Shoes on

    Thanks to the plentiful options technology offers, enterprises are using varied development tools, browsers and vulnerability scans. This adds up to challenges since traditional patching is no longer always possible. At the same time, failure to execute updates in real time leaves the enterprise vulnerable to threats. For example, Microsoft introduced the new Edge Chromium edition which utilizes Google’s Chromium open source framework. Google had three Chrome releases between this year’s regular January and February Patch Tuesday events. This meant Microsoft had to integrate Chromium updates in real time or delay resolution to critical vulnerabilities for its customers. As another example, if an enterprise has an internal browser that used Chromium, the same updates have to be pushed out to protect users from threats.

    Think Totality of a Fix

    The best way to achieve integration is to ensure security is baked in as part of the development and operations process from the beginning. Before a new product/application is launched, a united DevSecOps team will be aware of all the components in that product, all the vendors who will have updates related to those components and the expected cadence of these updates. For enterprises updating a web or SaaS-based application, updates should be doable fairly quickly.

    Make Security First

    Time-to-market pressures abound but the strategic DevSecOps professionals are placing risk mitigation before operational impact. They are doing this in a landscape in which cyber hygiene continues to be an issue. Legacy systems are not being patched correctly; updates are being done too late, or not at all. To counter this, enterprises need to adopt a security first principle and improve the timeliness and thoroughness of patching and updates.

    Know Your Vendors

    A must-do is for DevSecOps to fully investigate what patching/updates a particular third-party vendor provides, what their release cadence is and what risk exposure it may present by not covering certain releases/companies. As part of this scrutiny, discern which vendors are responsive to security risks and which are not. With so many companies–Microsoft, Oracle, et al.–executing varied release schedules, adding automation into DevSecOps can further ensure updates are done in real time and cyber hygiene can be improved.

    Fulfilling the DevSecOps Promise

    DevSecOps can begin to reach its potential by paying attention to the people factor and using technology as a support rather than another headache. Whether an employee is in development, operations or security, they are working for the same organization.

    By introducing more automation into the process, gaining a clearer picture of all relevant components and the third-party vendor release cadence, and making security a participant at the beginning of new product development, smoother updates, better security and a productive culture will result.

  • How DevOps Helps Improve Application Security

    The DevOps trend is gathering pace, evolving from a niche to a mainstream strategy. Organizations are overcoming the barriers to successful implementation and finding real benefits in terms of speed and efficiency. But there are lingering issues to solve with regard to security. As companies look to push more changes to production more quickly, risks increase from multiple areas including integrating third-party software with known vulnerabilities, creating security defects in the code, not being able to fix the security issues that do arise and poor configuration.

    According to the 2015 Cost of Data Breach Study from IBM and the Ponemon Institute, the average total cost of a data breach for participating companies increased 23 percent in the last two years to reach $3.79 million per breach. As DevOps presses ahead, security isn’t being considered often or early enough. Maybe a more “rugged” DevOps approach is needed.

    Building in vulnerabilities

    The vast majority of data breaches last year were entirely preventable. According to Verizon’s 2015 Data Breach Investigations Report, 99.9 percent of the exploited vulnerabilities were compromised more than a year after the Common Vulnerabilities and Exposures database, which lists known information security vulnerabilities and exposures, was published.

    Developers frequently integrate open source code with third-party applications that have known vulnerabilities, providing would-be attackers with a way in. It’s difficult, time-consuming and expensive to close these loopholes after the fact.

    Expand the DevOps mindset

    We see many benefits when development and operations teams work closely together, so perhaps it’s time we applied the same logic to security and risk experts. Putting them into the DevOps mix earlier in the process could lead to an increase in empathy and understanding—and an injection of expertise at the outset that could save a lot of pain later in development.

    Security and risk professionals can work directly with developers and operations to identify and remediate potential vulnerabilities. They can paint a picture of how to decrease the attack surface, set up alerts and boost response times.

    Integrate automated security into your pipeline

    If you can embed security goals into your continuous delivery processes, it should be possible to automate a lot of your security checks. Stick to the same principles as your wider development by making frequent, small, fast improvements to security. Automation can free up your security experts enough to find underlying weaknesses and tackle them.

    The average organization receives almost 17,000 malware alerts in a typical week, but only 19 percent of those are deemed reliable, according to the Ponemon Institute, in this Malware Containment Report. This means two-thirds of security staff time is wasted because of faulty intelligence, at an average annual cost of $1.27 million. Only 41 percent of organizations have automated tools to capture intelligence and assess threats, but those that do report that 60 percent of malware containment can be handled without any human intervention.

    It’s important that security professionals work directly with your developers and operations people to integrate vulnerability tests and security scans into your continuous delivery pipeline. They’re engaged in an ongoing battle with hackers, so make sure to continually review and tweak the tests that are run.

    It also helps to have versioned definitions of all your systems, so you can readily and automatically scan for vulnerable systems when new vulnerabilities are announced.

    Don’t forget to measure

    Testing the effectiveness of your security measures is vital. Run penetration tests and employ destructive testing tools to see how well your processes stand up. Make sure you have clear remediation plans and that you can deploy quickly to roll back or forward to eliminate any vulnerabilities.

    Security is too important to be an afterthought. We know there are lots of benefits to breaking down silos—let’s extend that beyond development and operations to include security. Build it into your continuous delivery pipeline and automate where possible, and you’ll get greater value from your security experts. You’ll also turn out better-quality software.

    About the Author
    cropAndrewPhillipsAndrew Phillips is vice president, DevOps Strategy for XebiaLabs, a provider of automation software for DevOps and Continuous Delivery. He sits on the management team and drives product direction, positioning and planning.