devopsy.kinsta.cloud

Category: Blogs

  • Executive Coaching, Lesson 1

    Executive Coaching, Lesson 1

  • Private and Virtual Private LTE/5G Challenges Network Visibility

    Private and Virtual Private LTE/5G Challenges Network Visibility

    Digital transformation continues to disrupt the entire IT stack by shifting nearly every paradigm, including the new blurring lines between network infrastructure. New mobile network technologies are at the cusp of adaption in the enterprise networks with a growing number of innovations poised to enable expanded and more flexible connectivity with a gradual displacement of traditional Wi-Fi networks.

    The evolution began as new unlicensed radio frequencies become a part of the 3GPP 5G Release 16 mode of operation. This new mobile mode of operation has the ability to offer the necessary technology for mobile network operators (MNOs) to operate the unlicensed spectrum into 5G networks and make some of it available for corporate networking. New standardization will enable the enterprise networks to gradually adopt these new mobile networks to their connectivity framework, in order to leverage the benefits of new modern applications and alignment to their connectivity, scale and quality of service requirements.

    With the benefits of a new mode of connectivity – in a converged fixed or pure mobile infrastructure – there are always measurable risks that require attention. Specifically, the new mode of connectivity brings potentially new security threats and operational challenges that need to be addressed.

    New Operating Modes

    It is likely that incorporating this mobile technology will require starting from new operational modes; these will be imperative to grasp the direction and the adaption of private mobile networks in reality. Industry hype is certainly driving the trend towards the mode in which the corporate IT teams will be capable to deploy and operate the new private mobile network. However, at this point in time, the more realistic option will be that full control of design, deployment and operation will be from the MNOs, as they have strong experience, knowledge and risk mitigation capabilities. This mode of operation is also incentivized through the business aspects of creating a new revenue stream for the MNOs. This higher-margin business can provide more stringent security operations, particularly in light of better understanding the vector of attacks. Such an approach provides carrier-grade operations with the commitment of a service level agreement and correlation to the required corporate business agility and continuity needed by the enterprise.

    Questions like the who, what and where of network traffic need to be answered to prevent security threats and maintain network performance and reliability—in essence, identifying and maintaining the identity of the mobile subscriber in a complex hybrid model of mobile connectivity. A corporate mobile network can be completely private, well isolated from other networks with no roaming into the public network. It can also feature a less stringent traffic policy using a virtual slice of the private network with a segmented perimeter in which certain traffic will roam into a public network and will be tracked with respect to subscriber-aware policy. This latter option is a greater challenge because of the inherent separation of data or user and control planes in mobile network architecture is virtual rather than physical. Additionally, new mobile 5G architecture includes virtualization and network slicing to offer valuable versatility and scale, but it also makes NetOps and SecOps monitoring and control even more challenging. In light of the complexities, we can assume that the favorable and practical mode of new corporate mobile networks will be outsourced to an MNO that will operate in tight synergies with corporate IT teams. Their work will be based on a defined playbook to drive a gradual evolution of architectural reference models and pragmatic learning curve for corporate “do it yourself” operations mode. Complexities multiply in cases related to IoT and manufacturing applications in which the mobile core is required to be closer or co-located with the edge to support low latency and high throughput requirements.

    5G features a separation of data/user and control planes that is an architectural advantage, particularly helpful for large IoT deployments, dynamic scalability and services and higher data rates with greater bandwidth efficiencies. It offers more distributed processing for greater scale and less susceptibility to a single point of failure. It also represents a shift from best-effort networks to ones that can provide better, more differentiated levels of services and prioritization. This separation requires a new approach for network visibility to understand who is doing what. This is an issue for security as well as networking performance.

    The Challenge of Virtualized Network Functions

    Another challenge is that 5G virtualizes in software the higher-level network functions that traditionally have been performed by physical hardware. This virtualized network slicing means a sharing of physical resources that expand the attack surface by offering the potential for a sophisticated attacker to traverse from one virtual instance to another knowing that it will be difficult for security teams to detect this lateral movement. In addition, 5G radio network deployments may include significant expansions of small cells connecting in a campus geographically distributed environment, machine-to-machine communications and dynamic connections to multiple cells. All of these present a new frontier for attackers and new challenges for IT operation teams. Organizations need visibility and understanding of these new infrastructure resources to ensure a clear design and implementation to prevent security breaches and disruption of business continuity.

    The potential for significant expansion of IoT devices on corporate networks using 5G offers important advances for measuring and monitoring devices or making everything connected. At the same time, these lean devices generally have far less endpoint controls—particularly robust access control—than traditional computing devices, and it is difficult to add such controls directly to each unit. The rise of more IoT machine-to-machine communication and away from a hub-and-spoke model adds additional complexity. A proliferation of such devices also intensifies the need for deeper visibility and more automated security to scale with these deployments without the bottleneck of human intervention for each. This adds risks to the internal IT learning curve, making it an unlikely option and again, favors outsourcing to MNO experienced teams to design, deploy and maintain the corporate private mobile networks.

  • Why QA and Monitoring Need to Merge

    Why QA and Monitoring Need to Merge

    Customer expectations for speed and reliability have upended the software development life cycle. Whereas developers used to develop a product and send it to quality assurance engineers for testing before widespread release, customers now demand new versions and features on a quicker timeline. In an era with little available time to run QA in the traditional development process, what’s the alternative?

    Fortunately, modern automated infrastructure provides a solution. Infrastructure-as-code (IaC) toolchains that deliver continuous observability with AIOps let SRE teams overlook the entire process, from the first piece of code through the software product’s public release.

    This merger of the traditional roles of QA and monitoring is enabling quicker speeds within the delivery cycle, a development that improves the customer experience but also ignites business innovation.

    The Benefits of Speed in the SDLC

    Observability delivers the data necessary to eliminate traditional QA, but teams still need help. With intelligent observability — where you apply AI to the data — teams can better focus their efforts and analyze information much more quickly.

    Finding and fixing software issues after deployment unnecessarily stresses SRE teams. But through observability with AIOps, DevOps practitioners and SREs monitor from early development through daily performance. QA is omnipresent. Teams can identify root causes of issues instantly, and AI surfaces the most actionable steps to quickly resolve impacts on the infrastructure.

    The DevOps team used to leave QA engineers with the tedious and time-consuming task of pinpointing issues amid a sea of data, creating a bottleneck within the development process. The continuous learning and intelligent collaboration approach, on the other hand, merges traditional QA and monitoring and yields a CI/CD pipeline that actually works.

    Integrating observability with AI into the development cycle allows teams to spot change almost instantly. If the platform starts acting oddly after its release, SREs and DevOps practitioners can jump in immediately without the need to wait for a QA team. If the issue is where a change in performance is expected, AI and machine learning often still can reduce what’s needed from your teams. If, for instance, you’re monitoring with an adaptive thresholding algorithm, you can let the algorithm retrain and learn the new behavior instead of relying on the DevOps team to communicate the expected change in performance to the QA team.

    As QA shifts left – as evidenced by the growth of software development engineers in test (SDET) – it’s natural that monitoring and assurance capabilities should shift left, too.

    A Principled Approach to QA

    The merger of quality assurance and monitoring throughout the software development cycle follows the three guiding principles behind DevOps practices.

    • Flow/system thinking. The approach eliminates workflow silos and instead creates a holistic view of the development process. The continuous oversight negates typical quality hazards, such as the handoff that can occur despite a known issue or the optimization for local efficiency only.
    • Amplifying feedback loops. A merging of QA and monitoring eliminates the need to loop feedback through multiple teams with various processes because teams are given consistent feedback throughout software development and delivery.
    • A culture of continual experimentation and learning. DevOps teams, no longer in a position to just pass software down the line to QA, will build constant improvement into their processes as they learn from bugs along the way. This also provides more opportunity to take risks and experiment. The approach is a more holistic product cycle versus quick development.

    Improving the Q in QA

    Removing QA as a singular step in the software development process initially may seem like removing quality assurance itself. But QA is actually heightened by integrating observability with AIOps into the development cycle.

    Observability with AIOps allows teams to see into systems as they are being built but also allows them to gain actionable insights to resolve issues on the overall structure. Actionable insights empower the merging of traditional QA and monitoring to drive a whole new speed of delivery, which yields better customer experiences and gives businesses the ability to quickly launch competitive, innovative services.

  • Empowering BizDevOps Teams With SLOs

    Empowering BizDevOps Teams With SLOs

    When BizDevOps teams are drowning in logs and false alerts and are spending more time on manual processes than on building and deploying new applications and features, the work suffers, morale suffers and the organization as a whole suffers. Releasing better and more secure software, faster and with real business impacts starts with a robust BizDevOps practice. A crucial step IT leaders can take to align the developer, operations and business teams is to create a shared language of service-level objectives (SLOs).

    SLOs are metrics for validating that software is meeting its technical and business objectives. Defining and implementing SLOs help align developer, operations and business teams, not only ensuring everyone is moving toward the same goals, but also providing a way to reliably measure how BizDevOps teams are progressing toward these goals.

    Here are three of the most impactful ways SLOs can empower your BizDevOps teams.

    1. Establish a Common Language Across the Delivery Cycle

    The best SLO gives you precise and actionable insight into your system. Take performance and resiliency engineering, for example. By defining SLOs for performance and error rates, teams can use common measurements to track progress toward meeting their quality criteria to ensure they are staying within their error budget.

    In this way, teams can use SLOs as a common language across the delivery cycle – something everyone from developers to operations to business teams can rally around, ensuring everyone is working toward the same outcomes. This aligns teams into a coordinated BizDevOps practice, where all sides have better insight into how each piece of the business feeds into the others. If an incident occurs, operations can use an AI-based observability platform to observe its trends and impacts across different product or service releases and automatically feed that information back to the developers, who can modify their builds accordingly. When everyone is using the same SLOs to speak the same language, BizDevOps teams can coordinate and communicate more easily and effectively.

    2. Creating a Culture of DevOps Resiliency by Shifting SLOs Left

    BizDevOps isn’t just a technical practice defined by tools and platforms. It’s also a culture change and a shift in mindset. SLOs can play a major part in this change. Shifting SLOs left into the delivery pipeline means giving developers feedback about the outcome of their work and real-time visibility into their business KPIs using consistent SLO measurements – ideally, on every code commit. This consistency gives them answers at their fingertips to make data-backed decisions that consistently deliver better business outcomes. Using SLOs for developer feedback is a fundamental building block of DevOps, but it’s also key to creating a culture and mindset of resiliency within BizDevOps.

    A resilient BizDevOps culture is more than just making changes to your technology stack; it’s about changing the mindsets of individual engineers and developers. Resiliency means strength and reliability; the trust that when something goes down, it’ll go right back up. It’s about building the processes and systems that guarantee flexibility for anything from managing crisis events to delivering service continuity. Shifting SLOs left helps facilitate this culture change by giving developers greater exposure to the impact their work has when it’s in production and when it’s deployed. It makes everyone feel they’re in the same boat, and recognizes developers, operations and the business teams as one cohesive unit.

    3. Integrating SLOs Into Remediation

    BizDevOps teams can use SLOs to enhance remediation and incident response efforts. With everyone working with the same metrics, BizDevOps knows with certainty when something is broken, can identify root causes more quickly and can develop agreed-upon incident responses to accelerate time to resolution. BizDevOps teams can then feed this incident response knowledge back into quality gates earlier in the development cycle to avoid future problems. This develops SLOs that have been “battle tested” and can be easily automated to make quality gate testing better on the development side, and incident response better and faster for the operations side.

    SLOs bridge the gaps between BizDevOps

    SLOs already serve a useful role in production, but they also can influence the ability to create a robust, resilient BizDevOps practice. Shifting SLOs closer to developers and using them as a shared language across the delivery cycle provides space for greater experimentation, more innovation and a culture of resiliency. SLOs can also be defined along business-relevant metrics, such as conversion rates, user experience or feature adoption. As a result, SLOs empower BizDevOps teams to respond more quickly to issues and deliver better digital experiences and business outcomes.

    SLOs aren’t just performance metrics – they’re a powerful tool for bridging the divides between the developer, operations, and business teams. SLOs can help cultivate a BizDevOps culture that delivers innovative, secure software faster and with tangible business value.

  • Five Tips For Creating Design Systems

    Five Tips For Creating Design Systems

    Design systems were all the rage half a decade ago, with an explosion of open source resources made public by Google, Salesforce and Shopify, for example. Not long after, design tools like InVision, Sketch, Adobe XD and Figma featured ways for product teams to maintain design systems within their apps. If you want to build a scalable, consistent product that increases build velocity in design and engineering teams, a design system is integral.

    Throughout my own design career, I have become an advocate for building and maintaining design systems. It has become a niche passion of mine, and I hope to share some of what I’ve learned through the years as a design system nerd.

    But wait – first, what is a design system? A design system is a library of style, components and other patterns documented so that building and adopting products is more efficient and cohesive for designers, developers and end users alike.

    The key benefit of a design system is that it creates consistent, repeatable patterns that make end users think less. A product experience that delights is usually designed with persistent visuals and consistent interaction. Users want to feel comfortable knowing that no matter where they navigate, they won’t be surprised by what they find. Repetition, in the case of product design, is not boring, but welcome. Design systems create trust with users.

    Another benefit is the increased build velocity from design and engineering teams. As designers, we are tasked with solving problems. We want to create a simple understanding of how our users can accomplish tasks in a workflow. Of course, we are tempted at times to invent new patterns to solve design problems. We often forget, in the minutia of design iterations, that we’ve already solved a particular problem in a prior project or in another part of the current product. This inefficiency can lead to wasted time, especially if those existing patterns and components have not been documented. In a single-person design team, the negative effects may not be as visible, but one can imagine the exponential nature of a larger design team consistently duplicating existing work or creating new patterns that, ultimately, create an inconsistent user experience.

    Instead, we want to empower ourselves as designers to focus on solving problems without the need to invent new interfaces every time we are posed with a design challenge. Design systems are always vital, but are especially so when design teams scale up and the product experience reaches a level of maturity.

    Hopefully, you’re now convinced that design systems are the backbone of the best design teams and delightful user experiences. Below are a few tips to help you create a usable design system in your own organization.

    Start Small

    Create that button symbol. Save that primary color or header text style. Audit your designs and see what patterns emerge. You get the idea! It doesn’t matter where you are in the design process; any remnant of documenting a pattern will do wonders for saving your precious time and creating beautifully consistent experiences for end users.

    Prioritize Design System Documentation

    Whether it’s as simple as a shared page, internal minisite or a full-fledged website, documenting your design system and making it easily accessible to the right people is fundamental to its success. You need to determine the level of complexity that is needed for your organization and teams that you collaborate with. Talk to your engineering team to see how to best document and stay in sync between design and code.

    Keep Evolving Your Design System

    Ask yourself and your team if certain parts of the design system are actually helping solve problems. Iterate on a component that needs to be more flexible or add a new one if there is an important use case that needs to be addressed. Audit your component library to see if there are components that are not used, or if there are multiple components that can be merged.

    Have a System for the Design System

    It’s easy to get lost in the moment and forget to create an important, requested component or remind a developer to build a part of the UI as a component. Having a project management system and workflow for your design system can help prioritize needs and keep communication organized. Whether it’s logging tickets in Jira, moving cards over in Trello, or simply annotating or resolving comments in Figma, there needs to be a workflow that is consistent and works for the entire team.

    Collaborate

    I’ve fallen into the trap of being inside a design tool bubble. As designers, we’re often stuck inside software that is great for communicating a user experience but poor at staying in sync with the actual code that is being written. This causes an inconsistency between design and code. Design systems are no exception to that problem. From the outset, advocate for working with a developer to build a design system that works as a fruitful collaboration between design and engineering.

    These five tips will help you start creating a usable design system that will make your collaborators and, most importantly, your users, happy. Ready to get started?

  • Dear Vendor: Letter to Technology Vendors

    Dear Vendor: Letter to Technology Vendors

    While I was writing my “Dear Management …” post, something was going on behind the scenes that inspired me to write another. We all have things we wish to say to vendors; this open letter picks some of the big points that they seem to invariably struggle with.

    Dear Vendor,

    We want to use your products, otherwise we wouldn’t even be writing to you. But depending upon who you are, and what year it is, you are struggling to meet our needs.

    We understand that your insistence that your new product or acquisition will solve all of the problems we don’t have is probably executive-driven, but give us the benefit of the doubt. We know our environment, and just because we use you for one thing does not automatically imply we want you to constantly push this other thing at us. By all means, tell us about your entire product line, but then back off. We will let you know if anything appears to fulfill a need.

    While we’re chatting, can we discuss pricing? Not just cost, but the byzantine structures you create, time after time? If you are going to use 15 different charges and fees to jack up the price there, we’re paying the bill – we’ll see it. You’re far better served by being forthright. Do you have any idea how many stories like, “I am not funding your Ferrari with your commission,” stories (this was actually said; it was hilarious – we went with a competitor) are out there? And they keep occurring. Just this week, the phrase “Your pricing is bonkers!” was submitted to a company. We want a good product at a fair price, not a cheap price up front that will drain all of our budget over time.

    Speaking of good products, let’s talk about security. Security issues with your product are our issues more urgently than they are yours. Don’t mess around; when notified, quantify the threat and notify us immediately, with suggested remediations until you can get a patch ready. Holding off until you can patch puts us in the unenviable position of being vulnerable and, worse, not even knowing we’re vulnerable. Use good coding practices so we’re not all caught off guard, and waive those secure coding requirements for no one. Interns and C-level execs are not professional coders (interns aren’t yet, and C-levels no longer are), and any code by these two groups needs to be reviewed by someone that knows your systems before they are sent to us for deployment. Don’t force bad updates on us. Do your best not to give us bad updates at all.

    Finally, on the topic of forcing things on us – guess what? We have a need for a specific tool in a specific environment. Telling us that starting next month your services are all “moving to the cloud” does not suit all of our needs. We get it, you want that data. It’s all the rage right now. You should understand that, if you stop serving our needs in your quest for our data, we’ll go elsewhere, eventually, no matter how reluctantly. Cloud is a great platform, but most IT tools need the versatility to run where we need them, not just on one platform out of many.

    And, as a side note, your AIOps generally isn’t. We know it’s the buzzword du jour, but honestly, if it’s basically the same product with some logic or a dashboard strapped on, that’s not AIOps, it’s normal product improvement. When you have deep data collection and analysis that uses trained algorithms, then you can join the crowd screaming AIOps. Until then, hush. You sound silly, and it undermines the rest of your messaging.

    Just to reiterate: We have a need, show us how you fill it, and let us decide if that suits our requirements. Then tell us about your other offerings and back off. We’re smart enough to smell vaporware, stubborn enough to resist your desire to collect all of our data and wise enough to judge whether or not you and the product you’re pushing this week will be around in a year or two. You serve a purpose, and we’re grateful you are doing this stuff so we can focus on our business. But please, make life easier on us, not harder. And if one more of you sells a product we don’t need to the C-suite, we may explode. That Sword of Damocles that you raised over us will inevitably fall, and your company’s reputation will suffer for it. But we’ll pay the price for trying to implement something we didn’t need in the first place.

  • The Role of APIs In Digital Transformation

    The Role of APIs In Digital Transformation

    Digital transformation is increasingly propelled by rapidly changing user expectations. Release frequency is increasing, as is the need to connect a growing number of applications and digital experiences. As a result, 83% of IT specialists consider API integration critical to their business, found the State of API Integration Report.

    Application programming interfaces (APIs) hold powerful sway in tech discussions of late. Building API-first could increase internal reusability. APIs have become a standardized machine-readable mechanism for connecting partners. There is also a hot market for API startups, meaning APIs are becoming products in their own right.

    APIs are also enabling change for large enterprises. I recently connected with Bernd Gross, CTO at Software AG, to get his perspective on the role APIs and integrations are playing within the new wave of enterprise digital transformation. Below, we’ll see how connected customer experiences, digital business excellence and a new ecosystem-driven economy are driving the emergence of more API-based strategies.

    Three Drivers of the Connected Enterprise

    Businesses continue to transform into more connected enterprises. Once relegated solely to improving back-office efficiency, digitalization efforts are being applied across the board — to employee management, assets, machines, partners and the supply chain at large, said Gross.

    Amid rising digitalization, connectivity is the glue that unites disparate elements and tools. A fully connected world is “the new flavor of digitalization,” said Gross. To his point, ‘connected experiences’ is a crucial driver for 68% of platform providers, The State of API Integration Report found.

    So, how are APIs fueling the new connected enterprise? Gross identified three key reasons why integration is now fundamental to enterprise digitalization initiatives.

    Software AG Marketecture, used with permission.

    1. Connected Customer Experience

    Many organizations “want to transform into a technology and software company,” said Gross. To participate in the connected digital economy, organizations are striving to create advanced 360-degree customer experiences. Today’s technology needs to “look beyond a PC application,” Gross said. These experiences must cater not only to desktops and smartphones but also to IoT devices and physical assets.

    For example, he explains how one large elevator company architected an embedded connected experience, incorporating digital touchpoints within elevators to showcase signage, entertainment and ads, opening new monetization possibilities. This change was so radical that the mechanical engineering company pivoted its mission statement, reimagining itself as a “vertical transportation company.” Soon, their AI-enabled elevators will predict behaviors and optimize travel times, so they are always on the right floor, waiting for human riders.

    Intelligent building technology is similarly being applied by digital-savvy hotels, Gross explained, which is especially important for contactless visits during the pandemic. A fully digitalized customer experience could involve automated check-in, a room access code sent to a smartphone, an online billing system, physical sensors and more. Enabling a seamless digital hotel experience sounds easy, but it’s technically quite challenging — there are endless integration requirements to connect. In some cases, it would take 24 integration points, noted Gross.

    2. Digital Business Excellence

    Gross recognized the high expectations for modern digital experiences. He described a “new trend of business excellence in delivering more of an end-to-end digital experience.” This means data can no longer be locked up; even traditional companies must transition to platforms to offer software and data to their end users. In the process, interesting things may occur — your customers could become partners, Gross adds.

    He described how one medical company, a leading centrifuge producer, sought to build more digital experiences to complement their hardware. Though the machine functioned seamlessly, there was no easy way to port data results to other applications. This inhibited initiating the fully digitalized workflow required for a smart lab experience.

    In this case, APIs were imperative to opening up back end cloud services to enable smooth user interfaces and end-to-end workflow automation. “Intuitive user interfaces must integrate all services, including cloud and on-premises services, to create and automate workflows,” Gross explained. “To do this, you need integration.”

    3. Ecosystem-Driven Economy

    The network effect of platforms is that they enable an ecosystem to form. And, according to Gross, involving partners in this new digital experience matrix is imperative for success. For example, the API gateway is one area where partnerships help an integration strategy; “You need an API gateway for security and governance reasons,” he stated.

    Throughout his experience overseeing APIs on many projects, Gross often noticed a naïveté associated with defining the ecosystem. “When [clients] engage in the first phase of these projects, they think they know how to do it, but they typically don’t,” he said. Potential API providers often don’t fully realize their monetization strategy, the security implications or the complementary software providers necessary to support a working model. “Partnerships often facilitate a value-add to customers — they enrich the total offering through APIs and ecosystems,” said Gross.

    Similar to how a machinery company may embed a bill of materials into the product they sell, digital partnership ecosystems can open up data so partners can access and innovate with it, Gross said. Frequently, ecosystem partnerships make a lot of sense, as they can better meet consumer expectations. For example, Gross suggested that integrating a ticketing system into a conditional monitoring system would bring compelling value.

    The Next Stage: Self-Service Integration With APIs

    According to the report, 40% of companies said that digital transformation is driving their need for app integration. Truly connected enterprises must embrace digitalization and integration across all aspects of the business. As a result, this is forcing a business shift toward more open ecosystems.

    But building these systems will require newfound knowledge dissemination around developer experience and self-service capabilities. “Self-service has become fundamentally important,” said Gross. It’s not enough to simply open interfaces — you have to also add self-service capabilities to integration tools, he added. This could mean offering low-code options alongside APIs — such drag-and-drop UIs would help facilitate integrations for more citizen developers. A self-service approach to digital platformification is an emerging trend, yet one that’s “not fully at mass market,” described Gross; it’s still in its early stages.

    Open ecosystems are guided by consumers, who often desire connections between your tool and external partners. But, opening up data isn’t just helpful for partner integration; it could also benefit internal use. As Gross described, time-series industrial analytics could empower operators on the shop floor or production facility to make sense of local data. “You need self-service analytics tools to give them that ability,” Gross said.

    Building new customer experiences to cater to various devices and platforms is a big driver for API adoption. As a result, headless styles are emerging to address multi-platform requirements. For these reasons and many more, APIs are fueling new digital transformations across enterprises, powering innovative customer experiences and hiding complexity in the back end. With APIs, smart processes, smart machines and smart partners can all come together.

  • Company Values

    Company Values

  • Vulcan Cyber Research Reveals Most Enterprise Cybersecurity Teams Lack the Ability to Remediate Risk

    Benchmark study finds most cybersecurity organizations lack the tooling and resources to deliver enterprise cyber hygiene

    TEL AVIV, Israel — May 12, 2021 — Vulcan Cyber®, developers of the industry’s only risk and vulnerability remediation platform, today released the results of its latest vulnerability remediation maturity research project. A survey of more than 100 enterprise security executives across North America and EMEA found that most enterprise cybersecurity and vulnerability management organizations lack the ability to drive remediation initiatives, to reduce risk and achieve acceptable levels of cyber hygiene. Vulcan Cyber is using the benchmark data from this research to provide cybersecurity leaders with a free vulnerability remediation maturity self-assessment service.

    Conducted by Pulse, the Vulcan Cyber vulnerability remediation maturity survey examines the maturity of enterprise vulnerability remediation programs while seeking to identify where shortcomings exist within respondents’ cyber hygiene efforts. According to the findings, 56% of organizations lack the ability to remediate vulnerabilities with speed and at the scale necessary to protect business from exploits and hackers. Immature cybersecurity teams typically react to vulnerabilities on a case-by-case basis. Additionally, nearly 80% of respondents do not have the proper tooling to proactively orchestrate and automate vulnerability remediation.

    “Enterprises must work to get ahead of the relentless barrage of known security vulnerabilities that increasingly threaten business. Development, IT operations and security teams should be able to coordinate and measure their efforts to remediate vulnerabilities quickly and at scale,” said Yaniv Bar-Dayan, Vulcan Cyber CEO and co-founder. “To be effective, it takes the right people, processes and tools. If anyone is lacking, it is close to impossible to drive meaningful remediation outcomes. It is no small task to get fix done so we are doing all we can to make vulnerability scanning and vulnerability prioritization freely available to all cybersecurity teams.”

    Key findings from the Vulcan Cyber study include:

    • Only 21% of enterprises have the proper tooling to proactively manage and automate vulnerability remediation. While only one-third (34%) of respondents reported having a defined, effective process for detecting and responding to vulnerabilities, one-third (33%) lack an effective or comprehensive process entirely.
    • Forty-four percent of survey respondents only rely on the criticality of a vulnerability and the available bandwidth of IT and security teams to determine how quickly to remediate a vulnerability—and less than one-quarter (21%) are proactively remediating as quickly as possible.
    • Nearly one-third (31%) of respondents admitted their organizations do not prioritize vulnerabilities at all. The most mature organizations use a combination of inputs from CVSS scores, threat intelligence, and risk to business assets to prioritize vulnerabilities, but this was only 26% of enterprises.
    • Forty-six percent of survey respondents either don’t measure vulnerability risk at all, or rely on “gut feel.”

    “As organizations become more mature in their vulnerability remediation efforts, it is possible to become substantially more efficient, while increasing the scale of cyber hygiene coverage,” said Bar-Dayan. “It requires all stakeholders – security, IT operations, engineering, and business unit owners – to align objectives and orchestrate tooling to create optimized and automated remediation workflows. We are working to change the economics of risk operations and vastly improve enterprise cyber hygiene.”

    Vulcan Cyber has made it easy for organizations to assess their vulnerability remediation maturity levels using its new security self-assessment tool. For additional guidance on how to benchmark current practices and outcomes against using the Vulcan Vulnerability Remediation Maturity Model, read the Vulcan Cyber eBook titled, The Four Levels of Mature Vulnerability Remediation.

    For more information about Vulcan Cyber, please visit https://vulcan.io/ to request a demo, or try Remedy Cloud today. In addition, Vulcan Free is now available as the industry’s only free vulnerability prioritization tool. Apply for Vulcan Free access today.

    About Vulcan Cyber

    Vulcan Cyber has developed the industry’s first risk and vulnerability remediation platform, built to help businesses reduce cyber risk through measurable cloud and application security. The Vulcan platform orchestrates and tracks the remediation lifecycle from scan to fix by prioritizing vulnerabilities, curating and delivering the best remedies, and automating processes and fixes through the last mile of remediation. Vulcan Cyber helps IT security teams collaborate and “get fix done” at scale. Vulcan Cyber is proud to offer Remedy Cloud and Vulcan Free as freemium SaaS solutions for businesses of all sizes. The unique capability of the Vulcan Cyber platform has garnered Vulcan Cyber recognition as a 2019 Gartner Cool Vendor and as a 2020 RSA Conference Innovation Sandbox finalist. https://vulcan.io

  • Big Compass Practical Guide to API Security

    Big Compass Practical Guide to API Security

    DOWNLOAD the Free Report >>