devopsy.kinsta.cloud

Tag: security

  • Moving Things Around: The Acquisition of Protego

    Moving Things Around: The Acquisition of Protego

    I received a note from Protego Labs’ vice president of marketing about Check Point Software acquiring Protego. We see a fair number of acquisition announcements, and usually don’t write about them–though we read them and stay abreast of industry happenings.

    I used to follow Check Point, and haven’t looked into what they’re doing in a while, so I followed through links to both organizations and looked at their products.

    I found myself becoming the wizard that some call Tim. But instead of “What is your name? What is your quest? What is your favorite color?” I was looking into “Where is your site? What are your products? What value do you add?” My beard is kept trimmed, more along the lines of a knight’s, so it makes sense I would ask different questions. As long as I’m not spouting “It’s just a flesh wound,” I figure I’m doing okay.

    First off, this merger makes sense. Protego does it for serverless and Check Point is doing their best to be where your code is running. Indeed, Protego probably needed a merger of some kind because all they do is serverless. Check Point’s Cloud Guard Dome 9, by contrast, will protect access rights and data for serverless, but doesn’t do what Protego does–keep an eye on the code. So this is a good fit.

    But it once again brings to light an interesting issue as you move things from DC to cloud A to cloud B to serverless. Where are your support functions? Networking, security, storage…These things need to be where the code is, but architectural options are more than they’ve been for decades. And the architectures are largely incompatible. Consider network functions for a physical-server based DC versus a VM DC, versus a Container DC, versus Cloud…You get the idea. The array of functionality and where it runs is different. Different in implementation and different in maintenance.

    This was a problem I (and others) pointed out when cloud started taking off: more work for ops, even if some of it is automated. Turns out ops, storage management and security all have more work, because all of those items are handled differently in the different architectures. And Protego had to focus on one to get it right, meaning they needed some kind of merger in the long run.

    So do you. Adding more and more work to ops–be it DevOps or traditional ops–is not the answer. A plan for standardizing is necessary.

    That is one of the big promises of containers, in my opinion. Not only are they more agile and easier to use in a DevOps environment, they are relatively standardized. Ops will still have more work if you’ve got apps in several of those architectures, but containers obfuscate some of the differences and allow standardized networking within the pod/node/group, for example.

    Some functionality just doesn’t fit into containers–you still need a physical network in the DC, or to configure the virtual network in a VPC to get traffic to/from your containers–but much of it does fit. Once at the pod/group, networking is virtual and the same regardless of where the containers are running. Which reduces overhead while making changes easier. The same is true for security, and increasingly for storage.

    There are great companies out there tackling these issues, and I’ll look at them on occasion. Right now, I know my former employer F5 Networks is working to solve the networking services/performance/security issues, and taking advantage of NGINX to handle some parts the core org traditionally hasn’t addressed. There are other companies, I just hear about that one more because I am still very close to some F5ers.

    It is worth planning for and certainly worth looking into more portable options, anything that lightens the load and keeps your great apps running. Keep kicking rear and spinning up apps.

    And don’t call me Tim.

    — Don Macvittie

  • Synack: DevSecOps Being Accelerated by Cultural Shifts

    Synack: DevSecOps Being Accelerated by Cultural Shifts

    The 2020 State of Compliance and Security Testing Report from cybersecurity testing platform vendor Synack claims that some of the world’s largest organizations are encountering a significant cultural shift within their development teams, and that bodes well for those seeking to build DevSecOps teams. For the report, Synack surveyed leaders from more than 300 organizations representing a number of industries and verticals, including technology, government, health care, information technology and financial services. 

    According to the report, a large percentage of organizations and institutions are moving toward a rigorous, continuous testing model to ensure compliance. As part of this shift, organizations are utilizing crowdsourced security testing to achieve regulatory compliance and real security, with adoption expected to increase four-fold in 2020.

    Perhaps those companies are being driven by numerous new regulations on the horizon, including the  California Consumer Privacy Act (CCPA), PCI  DSS 4.0, New York’s SHIELD Act and  other proposed data compliance regulations. Or perhaps the shift toward continuous crowdsourced security testing is being driven by the failures some organizations have encountered with traditional security testing methods, which were performed less frequently and failed to keep up with the CI/CD (continuous integration/continuous delivery) pipelines that many organizations have embraced. 

    Simply put, Agile and DevOps application development and delivery methodologies were poorly served by the traditional, siloed security testing methodologies of the past. A realization that has driven many organizations to embrace the DevSecOps model, in which cybersecurity becomes part of the overall team, having equal standing with both development and operations team members. 

    Organizations pushing ahead with the DevSecOps model quickly realized that security toolsets and team member interactions must change to be successful. Synack’s research bears that out, and the report offers that the adoption of continuous security testing platforms is expected to increase by 4X in 2020.

    “The rapid embrace of crowdsourced security testing has happened because it is proven to work better than traditional security testing methods and addresses the ever-growing talent gap within organizations,” said Synack CTO and co-founder Mark Kuhr. 

    The report found security testing is becoming part of an organization’s normal routine, rather than a once-a-year check of the box focused only on compliance. According to the report, 44% of the organizations and institutions surveyed perform security tests on a monthly or weekly basis, suggesting that they are moving toward a continuous model, which is further enabled by crowdsourced solutions.

    The report also revealed that some 63% of organizations commonly use external vendors to identify and reduce vulnerabilities. However, 52% experience unwanted cost and complexity due to overlap in functionality from using multiple security vendors. Those two data points demonstrate that simplification provided by leveraging a single security testing platform could deliver savings. Synack claims crowdsourced security testing solutions provide 147% higher ROI than a typical pen test and can decrease the burden of testing on organizations by reducing the signal-noise ratio. 

    “This shift toward continuous crowdsourced security testing will allow organizations and institutions to have the best of both worlds by procuring technology that offers efficient and effective results while fulfilling best practice standards such as NIST 800-53 to meet compliance objectives,” said Kuhr.

    “Although we are seeing a move toward a 24/7, 365 security culture at organizations in a wide variety of industries and geographies, there is still ample room for improvement,” said Aisling MacRunnels, Synack’s CMO. “Our survey found that on average, most security tests are lasting just 20 hours. As the number of cyber incidents continues to increase, it will be imperative for decision-makers to implement security testing solutions on a continuous basis with 1500-2000 hours of testing a year.”

    Those increased testing requirements will ultimately become the foundation to build a DevSecOps culture in most any organization bound by compliance regulations.

    — Frank Ohlhorst

  • Survey: DevSecOps Progress Remains Elusive

    Survey: DevSecOps Progress Remains Elusive

    Results of a survey of 103 IT professionals attending the recent DeveloperWeek Austin conference suggests that awareness of cybersecurity issues is clearly rising among developers, yet most organizations still have a long way to go toward before approaching anything resembling adoption of best DevSecOps practices.

    Conducted by WhiteHat Security, a unit of NTT Communications, the survey on DevSecOps adoption finds nearly 75% of developers worry about the security and 85% rank security as being a very important element of the coding and development process. However, nearly half of the respondents said their development teams lack a dedicated cybersecurity expert. Only 30% of respondents said they have achieved security certifications in their current or prior roles.

    More than half (57%) of survey respondents said their teams have the right application security tools in place to incorporate security into the software development life cycle (SDLC). Among those respondents who do use application security tools, a third (33%) scan for vulnerabilities daily, while 29% said they scan weekly and 20% said monthly. The remaining 18% scanned either quarterly, annually or at random.

    Also, 14% said they have not been given the proper tools to incorporate security into the SDLC and a third (33%) were unsure what their organizations provided in terms of cybersecurity tools.

    While the survey finds 57% are realizing that application security should be a key part of the SDLC, it also finds 43% of respondents still prioritize meeting their application release deadlines over security.

    WhiteHat CTO Anthony Bettini said it is apparent organizations are struggling to strike a balance between application delivery velocity and security. Organizations are under pressure to digitize more processes faster. However, that pressure can result in a lot more friction being created between developers trying to meet a deadline and cybersecurity professionals who ultimately are held accountable for the integrity of the overall IT environment, he noted.

    To bridge that divide, Bettini said a lot more work needs to be done in terms of driving the convergence of processes, people and tooling required to achieve DevSecOps. On the plus side, however, he noted within many organizations, DevSecOps is starting to supersede DevOps as a development philosophy.

    The biggest issue organizations may need to worry about as they strive to achieve that goal may be burnout. The survey finds more than half (52%) of participants have experienced burnout as a result of the intense pressures to deliver the applications on time that are secure.

    Overall, the survey makes it clear developers at the very least are willing to pay a lot more attention to cybersecurity. Compared to the way developers tended to view cybersecurity just a few short years ago, that alone represents substantial progress. The challenge organizations face now is finding a way to make it as simple as possible for developers to do the right thing from a cybersecurity perspective. There always will be the natural temptation to address a security issue later in the development cycle to meet a deadline. The trouble is that when cybersecurity issues continue to get kicked down the DevOps road, they all too often wind up becoming a major issue after an application has already been deployed in a production environment.

    — Mike Vizard

  • Why Is Security Missing in Many DevOps Implementations?

    Why Is Security Missing in Many DevOps Implementations?

    The exceptional and ground-breaking, technology-driven opportunities in today’s digitized age come with significant competitive pressures to transform promptly. Specific demands increase due to continuous repeating in response to customer preferences becomes the more deep-seated expectation. To overcome this issue, organizations are shifting toward DevOps as a medium to deliver innovations quickly.

    DevOps also promotes innovation and agile software development but, for optimal results, proper security implementation is required. When business security teams are more cohesive in the development culture it is easier to secure new developments from the start. 

    DevOps is all related to automation and speed. At times this can make the apps in development get exposed to malicious attacks, which results in various scams. However, the end customer is seriously concerned about the security feature. The tools you’re going to choose might be vulnerable to different security issues. Hence, it is essential to select those tools that comply with security concerns, such as the General Data Protection Regulation (GDPR).

    DevOps culture is driven by moving fast yet in small pieces. It offers organizations with a wide range of benefits, which includes cooperation among stakeholders, development processes, improvements in code quality, as well as enhanced business velocity. 

    DevOps is responsible for solving different challenges in the software development process, but at the same time, it also familiarizes new challenges. It is found that less than 46% of IT experts are neglecting security in DevOps design and planning. Such environments end up with an inactive and uncoordinated approach to incident management and mitigation.

    There are several reasons for security being missed during DevOps implementation. Some of them are discussed below.

    Cultural Resistance to Security

    It is a standard view in many organizations that introducing security will lead to a slower development process. However, the overall effort and time cost of catching some security flaws early in the design or development process is much lower than to fix the problematic code and weaknesses later during the development cycle. 

    More Focus on Speed Than Security Teams

    DevOps teams are often associated with InfoSec teams. DevOps induces and modifies code batches over a short period, which might far outpace the speed at which the security teams can keep up with code review. If security—code analysis, configuration checks and vulnerability scanning—is not adequately automated, the DevOps output will eventually be slowed down or result in a lack of security hygiene. 

    Practically, this fallout consists of insecure codes, inadvertent vulnerabilities, hard-coded passwords, misconfigurations and other weakness in-app security that can contribute to operational dysfunction or get exploited by attackers.

    DevOps and Cloud Environment

    A typical DevOps environment is dependent upon cloud deployments, which often shares many cloud security considerations. DevOps teams influence the latest, open-source and even immature tools to manage various security groups and server instances. In this digital age that function at large scale, a slight misconfiguration error or security malpractice can be widely propagated, resulting in extensive operational dysfunction or other exploitable compliance and security issues.

    Poorly Managed Access Controls

    Most of the aspects of DevOps are interconnected, changing rapidly and utilizing secrets. DevOps secrets might include private account credentials, APIs token, SSH Keys, etc. that might be used by both humans and non-humans, for example, apps, containers, cloud instances and microservices. Ineffective secrets management is a common flaw in DevOps environments. It provides a provoking possibility for attackers to interfere with the security and other controls, disrupts functions, steals information and exploit an organization’s IT infrastructure. 

    Moreover, to further advance the workflows, DevOps teams might also allow unrestricted access to some private accounts by multiple individuals, who might share their credentials. This is a practice that eliminates the chances of a clear audit trail. Several methods, configuration management, as well as other DevOps tools, might be granted immense privileges. With access to private accounts, an attacker or even a piece of malware can get full control of the data and systems.

    Security should be a top priority of an organization while implementing DevOps, but due to the practices mentioned above it is often neglected.

    How to Ensure Security in DevOps?

    Sticking to security helps the team to come up with quality code. This practice makes developers write error-free codes. When this culture turns into a norm, it fosters the DevOps efforts as a whole. Below are some of the ways to ensure security in DevOps:

    • Set a priority list and put things according to it. Shift the security focus to the left in the development lifecycle.
    • Ensure that developers are well aware of the security consequences and principles and follow the same path as of yours.
    • Educate and train your developers to use particular tools to build secure systems, as well as also keep your DevOps system safe.
    • Set up an alerting and monitoring system to avoid any damage in the end. 
    • Do have proper metrics and submit reports daily to ensure that everything is under control.
    • Various compliance tools and the best business security systems should be introduced into the toolchains. If the codes fail to pass security tests, the build breaks and does not gets deployed so, sent it back to the developer for further refining.
    • Adopt different configuration managements. It means do scans to identify and remediate possible errors. Stabilize all configurations by using the industry’s best practices. Also, allow continuous configuration and hardening baseline scanning across various servers and codes which are built for cloud assets.
    • Do prioritize the deployment of automated tools to detect possible threats, problematic or vulnerable codes and other issues with process and infrastructure. More strictly, you will match the speed of security to the DevOps process; the less you’re going to come across culture resistance, which is embedded in the security practices.
    • Shift toward the rising trend of DevSecOps. It is a practice of injecting security in the lifecycle of app development. It reduces vulnerabilities and brings security much closer to business goals.

    Final Thoughts

    Security is a crucial element in DevOps implementation because it influences the bottom line of any organization. At times, security is missed out, but if this continues it will eventually lead to exploitation by hackers and loss in customer trust. Remember, everything can be recovered, but once a customer’s trust is lost, it can never be gained again. Thus, it is imperative to ensure security while implementing DevOps and achieve success by leaps and bounds.

    — Farwa Sajjad

  • DevSecOps Adoption and the Web Security Myth

    DevSecOps Adoption and the Web Security Myth

    As DevOps practices have become widespread in the tech community, many people have begun proclaiming the virtues of DevSecOps. As the name implies, DevSecOps is the addition of security into DevOps. Just as DevOps promises better-quality production in less time, DevSecOps promises better security with less time required to achieve and maintain it.

    DevSecOps has many benefits. However, many executives are under the impression they can’t embrace DevSecOps across their entire organization.

    This idea is false. Most organizations that have already adopted DevOps can, and should, take the next logical step and adopt DevSecOps as well.

    ‘It Sounds Great, But We Can’t Use It Here’

    Adopting DevOps requires far-reaching changes throughout an organization. Going to DevSecOps can be similarly disruptive. However, internal disruption is not usually the (perceived) problem with DevSecOps.

    Instead, the problem is usually the network border. Many executives believe that their current web security solutions are incompatible with DevSecOps.

    In many cases, this is actually true. Older approaches to web security are indeed hindrances to DevSecOps practices.

    Therefore, the problem isn’t actually with DevSecOps. The problem comes from the security solutions currently in use.

    Legacy Security Solutions and DevSecOps

    Many organizations are still using appliances (whether physical or virtual) as their primary protection against external threats. A decade ago, appliances were good enough. Today, they’re a competitive disadvantage.

    There are several ways in which appliances are incompatible with DevSecOps:

    • Programmatic control of an appliance is often difficult if it’s even supported at all.
    • Configuring an appliance can be challenging. It often requires a high level of security expertise.
    • Rolling out settings and configuration changes across a bank of appliances can be time-consuming and potentially error-prone.
    • The cost and specialized nature of most appliances make them inconsistent with the DevOps mantra of “cattle, not pets.”
    • Physical appliances do not scale.
    • External-facing applications will be limited in their scaling as well.
    • Appliances are not designed for ephemeral workflows.
    • Appliances are not designed to support infrastructure as code (IaC).

    Security appliances represent a decades-old approach to security, so it’s not surprising they don’t support modern practices. What is surprising is that even many allegedly “cloud-native” solutions aren’t built for DevSecOps, either.

    For example, some require multiple instances to be launched into your environments. Some require additional layers of management just to maintain consistent configuration among them. Many do not provide good support for evolving architectures and expanding deployments. In general, these security products tend to require significant intervention and management, while lacking automated control capability. This all severely limits the use of DevSecOps.

    These appliances and incorrectly labeled “cloud-native” solutions are why many executives believe DevSecOps isn’t an option for their organizations. To be clear, these executives are correct—for as long as they continue to use previous-generation approaches to web security.

    Not Just a DevSecOps Issue

    Older approaches to web security have other problems that go beyond a hindrance to DevSecOps usage.

    For example, appliances are marketed as complete web security solutions, but they cannot actually fulfill this role. Among other things, an appliance cannot defend against a volumetric DDoS. The attack can overwhelm the upstream ISP before the appliance even has a chance to scrub the traffic. This can result in the ISP blackholing all incoming traffic, which makes the targeted site and web applications unavailable to users and customers—which is the exact situation the appliance was supposed to prevent.

    Solving the Problem

    Organizations which are still using older security technologies should re-evaluate this decision. Modern solutions such as cloud web security platforms can provide better protection, along with numerous other benefits. These include full management by the provider, real-time reporting and traffic control, adaptive threat identification based on machine learning and much more.

    When organizations continue to use legacy security solutions, they not only prevent themselves from enjoying the benefits of DevSecOps, they are also missing out on many other benefits as well.

    — Maksim Blishchik

  • The Road Ahead for Security, DevOps Transformation

    The Road Ahead for Security, DevOps Transformation

    Qualys hosted its Qualys Security Conference 19 this week in Las Vegas. Hundreds of attendees from around the world have gathered at the Bellagio hotel to learn more about the current state of cybersecurity and what the future has in store. As you might expect, given the technology landscape today, many of the sessions and discussions have revolved around DevOps and how cybersecurity can adapt to DevOps culture.

    Scott Crawford Qualys Security Conference
    Scott Crawford, Research Vice President at 451 Research presents “The Road Ahead for Security, IT, and DevOps” at the Qualys Security Conference

    The Shifting Technology Ecosystem

    Scott Crawford, research vice president at 451 Research, opened day two of the Qualys Security Conference with his keynote, “The Road Ahead for Security, IT, and DevOps.” Crawford talked about the dramatic changes over the last decade or so—from monolithic to microservices, from standalone applications to integrated software, from Waterfall to Agile, enterprise networks to IoT / OT, from standard networks to 5G wireless, and from traditional IT to DevOps. He discussed the challenges organizations face and the dilemma of doubling down on past success and missing out on innovation.

    With all of the changes from this shifting technology ecosystem, there are consequences. Organizations no longer have a single point of control and IT teams are faced with managing and protecting an increasingly complex web of interconnected platforms, applications and services.

    Security and DevOps

    Crawford also talked about the rise of zero trust. He described it as a sort of mashup of the concept of least privileged access, combined with behavioral analytics and an on-demand, just-in-time approach to managing access. The zero trust paradigm is based on the premise of never trust, always verify—and that means determining who is requesting access, under what conditions they’re requesting access and what actions they intend to perform with that access on a case0-by-case basis.

    He shared the Xebia Labs Periodic Table of DevOps tools to illustrate the overwhelming number of options available and stressed the importance of automation. CI/CD (continuous integration/continuous deployment), RPA (robotic process automation), and SOAR (security orchestration, automation and response) solutions have been developed to help address and manage some of the complexity of both DevOps deployments and cybersecurity.

    Xebia Labs Periodic Table of DevOps Tools
    Xebia Labs Periodic Table of DevOps Tools

    DevOps and Digital Transformation

    Crawford’s keynote was followed by a presentation titled, “The DevOps Transformation of the Qualys Platform: Lessons Learned.” Dilip Bachwani, senior vice president of engineering and cloud operations for Qualys, talked about how the company has addressed the “innovator’s dilemma” and steps it has taken to deal with growing pains as it goes through its own digital transformation.

    Bachwani explained that the engineering team at Qualys has expanded exponentially in a relatively short period. That comes with several benefits in terms of how quickly they can develop and implement new solutions, but the team also faced challenges with balancing that growth and trying to maintain velocity at the same time without sacrificing stability or reliability.

    Just like every other organization going through a DevOps transformation, Qualys has had to break down silos with people, processes and tools. Bachwani explained that they needed to do things differently to automate as many functions as possible. They decided to view infrastructure and operations as software problems and find ways to fully automate deployment and configuration.

    He also emphasized that security must be built in throughout the DevOps life cycle. Qualys adopted a hub-and-spoke DevOps model and developed a robust DevOps toolchain designed to combine and orchestrate an effective set of tools for developing, delivering and maintaining software. Having a standardized toolchain ensures that there is a common platform available to everyone.

    Accelerating Transformation With Citizen Developers

    At the end of Crawford’s keynote, he talked about the lack of people with the right knowledge and skills. Cyber Security Ventures predicts that there will be 3.5 million unfilled cybersecurity jobs by 2021. That’s just cybersecurity. What about developers and other key personnel? Crawford posed the question, “Where will we find the people to do it all?”

    The answer, he said, is citizen developers. What is a citizen developer? It’s a movement to empower employees who are not developers by trade with the tools and support to implement ideas. They are the ones closest to the problem and, arguably, best equipped to understand how to solve it. They don’t need to be professional developers or need experience with coding environments. Low-code and no-code platforms give them the power to turn ideas into solutions.

    A few years ago, George Hulme wrote an article on the growing citizen developer movement. Hulme noted, “The organizations that succeed with citizen development will be those that wholeheartedly embrace the movement and cultivate it, with IT’s help and guidance.”

    The DevOps revolution isn’t going away. Companies that don’t embrace digital transformation will likely fade into oblivion as they are left in the dust by more innovative competitors, and organizations that don’t figure out how to integrate security into the fabric of their culture will struggle against a rapidly expanding and evolving threat landscape.

    At this point, these things are like the ocean tide. It is coming whether you like it or not, and it will destroy those who are not prepared. Crawford wrapped up by asking the audience to consider what their role is going to be in building and maintaining the future of DevOps and cybersecurity.

    — Tony Bradley

  • Three Ways Developers Can Worry Less About Security

    Three Ways Developers Can Worry Less About Security

    Over the past 10 years, developers have risen in organizational importance. They’ve acquired more tools, power, responsibility and autonomy. As part of that evolution, many developers today want to touch all of the layers of code and have their hands in every tool that’s being built. Known as “mechanical sympathy,” developers are taking increased initiative in areas they simply haven’t before–like installing security systems or being in charge of their team’s application security lifecycle.

    While pride of ownership is never a bad thing, in today’s complex IT environments, where organizations are adopting hybrid cloud solutions, microservices and containers–and are required to push applications and software into production as quickly as possible–this simply isn’t scalable. Pursuing mechanical sympathy in this case can be too costly and ultimately become counterproductive–especially when it comes to security, where an attacker only needs to find one vulnerability to gain a foothold in the system.

    Rather than relying on developers to become security experts, organizations should empower them to dig deep on the tasks that matter to them (development) and leverage the expertise of other specialists (security). That way, everyone can focus on their own productivity and deliver the most value to the business.

    Here are three ways developers can let go of their need for mechanical sympathy.

    Consider the Implications of Being Responsible for Security

    Taking on security means abiding by security best practices, like adopting multi-factor authentication and implementing privileged access security for secrets management. None of this is in the typical wheelhouse of the developer, and in fact, developers could actually be increasing risk if they intend on being responsible for security.

    Developers should think of it this way: Imagine something goes wrong with the application you put into production, such as leaking sensitive data based on a mistake in the source code or a design flaw. Do you really want to be the team who’s called? The answer is probably no.

    By focusing on core developer strengths and allowing security teams to handle an organization’s security strategy, developers are able to collectively ship applications that are functionally sound, as well as secure.

    Don’t Solve for Already-Solved Problems

    When it comes to DevOps methodology, there are an increasing number of tools now available that automate time-consuming security tasks–such as automated secrets management, encryption and vaulting solutions–which remove those burdens from developers and allow them to work at true velocity.

    With these tools available, there’s no need to reinvent the wheel. Developers should leverage these assets to their advantage and abstract away complexity to the security team, who should be governing and provisioning security tools so developers can get back to delivering applications to market as efficiently as possible.

    Prioritize the Value Stream

    The aforementioned tools provide a great benefit to developers–freeing them up to focus on more impactful work–but it can be easy for the opposite effect to take hold if developers get mired down in the weeds with them. Instead of trying to specialize in tools such as Kubernetes or OpenShift, which have manufactured obsolescence to begin with, developers should be encouraged to think about the big picture–creating a high-performance, automated pipeline that accelerates software delivery from code to production.

    By focusing on the health of the pipeline, rather than the specific tools within, developers establish a real-time feedback loop that enables them to anticipate the future and see the amazing projects that are truly possible. It positions them as drivers of innovation and increases their sphere of influence across the organization.

    Developers play a critical role in bringing applications and software to market with speed and stability, but when organizations default to letting them own everything from the nuts to bolts, they may end up introducing security issues that could otherwise be avoided.

    The best way to ensure security in the development process, however, is to start with a strong security foundation. Organizations that understand developers and the development process are savvier when it comes to the vulnerabilities that could be inadvertently introduced and are in a better position to secure them with minimal impact on velocity.

    In such a complex and powerful world of cloud, CI/CD and more, when developers are empowered to let go, organizations can better manage and mitigate risk, and deliver higher quality applications that drive true business impact.

    — Brian Kelly

  • DevOps Chat: Holistic Kubernetes and Cloud-Native App Security, With StackRox

    DevOps Chat: Holistic Kubernetes and Cloud-Native App Security, With StackRox

    More than ever, application security is a top priority. Beyond secure coding practices, a holistic app security strategy addresses the full application and infrastructure stack. This includes containers, microservices, orchestration, infrastructure software and the cloud. Bolting on the next security tool may not be the answer.

    Kamal Shah, StackRox CEO, joins us on this DevOps Chat, diving into the need for a systemic security approach across the life cycle of cloud-native, even “Kubenative,” applications. We explore how Kubernetes and cloud-native apps bring access to rich configuration information, usage visibility, runtime context, inherent security controls and compliance. It’s a fascinating conversation that will open up new paths to secure Kubernetes and cloud-native applications.

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

    Transcript

    Mitch Ashley: Hi, this is Mitch Ashley from devopsy.kinsta.cloud and you’re listening to another DevOps Chat podcast. Today I’m joined by Kamal Shah, who’s CEO of StackRox. Our topic today is security in a cloud-native world. Kamal, welcome to DevOps Chat.

    Kamal Shah: It’s great to be here, Mitch. Thank you for having me.

    Ashley: Well, I really appreciate you taking time out of your schedule. I know you’re very busy. Happy to have you on. Would you start by introducing yourself? Tell us a little bit about you and what you do. Of course as CEO we can imagine, but also a little bit about StackRox.

    Shah: Absolutely. So again, I’m Kamal Shah. I’m the CEO of StackRox, and StackRox is a leading provider of security and compliance solutions for your cloud-native infrastructure. So as you’re embarking on your journey towards microservices, containers and Kubernetes, we help you address your security and compliance requirements across the entire application life cycle from build to deploy to runtime.

    Ashley: It’s about secure software, especially in a cloud-native containerized world. That’s for sure. Well, tell us a little bit about how you approach this problem? You know, how do you think about security in a kind of contemporary app development world where you’re doing cloud-native applications? Kub-native, I know is a way that we like to talk about it. How do you approach this from a StackRox standpoint?

    Shah: Absolutely. And so the big trend that we saw when we started the company was that customers were, you know, shifting their monolithic applications built on traditional infrastructure to microservices and containers and as a result security also had to evolve to meet and secure this cloud-native infrastructure. And we saw an opportunity to build a new set of solutions that are purpose built for this cloud-native infrastructure, because when you really think about it there’s fundamental differences between traditional application and traditional security and cloud-native applications and cloud-native security, right? I mean you’re deploying containers; security then has to make sure that it understands the ephemeral and immutable nature of containers and security has to shift left and provide controls and guardrails for the build and deploy side of the application life cycle, not just at run time.

    And equally important, security now has to seamlessly integrate with DevOps processes, automation and workflow, because if you don’t then the DevOps organ is gonna reject—or sorry, the DevOps body is gonna reject the security organ.

    Ashley: [Laughs] I’m glad you talked about it in both ways because Kubernetes, containers, that obviously changed the architecture of software and how we’re doing that in the cloud. You know, it isn’t just about locking down servers anymore. It’s really app security level, but at the same time we’re creating software differently. Can you say some more about what maybe some of the unique challenges are that you’ve had to address for both cloud-native world and also shift left within DevOps?

    Shah: Yeah, absolutely. I mean the one big trend, people talk a lot about microservices and containers, but the other big thing that I would like to call out is that Kubernetes has emerged as the de facto standard for orchestrators, right? We did a survey late last year and again six months later and what we found is the adoption of Kubernetes as the orchestrator has grown from 57 percent of organizations using it to now, you know, over 86 percent of organizations using Kubernetes, right?

    Ashley: Wow.

    Shah: And for the right reasons, because it is really, really hard to scale, manage, and deploy containers in large environments, and Kubernetes was purpose built to help you do that. It was an opensource system developed by Google, and Google today uses Kubernetes or a version of Kubernetes, the internal version, to manage over 4 billion deployments at 4 billion containers at scale. So the first thing here is that you have to appreciate the importance of Kubernetes and you have to make sure that security is focused on not just the container but also at the orchestrator and specifically Kubernetes, right?

    Ashley: Sure.

    Shah: And that itself brings a whole new set of challenges because Kubernetes is a large system with significant operational complexity, right? And they just went through a security audit and the assessment team found that the configuration and deployment of Kubernetes is nontrivial, and I can get into the details as to what those challenges are, but the starting point is to make sure that you’re not just focusing on security at the container layer but also focusing at the Kubernetes layer.

    Ashley: Well, isn’t that the truth. We find so often even outside of the container world it’s oftentimes configuration issues, not just the software itself. And as you mentioned, Kubernetes, well as great as it is, it is very complex to set up and operate. It’s not a simple task. Maybe it is as a developer to get an environment running but not in a multi-cluster distributed environment in the cloud, et cetera, high bred, all that kind of thing.

    Shah: They highlighted, you know, the three reasons why it is nontrivial. The first reason was that there are certain missing operational controls, right? So you obviously have to make sure that you understand what those are and put guardrails in place for those controls. The second is that there are a lot of components that have ability to put controls in place but the default settings are confusing, and the big takeaway for me is that we need to distinguish between security controls being available by default and that doesn’t mean that they are configured securely by default, right? So the misconfiguration is therefore the number one concern that users have and it was expressed by two-thirds of the audience in the StackRox State of Container Security Report that two-thirds of the respondents were concerned about misconfigurations.

    Ashley: I believe you even have that report or some information about that on your website. I remember downloading some of that. It has some great information in it. Talk to us about then how do you approach that from a StackRox product standpoint? What parts of those issues does StackRox come in and really help you solve?

    Shah: Yeah. So, you know, what we have taken is really a holistic approach to container and Kubernetes security and we have focused on making sure that our approach is both container-native and Kubernetes-native. So what does that mean? It means two distinct things. First is making sure that we capture all the rich configuration data that is in Kubernetes and use that to address and improve the efficiency of all the use cases that we address in the product. So let’s take vulnerability management as a very simple use case, right? You can go scan images and say here are a list of all the images with a vulnerability score of seven or higher.

    Now imagine you have hundreds of images with vulnerabilities and you give them to developers. What are they gonna do? And I say, well, they’re gonna throw their hands up in the air and say, “Well, I can’t get to all of them,” and that’s where we had the Equifax problem. But by deeply integrating with Kubernetes and being Kubernetes-native, what StackRox does is takes the additional step of saying, “Hey, you know, it’s great that we have these images with vulnerabilities, that’s a good, important first step, but let’s take the second and third and fourth step to understand are those images even deployed anywhere in your production environment?”

    Ashley: Exactly.

    Shah: Right? And if they’re employed in production environment, what data is it accessing, what secret is it accessing, what’s the network configuration, is it publicly accessible, what behavior are we seeing at runtime? And by taking all this rich context we can t hen give you a prioritized list of risks in your environment so you can focus on the most important risks first as opposed to getting a laundry list of issues. So that’s an important—you know, that’s how Kubernetes-native solutions can help you prioritize risk and that’s precisely what we do at StackRox.

    Ashley: I was just going to say, I think this is an extremely valuable aspect of your product because so many security teams—and I’ve talked to even, you know, major online tech companies that say, “I don’t need more information; I need problems solved, right? Tell me what are the biggest, most important things to go after,” and I think that’s a huge part of what StackRox does.

    Shah: Exactly. And, you know, alert fatigue, as I’m sure you’ve heard, is a very common problem in the security industry.

    Ashley: That’s the nice way to say it. [Laughs]

    Shah: Yeah. And by leverage the context, the rich context available in Kubernetes, you can actually make that information more actionable for your development teams and your security teams. So that’s one example. The other example of what it means to be Kubernetes-native is really to leverage the built-in controls available in Kubernetes for policy enforcement, right? And so let’s take network segmentation as another use case where you want to segment your networks between—inside—so that not every container can talk to every container, and there are two approaches. You know, Kubernetes has something called Network Policies and you can leverage those, and it’s much more scalable and robust and it seamlessly deploys within your infrastructure, right?

    The other approach would be to go deploy a proprietary firewall, which is fraught with scale challenges and creates issues if it fails, right? And so a customer again says, “Hey look, when I’m talking about being Kubernetes-native I want to leverage Kubernetes for what it’s designed to do, leverage the native capabilities, because it’s much more scalable and robust, and I want to make sure that my controls are all in Kubernetes, have a central place for policy enforcement as opposed to multiple proprietary tools doing policy enforcement,” which is not the approach and not what Kubernetes recommends and that’s precisely why they have those built-in controls. And so that’s again another example of what—you know, the advantages of being Kubernetes-native and it allows for native enforcement of your policies.

    Ashley: Well, I think that’s another place where, you know, the DevOps intersects with other parts of the organization, DevSecOps, et cetera. You know, a security team might be used to locking down a server or at a massive application level, and as you’ve mentioned sort of outside of the Kubernetes environment locking something down at the firewall, that doesn’t deal with really what’s happening amongst all the clusters, all the containers, microservices. So you’ve really highlighted an important aspect of security, that once security teams get engaged and find out what’s possible now they can, you know, do that through StackRox. That’s gotta be a huge advantage.

    Shah: Yeah, and precisely the reason why we took this approach, because when we go talk to customers what we find is that there are security teams that care about the controls that we are talking about here and then there are platform and infrastructure teams that are responsible for the operationalization of these tools, right? They are responsible for SLAs. The SREs are the ones that have to operate these container and Kubernetes-native security solutions and, you know, they just prefer solutions that are more native to the infrastructure versus deploying proprietary third party tools. And so having a Kub-native approach also helps align security and DevOps teams, and what we are seeing now is as a result that this emergence of DevSecOps, which is all about bringing the two together and really being responsible for the security of your application and your cloud-native infrastructure.

    Ashley: I’m curious. Who is it usually that’s reaching out to you or showing interest in StackRox? Is it the developers, DevOps folks, is it security folks kind of figuring out how to talk to the dev teams? What do you see happening in the market?

    Shah: Yeah, and a great question. We typically see security teams or security architects or application architects reach out because they know they have to address it, and so that’s where the initial conversation starts. What we find is that when they involve the DevOps teams, because they have to get involved to do a proof of concept or even to deploy an operationalized solution, the DevOps teams actually much prefer a container and Kubernetes-native approach as opposed to a proprietary third party security tool because they often refer to proprietary tools as a root kit that they do not want to install in their infrastructure, right? And so it is—you have to speak to both audiences.

    You have to make sure that you cover all the use cases that security teams care about and you also have to make sure that from a day-to-day operationalization of the product it aligns with your DevOps teams, their processes, their workflows.

    Ashley: I have to believe that’s gotta be a big plus to the security team. It’s not another security tool that they bolt on to the network. It’s something that’s built into Kubernetes and managed through Kubernetes and StackRox. It’s also native to the application infrastructure versus something they have to integrate in or yet another tool to watch. It just seems to be much simpler, although it’s a complex topic, but simpler thing to implement as well as manage.

    Shah: Absolutely. I mean you said it spot on. This is security that’s built in versus security that’s bolted on, and if you think about where the security industry is headed it’s all about security as code, right? Where you built it into your applications. People talk about infrastructure as code, which is what we’ve been doing for the past five years, and now we are moving to this security as code where it presents us with a unique opportunity to address security from the very beginning and forever change the security equation in our favor.

    Ashley: I’m curious. When we talk about shift left for security, I think bundled inside that, really what’s also shifting left, is auditing and compliance. Are there things about a Kub-native environment that help us with that as well, the auditing and compliance aspects of security?

    Shah: Yeah. Absolutely. When we think about compliance and, you know, shift left you want to make sure that your Center for Internet Security benchmarks cover both your containers as well as your orchestrator in Kubernetes. If you’re doing any kind of PCI or HIPAA or NIST 800-190 compliance controls you want to make sure that you extend them not just to your containers but also to your orchestrator in Kubernetes specifically. The whole shift left movement is that if I can catch an issue early on and prevent it from being deployed in my environment that is 100 times more effective than deploying it in my environment and then catching it when something goes wrong, right? So the sooner—it’s more preventative as opposed to, hey, we’re gonna detect it—let anything run in the environment; we’ll detect everything bad that happens.

    And, you know, and as we know that’s not effective. You have to have preventative solutions, you have to have guardrails in place that harden your environment so you have fewer chances of things going wrong. And that said, you also need capabilities at runtime, so despite your best efforts, when things do go wrong, you can still catch them and prevent any damage from happening.

    Ashley: Well, that’s the whole observability tracing into microservice, et cetera, understanding what’s happening in the environment. You have to know what the environment is in the first place as well as tie it back to that data.

    Shah: Exactly. And I think what we’re going to see is logs and metrics and tracing forming observability as you point out; and similarly, you know, security is just the other side of the coin, right? So observability and security go hand in hand. What we are doing is leveraging all of that rich information that is available at the node level, at the cluster level, and leveraging that to protect your applications across the entire lifecycle.

    Ashley: Excellent. Well, we’re coming up on the end of our time here. One last thought. Is there a certain best practice or something that you’ve observed as you work with customers when they begin engaging with StackRox and see your technology and what it can do for them? What is the thing that they walk away saying, “Wow, this has really helped me and I’ve solved the following problem or knowing the following has saved me a lot from avoiding some problems”?

    Shah: Yeah. So there are a lot of, you know, great resources available on our website at www.StackRox.com, and we talk a lot on misconfigurations and we’ve highlighted some best practices. For example, making sure that you use a read-only root file system, right? Because that’s a very powerful mitigation against attempts to gain foothold in your infrastructure and the adversary’s job becomes that much more difficult. Or minimize the image contents, because a lot of file systems often contain bash or package managers which further enable an attacker to do bad things, and so remove all nonessential binaries or pay attention to your Kubernetes RBAC configuration.

    Why? Because Kubernetes API is a critical attack surface. It controls what happens in your cluster and it controls what security configurations are in your cluster, and so if you minimize who has access to that Kubernetes API it prevents—it again hardens your environment, and also upgraded to the latest version because Kubernetes, the community, is constantly adding more and more security controls, they’re constantly addressing vulnerabilities that are discovered, and so running on the latest version of Kubernetes is also an important step that you can take to secure your Kubernetes environment. So there are lots of other, you know, best practices that I would call low-hanging fruit that we’ve called out on some blogs that we’ve written about, and that’s irrespective of whether or not you’re using StackRox, right? These are just some good best practices as you embark on your journey to containers and Kubernetes.

    Ashley: You do have an excellent blog and I would certainly recommend that to our listeners. Well, it’s been great talking with you. Kamal, thanks for being on the podcast.

    Shah: Mitch, thank you so much for having me.

    Ashley: It’s definitely been my pleasure. So I’d like to thank Kamal Shah, CEO of StackRox, for joining us today. You, of course, have listened to another DevOps Chat podcast and I’d like to, of course, thank our listeners for joining us today as well. This is Mitch Ashley with devopsy.kinsta.cloud. Thank you for joining us. Be careful out there.

    — Mitchell Ashley

  • WhiteSource Extends DevSecOps Reach

    WhiteSource Extends DevSecOps Reach

    WhiteSource has extended its platform that enables developers to more easily address application security issues to provide integrations with GitLab Core and integrated development environments (IDEs) based on the open source Eclipse project.

    David Habusha, vice president of product for WhiteSource, said these latest extensions extend the reach of the company’s platform for addressing DevSecOps beyond existing support for GitHub and BitBucket continuous integration/continuous deployment (CI/CD) platforms and the proprietary IntelliJ IDEA development platform. All of these integrations are being made available via WhiteSource for Developers, a commercial instance of the WhiteSource platform that includes a WhiteSource Remediate tool to address vulnerabilities and integrations with repositories, IDEs, CI/CD platforms and multiple browsers.

    As the responsibility for cybersecurity continues to shift left, Habusha said WhiteSource is making it possible for developers to identify, track and remediate cybersecurity issues from within, for example, an Eclipse-based IDE. That approach eliminates the need developers to exit the tool in which they spend most of their time to address cybersecurity issues.

    In general, Habusha said organizations that have adopted DevOps are now in the best position to leverage best continuous integration practices to make the transition to a new DevSecOps era. It’s still early days in terms of making that transition, but he said it is clear higher levels of collaboration between DevOps teams and cybersecurity professionals are now occurring.

    In fact, a recent survey published by WhiteSource finds 71% of respondents agree that operational responsibility for application security now lies with software development teams. That same survey finds over a third of respondents (36%) are starting to integrate security testing tools at earlier points in the software development life cycle (SDLC).

    Regardless of where organizations may be on the DevOps maturity curve, it’s never too early to address cybersecurity issues. The challenge is providing the means for DevOps teams and cybersecurity professionals to collaborate. There are not enough cybersecurity professionals available to participate in every stage of the application development process. Developers need to be able to act on issues identified by cybersecurity teams within the context of a larger, ongoing quality assurance process that revolves around their CI/CD platform. In effect, Habusha said, responsibility for cybersecurity needs to shift both left and right across the entire DevSecOps team.

    Nor is there any single right approach to DevSecOps; rather, Habusha said each organization will need to define the right set of processes for addressing application vulnerabilities earlier in the development cycle that best fits their culture.

    It may take some time to heal the rift that has existed between developers and cybersecurity teams for decades now. Even though everyone agrees developers need to take on more responsibility for cybersecurity, the individuals within organizations that have cybersecurity expertise don’t always trust developers, who are under constant deadline pressure to do the right thing. However, given the fact that cybersecurity professionals can’t address every vulnerability on their own, many of them are now coming to terms with the fact they need to find a way to work much closer with application developers regardless of their level of trust.

    — Mike Vizard

  • ESG Survey Sees Long DevSecOps Road Ahead

    ESG Survey Sees Long DevSecOps Road Ahead

    A study published by Enterprise Strategy Group (ESG) in collaboration with Data Theorem, a provider of tools for securing application programming interfaces (APIs) and mobile applications, finds that while a lot of progress has been made in terms of adopting DevSecOps, most organizations still have a very long road ahead before they can claim DevSecOps practices have been implemented consistently across the organization.

    Based on a survey of 371 IT and cybersecurity professionals at organizations in North America, the ESG study finds 55% of respondents have incorporated security into their DevOps processes, with another 22% planning to do so and 20% still in the evaluation stage. However, the study makes it clear that adoption of DevSecOps is still uneven at best. Only 33% are involving cybersecurity teams at the start of the application development process. And 39% of respondents report that members of their cybersecurity team are involved with more than half of cloud-native application projects today—a number that is projected to jump to 78% in the next two years.

    The survey also notes only 8% of respondents are securing 75% or more of their cloud-native applications with DevSecOps practices today. Within two years, however, 68% of respondents expect to be securing 75% or more of their cloud-native applications using DevSecOps practices.

    Doug Cahill, a senior analyst and group director at ESG, said the study makes it clear cybersecurity increasingly is being baked into applications rather than bolted on. The challenge now is finding a way to accomplish that goal at unprecedented levels of scale, he said.

    The platforms on which applications are being built and deployed are more diverse than ever. Organizations are running workloads on virtual machines (34%), bare-metal servers (28%), containers (23%) and serverless computing frameworks (15%), according to the survey results. Only 10% are running more than 50% of those workloads on a public cloud, but that amount is forecasted to jump to 30% in two years.

    Not surprisingly, the biggest cybersecurity challenges those organizations face is consistently managing cybersecurity across multiple platforms (43%), the cost and complexity of implementing cybersecurity controls across those platforms (35%) and lack of understanding of the threat vectors cloud-native applications face (35%).

    In terms of container security concerns, aligning controls with deployment models (32%) and verifying images in registries meet compliance requirements (32%) were cited as the top two issues. In terms of serverless computing, application programming interface (API) vulnerabilities (32%) were the most cited. As far as budget allocations are concerned, vulnerability scanning of registry-resident container images (26%) narrowly beat out API vulnerabilities tools (25%).

    Half of respondents also said they expect their organization will consolidate controls by leveraging suites and platforms procured from a smaller set of vendors or even a single vendor. Nearly three-quarters (73%) said they believe that their organization uses too many specialized products to secure cloud-native applications properly. Nevertheless, 59% said they prefer disparate point controls to achieve more functionality even if it means using multiple controls for different compute types/locations.

    The most important attributes of products used to secure cloud-native apps identified by survey respondents included a rich set of pre-deployment capabilities, runtime capabilities and support across a mix of server workload types, with flexible deployment options.

    The biggest issue, however, may be just the way these organizations are currently structured. The survey finds 82% of respondents have different teams assigned to secure cloud-native apps. Among those respondents, half plan to merge these responsibilities in the future, while 32% intend to keep them separate.

    Put it all together and it’s apparent there’s a long way to go before DevSecOps nirvana might be achieved. The good news is most organizations have a least started the journey.

    — Mike Vizard