staging-devopsy.kinsta.cloud

Tag: devsecops

  • DevOps Trends to Watch in 2021

    DevOps Trends to Watch in 2021

    Engineers at fast-paced startups often wear both Dev and DevOps hats. Early in my career, as a developer at a sentiment-analysis startup, I was tasked with writing scripts to spin up servers, configure them, install necessary software and deploy the code we wrote. My custom shell scripts, Python scripts and cron jobs did all the heavy lifting so that we could reliably deploy software and scale resources on AWS. Fast forward to today, and that problem of confidently building and securely deploying software has become an even more enormous challenge at scale.

    The Cloud-Native Application Stack

    A simple looking e-commerce app today can easily be a big set of coordinating microservices that are powered by containers, orchestrated using Kubernetes and hosted on multi-cloud/hybrid cloud. This combination enables faster delivery of code, cheaper hosting bills and more efficient use of server resources.

    While the application components certainly became smaller over time, organizations today are tasked with managing tens of thousands of containers in a production environment. In a 2020 Cloud Native Computing Foundation (CNCF) survey, 92% of respondents said they use containers in production, a 300% increase from just 23% in the first survey from March 2016. Such coordination complexity at scale is being managed by software delivery pipelines. Just as Ford revolutionized the automobile industry with its assembly line, these integrated DevOps products are massively impacting verticals like finance and insurance.

    DevOps Trends

    Trend: Developers are now Decision Makers and Influencers

    We are excited to see the increasing impact and influence of developers when it comes to the selection of tools. The top-down sales motion largely doesn’t work in the cloud-native world, and needs to be supplemented by bottom-up community adoption. The best developers pick peer-recommended tools to solve these tech challenges. Developers today leverage large communities, self-organize and pick the best open source tools to kickstart small projects that have potential to impact the growth curve of any organization. For vendors, developer evangelism becomes an important strategy for customer acquisition.

    Trend: Integrated Software Delivery Pipelines

    CIOs typically pick category-leading products for each category of the DevOps toolchain, like CI, CD, SAST and SCA. Historically speaking, integrating these tools to maintain an effective CI/CD pipeline has been painful and requires stitching together tools using custom scripts. We hear the frustration when we speak with maintainers of such scripts. To address this challenge, we think end-to-end integrated DevOps platforms will become the norm. Such platforms will offer a few best-in-class components with built-in automation, and will enable organizations to integrate other DevOps tools in a plug-and-play manner.

    Trend: Shifting Left with Code

    The shift left phenomena, which enables fixing of bugs/security issues early in the software development life cycle when it is cheapest to do so, is accelerating. By implementing a shared security responsibility model and enabling developers to take more ownership related to infrastructure, security and other critical production issues with code, organizations are shipping code faster and cheaper with less bugs.

    Trend: Low-Code DevOps Automation

    Many workflows are pretty standard in the DevOps world. Go look at an alert in production; prioritize it, look at the knowledge base for a fix, create incident, apply fix, resolve ticket and then repeat. This example is an oversimplification, but there are many repeat use cases that can be automatically managed. These workflows can and should be automated, which can make DevOps teams more effective. We think that customizable low-code automation interfaces will evolve to act as secret weapons for effective DevOps engineers.

    Trend: Security at the Speed of Dev

    Software release cycles a decade ago used to be four to six months long — if not longer — but today, the software delivery life cycle and release cadence is accelerating. The 2019 State of DevOps report suggests that the top performers deploy software 1,460 times per year, which is effectively four deployments per day. Security, compliance, vulnerability management, authentication and authorization all have to move at this speed, otherwise delivery of secure code is just not possible. We see the most innovative CISOs adopt a shared ownership model of security that enables application component owners to detect and fix vulnerabilities. In this shared model, a good balance between agility (so that development is not blocked) and security (so that risk can be managed) needs to be struck.

    Are You Building the Next Big Thing?

    Cloud infrastructure is an enormous opportunity that Gartner expects to grow to $412 billion by 2024 and many enterprises are just getting started. If you haven’t been paying attention, Satya Nadella now runs Microsoft and Andy Jassy will soon run Amazon. Both these leaders are pioneers in cloud, having led Azure at Microsoft and AWS at Amazon, respectively. This shows how much the largest companies, as measured by global market cap, believe in the opportunity related to the cloud. We couldn’t agree more.

  • Pulumi Moves to Automate Cloud Infrastructure Provisioning

    Pulumi Moves to Automate Cloud Infrastructure Provisioning

    Pulumi announced today it is expanding the scope of its automation ambitions to make it easier to securely provision cloud infrastructure-as-code.

    Joe Duffy, Pulumi CEO, said the Cloud Engineering Platform enables DevOps teams to use Pulumi Packages to create reusable components for automating IT infrastructure provisioning in a way that can be embedded within workflows and applications using an application programming interface (API) that Pulumi has exposed. IT teams can define a Pulumi Package in the programing language of their choice, Duffy noted.

    The Cloud Engineering Platform is now generally available on the Microsoft Azure cloud, while a preview edition of the offering is available on Google Cloud Platform. Support for Amazon Web Services (AWS) is planned for later this year.

    The platform itself is based on version 3.0 of Pulumi, an open source tool that developers have previously employed to manage infrastructure-as-code. Pulumi is also making generally available a tool for integrating its tools with more than a dozen continuous integration/continuously delivery (CI/ CD) platforms.

    That capability, coupled with existing support for integrated testing capabilities and the tools for managing compliance-as-code based on identities, provides IT teams with a more comprehensive approach to managing infrastructure-as-code, said Duffy.

    Most cloud resources today are directly provisioned by developers using open source tools such as Terraform. The issue that organizations have encountered is that developers are prone to making configuration mistakes that cybercriminals then exploit. Pulumi is making a case for an alternative approach to provisioning infrastructure-as-code that makes it easier to validate configurations using testing tools, while at the same time limiting who can access infrastructure resources by including support for the secure access markup language (SAML) and single sign-on (SSO) capabilities.

    It’s not clear at what rate enterprise IT organizations will be shifting toward platforms that enable infrastructure to be managed as code in a more robust fashion. Developers that don’t always have the greatest appreciation for cloud security issues routinely employ tools such as Terraform to provision infrastructure-as-code with little to no supervision. Cloud resource misconfigurations often result in ports left wide open, and cybercriminals now make use of tools to scan for those types of misconfigurations.

    Pulumi Packages provides a means for IT teams to exercise more control over the provisioning process, using vetted reusable components in a way that doesn’t compromise the rate at which developers can spin up cloud resources, noted Duffy.

    As organizations focus more on software supply chains in the wake of some recent high-profile breaches, it’s only a matter of time before more questions arise about how cloud infrastructure is being provisioned. Much of the concerns organizations already have about cloud security doesn’t stem from the platforms themselves. Rather, it’s the processes employed to provision infrastructure under a shared cloud security responsibility model that results in so many vulnerabilities. Many developers assume the cloud service provider is securing configurations, only to discover later that it was their responsibility to validate those configurations. Security teams, meanwhile, can’t keep pace with the rate at which cloud infrastructure resources are being provisioned.

    Hopefully, there will come a day when DevSecOps best practices leverage automation to resolve this issue once and for all. The challenge is finding the best way to achieve that goal in a way the average developer will accept and embrace.

  • DevSecOps Practices Gap Assessment

    DevSecOps Practices Gap Assessment

    DevSecOps practices are essential to deliver software safely and securely withinDevOps value streams.

    To get the maximum security protection from DevSecOps, it is important to use recommended best practices, inclusive of people, processes and technologies. A gap assessment is a great way to efficiently evaluate an organization’s practices for DevSecOps and determine a strategy for improvement. Gap analysis provides valuable inputs for formulating a strategy and roadmap to improve a topic including DevSecOps.

    My SlideShare Gap Survey, Assessment and Analysis For DevSecOps explains how my 9 Pillars Gap Assessment Tool greatly speeds up the gap survey, gap assessment and gap analysis process for DevSecOps.

    It is important to clarify a few definitions for these purposes, because I have found that different people and organizations use these terms differently. In this blog, and in my consulting work, I use the following definitions:

    • Gap survey is discovery tool used to collect information about the current state of practices for a topic.
    • Gap assessment is a process to determine differences (gaps) between current practices and recommended practices for a topic. Gap assessment is also used to refer to the entire collection of activities in this list.
    • Gap assessment workshop is a meeting in which the gap assessment is validated prior to gap analysis.
    • Gap analysis is the process of determining priorities for reducing the gaps found during a gap assessment.
    • Gap assessment tool is software that helps perform gap surveys, gap assessments and gap analysis.

    For those that want to dig deeper on this topic, additional definitions and contextual information related to the way I do gap assessments are clarified in my book Engineering DevOps.

    I define a seven step process for gap assessments. The steps are as follows:

    1. Pick a topic to analyze. The same processes and tools can be applied equally well to almost any topic.
    2. Determine recommended practices for the topic. Something that is worth doing a gap assessment for, such as DevSecOps, will normally be fairly complex with tens, if not hundreds, of practices. Categorize the practices into groupings (I call the groups “pillars”) to make the list of practices more understandable and meaningful. Doing this will require some research and work. For example, I have a database of practices and pillars for DevOps, continuous testing, DevSecOps and SRE and some other topics such as containers.
    3. Enter the chosen practices into a gap assessment tool. The tool can be a simple survey tool you create, a commercial survey tool or something custom-made.
    4. Determine who needs to be included in the gap survey.
    5. Collect data using the gap survey.
    6. Perform a gap assessment.
    7. Perform a gap analysis.

    Let’s take a look at the above seven steps for DevSecOps.

    Step 1: Pick a Topic to Analyze

    For our purposes here, the topic is DevSecOps.

    Step 2: Determine Recommended Practices for DevSecOps

    For an example DevSecOps assessment, I used the practices under nine practices categories described in a blog that I co-authored called 9 Pillars of Continuous Security Best Practices. The nine practice category pillars are:

    • Leadership
    • Collaborative culture
    • Design for DevOps
    • Continuous integration
    • Continuous testing
    • Continuous monitoring
    • Elastic infrastructure
    • Continuous delivery
    • Continuous security

    Step 3: Enter the Selected Practices into a Gap Assessment Tool

    You can find and download a free gap assessment tool, pre-loaded with a sample of DevSecOps practices in a file called DevSecOps Assessment, from one of the resource pages found on my website, EngineeringDevOps. You can edit the practices categories and add/delete practices from each category if you prefer to make changes.

    Step 4: Determine Who to Include in the Gap Survey

    For the gap analysis to be comprehensive, people in roles that are affected by container practices need to be surveyed, or at least represented, to ensure their perspectives are included. Some example roles that are typically included:

    • Business leaders – because leaders influence culture and budgets for DevSecOps.
    • Developers – because developers need to design in accordance with DevSecOps practices.
    • Project owners – because they influence product work priorities.
    • QA testers – because they need to test in accordance with DevSecOps practices.
    • Ops – because DevSecOps practices affect operations.
    • Security – because DevSecOps practices affect security practices.

    The survey can be conducted for an individual application, a group of applications or all the applications in the enterprise. However, it is important that the gap assessment and gap analysis be performed on the organizational segment that is being targeted for improvement.

    Step 5: Collect Data Using the Gap Survey

    A gap survey should allow each surveyed person to enter an “Importance Level” score, a “Practice Level” score and comments for each practice. All this information is essential for the gap assessment and gap analysis. In the gap survey included in in my gap assessment tool, survey respondents are asked to score the importance of each practice as one of 0=not relevant, 1=not important, 2=nice to have, 3=important, 4=very important or 5=critical. Practice-level choices are 0=not sure, 1=rarely, if ever, 2= sometimes, 3=most of the time, 4=always or 5=we are good at this. Comments that are relevant to qualify or explain the scores entered for each practice should also be entered, especially if there is any doubt or ambiguity.

    Step 6: Perform a Gap Assessment

    The gap assessment process requires all the practices scores collected from the surveys to be collected and assembled to calculate an aggregate set of scores. Gap scores are calculated using a formula that weights each practice level score with the corresponding importance level score. A visual representation helps to identify practices areas and individual practices that have the highest, most important gaps.

    No matter how professionally written the practices and score definitions are, it is not unusual for some people to misunderstand and to enter scores that they would not have otherwise. For this reason, it is important to ensure that the data collected is validated before conducting the gap analysis. The preferred approach is to conduct a gap assessment workshop with key representatives from each role that participated in the survey. During the workshop, the scores for each practice that have a high deviation between survey responses are discussed and, if necessary, adjusted.

    Step 7: Perform a Gap Analysis

    The gap analysis process involves extracting the high gap practices and tagging and ranking each of them against solution categories that are determined by a consultant or topic expert.

    The result of the gap analysis indicates where solution strategies and implementation roadmaps need to be focused to reduce the most important gaps.

    What This Means

    While is it clear that DevOps offers immense value for software deployment, the adherence to best practices for DevSecOps is essential to reduce risk and assure security. Each organization is different, and has different security postures. The specific practices, security tools and metrics that are appropriate may vary according to a risk assessment for each organization. This blog explained a gap assessment approach, which uses my nine pillars of best practices for DevSecOps. My free DevSecOps assessment tool facilitates a gap analysis for DevSecOps and priorities to improve DevSecOps practices for an organization.

  • Solving Cloud-Native Challenges in the Rush to the Cloud

    Solving Cloud-Native Challenges in the Rush to the Cloud

    The shift to cloud-native environments away from traditional data center infrastructures continues unabated, but security and complexity challenges remain a struggle for DevOps teams.

    These were two of the main takeaways in a survey and analyst report published by the IT consultancy firm Flexera. 

    The survey, based on the responses of 750 IT professionals, revealed that 92% of the organizations represented in the survey have a multi-cloud strategy, 80% have a hybrid cloud strategy and only a minority (45%) have integrated data between cloud environments.

    The top challenges, according to the survey results, are:

    • security (81%)
    • managing cloud spending (79%)
    • governance, lack of resources/expertise and compliance (75%)
    • comprehending cost implications of software licenses (55%).

    The solution for these challenges largely involves — in addition to implementing the right DevOps culture and practices — adoption of the right tools and platforms, especially for security. However, first-generation cloud-cost management tools “simply are not cutting it” for modern architectures, said Asim Razzaq, CEO of Yotascale, which offers a cloud resource optimization platform.

    “Today’s modern architectures are dynamic, and ownership is transient and not always well-defined. The greatest strength of containers and Kubernetes is the ability to scale on-demand and share cloud resources among multiple applications,” said Razzaq. “Tracking cloud costs in modern architecture requires a strong ability to automate cost attribution — or tag management — for those dynamic resources, and the ability to understand usage at the application level, even for containers that are sharing resource instances.”

    First-generation cloud management tools are, in this way, unable to provide the information DevOps teams require to understand how to automate cost attribution for modern architectures, said Razzaq.

    “[DevOps teams] can’t break down costs into any level of meaningful detail for engineering and finance teams to digest and act upon,” said Razzaq. “Conversely, newer approaches that are focused on Kubernetes cost management lack the ability to understand and break down the costs of non-cloud-native workloads.”

    Indeed, tools are often frustrating to engineering teams because of their static custom reporting, broad and generalized recommendations and no effective workflow for effective collaboration between finance and engineering, Razzaq said.

    “The biggest source of frustration is the inability to drill down and manage costs in a way that matches the way that these teams do business. There may be 10 teams, each with five production applications running in the cloud, for a particular account,” Razzaq said. “Engineers need to see, at the application level, what their resource utilization, costs and cost anomalies are in order to make the best cost/performance decisions for their applications. Without that, they’re flying blind; having to defend their cloud usage without any supporting data.”

    As an example, a misconfigured Kubernetes cluster can “cause a massive spike in costs,” Razzaq explained. “Without detailed cost and utilization reporting at the team and application level, an engineer can spend weeks digging through spreadsheets and logs trying to track down the source of the anomaly. That’s weeks of their time that they aren’t [using to] be productive on new features.”

    cloud-native

    Razzaq said there are a number of solutions DevOps teams can adopt to address these issues, including automated cost attribution and tag management, actionable recommendations and comprehensive observability capabilities.

    Automated cost attribution and tag management “is the foundation of accurate and detailed cloud cost management,” said Razzaq. “Engineers need tools to help them set tag management policies, identify untagged instances and update tags quickly and easily in their cloud environment,” he said. “With this in place, cloud-native workloads can be automatically tagged as they are dynamically created, ensuring that cloud costs are always clearly attributed to the right teams and applications.”

    Actionable recommendations at the cloud-instance level with closed-loop feedback also are an important process “so that engineers can see exactly why the recommendation is being made, and what the cost impact will be of taking that action,” Razzaq said. “The ability to provide feedback on the recommendation and dismiss recommendations that don’t align with business needs ensures that new recommendations are relevant,” Razzaq added.

    Finally, tools that provide a unified view of both cloud-native and traditional workloads that have been shifted to the cloud help to ensure “that engineering and finance have a single source of truth for their cloud costs that enables them to make smarter decisions for their business,” Razzaq said. 

     

  • Seeing the Bigger Picture With BizDevSecOps

    Seeing the Bigger Picture With BizDevSecOps

    Not long ago, if you can believe it, software was shipped on physical floppy disks and CDs. These physical relics contained dense paper instruction books that humans read diligently for hours on end (I guess they had more time to spare back then?). Complexity was a given for computer-based tasks.

    Fast forward past the consumerization of IT to 2021, and you’ll find extremely high standards for technology. End users now expect intuitive apps with instant end value and 100% uptime. If they don’t receive gratification within minutes, they’re likely to trash it.

    In the race to meet digital innovation demands, software companies are increasingly tapping new strategies to deliver iteratively. Thus, disciplines like DevOps, DevSecOps, low-code and SRE have flourished. But are we adequately considering the end value of that work? Some feel business leadership needs a larger seat at the table and more input: enter the newest iteration of these disciplines, BizDevSecOps.

    I recently met with Gregg Ostrowski, CTO at AppDynamics, to discuss how to introduce BizDevSecOps in an organization. For Ostrowski, it boils down to having full-stack observability to connect application performance, security threats and revenue generation. Only by democratizing access to important metrics and identifying runtime weaknesses can business outcomes truly drive production.

    Full-Stack Observability

    Within our new pandemic-first reality, all organizations are amplifying their use of digital services to interact with customers. However, software teams are struggling to keep pace in this new environment — 89% of technologists report feeling under tremendous pressure at work, the Agents of Transformation 2021 report found. This strain has only increased as IT complexity soars amid the pandemic — 83% felt their job became more complex over the past year.

    IT staff is under mounting pressure to perform, and they may not have the correct elements in place to support elegant and profitable applications, said Ostrowski. When it comes to monitoring, in particular, alert fatigue could especially hamper innovation attempts and make it difficult to know what to prioritize.

    Instead, Ostrowski advocates for letting tangible business outcomes, such as conversion rates and performance, drive development. To correlate the impact on revenue more directly, he encourages “giving business leaders a seat at table during the entire CI/CD pipeline.” One aspect to roping in business, security, development and operations is unified observability across the entire stack.

    The Pendulum Swings

    But wouldn’t it be challenging to give business leaders a seat within a technical software delivery process? Well, this wouldn’t be the first time business has directed technological change.

    Ostrowski recalls the mid–2000s and the dawn of the mobile market. During this period, IT became consumerized for laypeople, with glossy apps and impressively intuitive experiences. He recalls a general loss of faith in IT staff, as workers often had “better tech at home than they did in the office.” This drove business leaders to invest heavily in modernizing their companies.

    In the following years, cloud solutions quickly re-empowered IT with new computing models, emboldening them to compete using the same tools as tech companies. However, simple deployments using a single server quickly morphed into arranging multiple workloads on various cloud service providers (CSPs). Virtualization, serverless and microservices architectures also brought novel complexities into the stack.

    “The IT staff is being asked to do jobs they’ve never done before,” Ostrowski said. He explained that SREs, for example, must understand networking, infrastructure and security — a vast portfolio for a single person and role. Supporting many disparate paradigms is simply beyond the scope and scale of what a single person can do, meaning new automation must be constructed — because “if you’re too busy debugging, you can’t innovate,” says Ostrowski.

    Amid mounting complexity and the burden of rising cloud costs, it appears business leaders again have a role in directing and prioritizing technological efforts.

    Getting Busy With BizDevSecOps

    According to Ostrowski, connecting IT and business with BizDevSecOps all hinges on collaboration. “If you don’t get to a point where you can collaborate with all these pillars, you’ll degrade your business,” said Ostrowski.

    BizDevSecOps also could help connect the dots to comprehend anomalies. For example, suppose a commerce application is experiencing a 15% conversion rate, but it drops to 7% after an upgrade. In this scenario, collaboration is crucial to identify usability bottlenecks in production and adjust accordingly.

    Tracking business outcomes can align development around improving the user experience. If broken features are hurting conversion rates, all stakeholders need to know to adjust accordingly. “User experience is the golden gem,” said Ostrowski.

    Other benefits of a BizDevSecOps approach may include:

    • Correlating activity and revenue: Ensuring spikes of activity are associated with revenue generation and not attacks or faulty instances.
    • Workload optimization: Monitoring business outcomes can help adjust the scope and size of machines as needed.
    • Before and after: Comparing financial results before and after migrations, new versions or new feature additions.
    • Postmortems: Pinpoint and correlate data when conducting postmortems.
    • Progressive delivery: A more rapid release frequency helps a business retain agility and pivot when needed.

    Visibility Enables BizDevSecOps

    DevSecOps is now a common philosophy — it promotes development with security baked into the application. Now, BizDevSecOps could be the next iteration; a collaborative approach that considers additional perspectives. BizDevSecOps is a vital method to “continue to build trust and collaboration so everyone has a seat at the table,” said Ostrowski.

    Ninety-six percent of technologists agreed that monitoring the entire IT stack to connect technical performance to business outcomes will be important in 2021, the Agents of Transformation Report found. To enable this, business, security and development must inevitably de-silo. According to Ostrowski, adopting BizDevSecOps depends on a window into performance management and business intelligence, because “when changes happen and no one knows about it, it’s a serious problem,” he added.

  • 1Password Extends Encryption to Automate Secrets Management

    1Password Extends Encryption to Automate Secrets Management

    1Password this week added a Secrets Automation platform to its offerings that enables IT organizations to more easily encrypt, manage and orchestrate credentials, application programming interface (API) tokens, keys and certificates.

    In addition, the company revealed it has acquired SecretHub, a provider of a separate secrets management tool. Terms of the acquisition were not disclosed.

    Carson Brown, senior product manager for 1Password, said the SecretHub team will now focus on the development of the 1Password Secrets Automation platform based on encryption technology previously created by 1Password.

    Finally, 1Password this week also announced an alliance with GitHub under which it will, at some future date, enable DevOps teams to employ SecretsHub to encrypt secrets used to access the source code repository. 1Password already provides integrations with HashiCorp Vault, Terraform, Kubernetes and Ansible, in addition to client libraries written in Go, Node and Python.

    The 1Password platform for managing and securing passwords is already in use by more than 80,000 businesses worldwide. The Secrets Automation platform now extends the reach of the company’s core encryption technology into the realm of DevSecOps best practices, said Brown.

    It’s still early in the cycle of DevSecOps best practices adoption, but it’s clear an initial focus will be secrets management. In the wake of recent high-profile breaches involving software supply chains, there’s now increased scrutiny of secrets management. Cybercriminals have become more adept at scanning for secrets left exposed as plain text. The challenge organizations face is that developers, while building applications, tend to copy secrets for the sake of convenience, which they often forget to delete after an application is deployed in a production environment.

    In response, many IT teams vacillate between overly restrictive and overly permissive access controls that are rarely implemented consistently.

    Of course, it’s now also only a matter of time before auditors start citing all those unencrypted secrets as compliance violations, Brown noted. A set of DevSecOps best practices based on automatic encryption of secrets eliminates those compliance concerns in a way that is transparent to application developers, noted Brown.

    It’s not immediately clear whether it will be DevOps teams that lead the charge to automate the encryption of secrets, or whether cybersecurity teams will take the lead. Regardless of which team assumes responsibility, the number of secrets that need to be tracked keeps expanding as the number of platforms employed increases. Manually keeping track of all those secrets is no longer feasible. Centralizing secrets management is the first step toward regaining control over an IT environment, said Brown.

    Secrets management may not always be the first thing that comes to mind when organizations begin their DevSecOps journey. As it turns out, however, securing secrets may very well turn out to be the first order of business as senior business and IT leaders review their entire software supply chain. After all, once it becomes apparent just how dependent organizations are on software, they quickly realize how much of their intellectual property is one compromised credential away from being stolen.

  • 4 Ways SASE Fuels DevOps Productivity

    4 Ways SASE Fuels DevOps Productivity

    Many enterprises are adopting secure access service edge (SASE) solutions as part of their digital transformation efforts. SASE, in a nutshell, merges together SD-WAN and security stacks to deliver secure networking and improved WAN performance, making it a logical choice for cloud-enabled businesses going through the throes of digital transformation. However, SASE offers other benefits, which may be of particular interest to DevOps teams.

    Let’s take a look at four ways SASE can enhance the productivity of DevOps teams.

    Reducing Collaboration Challenges

    SASE reduces the challenges associated with team collaboration. SASE, by design, integrates WAN optimization with cybersecurity. Today’s DevOps teams need to work together, despite being physically separated, and must have reliable, secure connectivity amongst the team. “DevOps are all about time-to-market, and DevOps teams are looking for ways to shorten their  CI/CD cycles. A critical part of that process is reducing their dependency on the networking and the security teams,” said Boaz Avigad, director of product marketing, CATO Networks. “Since SASE solutions already provide optimized performance and robust security, DevOps [teams] are free from waiting for infrastructure teams to provision the necessary resources. SASE provides DevOps the control and operational cadence they need without compromising performance or security.”

    SASE Improves Networking

    SASE improves overall network performance with integrated load balancing and failover capabilities. DevOps teams cannot afford to lose connectivity, especially when rolling out new iterations of software or resolving bugs. “For DevOps teams, fast and reliable application performance is critical,” said Avigad. “SASE architectures free DevOps [teams] from worrying about the infrastructure by connecting all the company’s edges, data centers, mobile users and cloud resources, with the same self-healing, secure and fully optimized global network. Should a line fail or a route become congested, SASE automatically switches to an alternate path.”

    Better Security Built In

    SASE helps to secure DevOps projects with native cybersecurity capabilities. When properly implemented, SASE integrates numerous security technologies directly into the network stack. “DevOps teams worry about information interception and protecting their applications from threats. All security services share a single, unified context, improving insight and closing the gaps in legacy security architectures; gaps attackers often exploit,” said Avigad. “SASE not only includes NGFW, IPS, SWG, AV and MDR services, it also converges them together into a single-pass architecture.”

    SASE Removes DevSecOps Burdens

    SASE secures internal applications, along with the interactions with those applications, which in turn helps to reduce the burdens on DevSecOps team members. Applications that run over SASE/SD-WANs are further secured by zero-trust network access (ZTNA) and software-defined perimeter (SDP), technologies that help to keep all interactions between an endpoint and an application secure. “Many proprietary applications are too sensitive to run over the public internet. SASE protects those applications by obfuscating traffic, protecting all entry points with a NGFW and restricting access with its zero-trust architecture,” said Avigad. “All internal application traffic is also continuously inspected for threats.”

    Adopting SASE for DevOps teams is beginning to make a lot of sense. The technology addresses many of the pain points that DevOps teams experience as businesses drive toward digital transformation. What’s more, the security benefits offered bring forth additional productivity, while also unifying the security stack. 

  • Low-Code and DevOps: Friends or Foes?

    Low-Code and DevOps: Friends or Foes?

    What does low-code mean, and who is it really for?

    Over the last few years, I’ve seen many articles associating “low-code” with “citizen developers” or with people who don’t have deep development skills. Users can arrange visual elements, or fill in forms with key information and publish the result as an application.

    But tools for citizen developers are only one part of the low-code story. There is also a growing number of tools for professional developers, and I want to talk about those, too.

    Both citizen developers and professional developers have a role to play in application development and automation projects, and low-code has something to offer both of them.

    Low-code is Not a Market, it’s an Approach

    Low-code does mean providing visual and graphical tools and simple frameworks that mask more complex coded operations, so the application designer does not have to directly touch the code that performs desired operations. These apps are naturally limited, as the resulting application can’t be highly customized if you can’t touch the code.

    With these kinds of visual tools, anyone can create a simple application within the limits of the tool. But when we pull back and look at what is needed to create larger, more complex applications – ones that need to communicate with other enterprise systems, or need extensive customization, or cross organizational boundaries, or need to pay attention to governance requirements, for example – the visual-only approach is frequently insufficient. In complex cases, developer expertise is often needed, and developers have to get “under the hood” to tinker with code.

    There is no “low-code market.” We are bringing tools to people who need them to develop specific projects. A comprehensive low-code approach to application development and automation means offering both visual programming and coding capability. For usability reasons, these tools are clearly separated and presented to the development team in a way that allows citizen developers to work on certain elements and developers to work on others, all on the same platform.

    We know that it’s possible to serve professional developers with low-code, too. A low-code approach also includes drag-and-drop tools that developers can use – for example, to develop APIs, or to integrate the application with other systems, or to customize front-end interfaces. Of course, when code is required, developers should be able to use their own tools and frameworks and not be limited by low-code tools. Platforms that offer a hybrid approach are likely to be most useful to mixed-skills development teams.

    The Hybrid Approach

    Strictly low-code tools can serve simple automation use cases. More broadly, automation platforms offer a hybrid of low-code and coding capabilities for more complex automation use cases.

    For critical enterprise applications, both business and developer inputs are usually needed. Having tools for both of them means not leaving anyone out.

    Low-code tools will continue to become more mainstream. Low-code is not a fad or a passing trend, but a quiet revolution that will see greater incorporation into more business tools.

    Here Come the Digital Natives!

    More vendors are offering low-code tools for digital process automation, business intelligence, robotic process automation, identity management and data integration, to name just a few.

    As automation platforms and other low-code tools mature, a greater number of people are getting used to working with them. Developers are less hesitant about incorporating non-developers into their teams, as everyone gains a better understanding of the benefits of these platforms.

    The younger generations entering the workplace today are digital natives. They are fearless about diving into technology and working hands-on. So, these low-code tools are ready for them, and they are ready to put them to work.

    Low-code is breaking down technical barriers to work in the automation space, making smooth collaboration between business and development easier.

    Low-Code Can Be a Double-Edged Sword

    Automation and development teams are also becoming more aware of vulnerabilities and compliance issues as citizen developers roll up their sleeves and join the technical team.

    Low-code tools are a double-edged sword. They facilitate teamwork, but issues with security and data governance may not be top-of-mind for non-developers. If you have a big team working on automation and/or application development and delivery, the need to build in governance becomes even more important.

    Using a shared platform will help manage and mitigate these issues with security and governance. This will become even easier as the platform tools evolve and mature, so DevOps teams can use them to help mitigate some of these issues.

    Does Low-Code Have a Place in DevOps?

    We are definitely seeing the impact of low-code on development environments and DevOps. Remember, low-code started with small applications, and while DevOps-style teamwork and workflows may not be needed there, as the use of low-code platforms becomes the norm for critical enterprise projects, DevOps will be a necessary part of the mix. This is where low-code is having a more obvious impact; Agile methodologies using low code platforms for iteration, for continuous improvement and for continuous delivery. These applications aren’t one-and-done. They need to be maintained, improved and delivered, again and again.

    Low code isn’t going away. On the contrary – it’s going everywhere.

  • DevSecOps: Rethinking and Reengineering Cloud Security

    DevSecOps: Rethinking and Reengineering Cloud Security

    Organizations are embracing the cloud to modernize legacy applications, create more resilient business infrastructures and to support remote work. In fact, Deloitte’s “TMT Predictions 2021: Cloud Migration Trends and Forecast” report suggests that, spurred by this growth, cloud revenues will likely continue to remain above 30% through 2025. While cloud migration is predisposed to embrace an agile development methodology enabled with DevOps, many organizations still leave themselves open to risk when modernizing and migrating applications to the cloud by neglecting to embed security into their development operating model, architectural design and processes.

    When migrating to the cloud to modernize applications, DevOps and DevSecOps, as an architecture process, can enable organizations to rethink and rearchitect the security model with a “security by design” approach. If done right, organizations stand to create more secure and agile applications that balance the need for continuous releases in an evolving threat landscape with building customer trust.

    DevSecOps Requires a New Operating Model

    DevOps is a demonstrated approach to achieving better value, sooner, from IT programs and is seeing new developments in an increasingly distributed work environment. Previously, organizations may have relied on a shift-and-adopt strategy for incremental cloud replatforming. But, today’s rapidly shifting business strategies demand fast reaction time and resilient solutions, as well as flexible and agile solutions supported by DevSecOps to help development and security move at the same pace as the business.

    Importantly, DevSecOps requires an integrated team of cross-skilled cloud and cybersecurity specialists working under a shared operating model. A modernization and migration center of excellence (CoE), often led by the digital transformation leader, can help bring together cloud and cyber specialists from across the business with external cloud service providers via a shared responsibility model. Through collaboration, cross-teaming, cross-skilling and a shared operating model across cloud developer and security functions, organizations can achieve better outcomes.

    Embracing “Security by Design”

    DevSecOps, then, is about more than moving existing security processes earlier into the development process. It is about elevating, embedding and evolving your organization’s risk response, as well as rethinking and rearchitecting the way applications are designed with security as a guiding factor in the architectural decisions. Secure by design means setting up a whole DevSecOps capability to make sure security is embedded early on in application architecture design and then further safeguarded through strategies like segmentation, zero trust and attack surface management.

    Before the migration begins, DevSecOps would have developers and security specialists considering data flows, functional requirements and work streams related to workload protection, secure landing zones, operating model, network segmentation, access/controls to be implemented in a zero trust environment, attack surface management and more. An organization, for example, might use microservices to segment application access for internal versus external users to achieve enhanced security through system design.

    DevSecOps Requires Process Innovation

    DevOps and DevSecOps bring the security and application teams together with shared processes and communication to quickly, securely and efficiently roll out products from concept to production at pace. During the pandemic, teams have pushed their use of communication and collaboration tools to better support distributed teams, including the use of ChatOps, to enable real-time knowledge sharing and knowledge management, increased DevOps automation through incorporation of cloud artificial intelligence (AI)/machine learning (ML) services and reimagining traditional roles to embrace more of an IT-as-a-service operating model.

    DevSecOps

    As DevOps continues to shift left beyond DevSecOps to embrace operations, governance, and customer support, developers will need to work on increasingly integrated teams. These foundational communication leading practices can be valuable as a model for agile working across functions.

    Rethinking Cloud Security and Development

    DevSecOps can help support cloud migration and agile development programs that require speed and resilience by rethinking the development operating model, architecture approach and collaborative processes to improve security and compliance and enhance customer trust. Security specialists must understand the demands placed on developers for fast migration and continuous releases and developers need to work with cyber professionals collaboratively to make applications designed to be secure and resilient. A security-by-design approach to cloud cyber collaboration can help organizations to rethink and re-engineer their DevSecOps approach. Security specialists should also work toward making their services easily consumable in the DevOps process to enable frictionless security.

    Vikram Kunchala, Deloitte’s Cyber Cloud leader and Principal, Deloitte & Touche LLP, and Amod Bavare, Deloitte’s Global Cloud Migration and Modernization leader and Principal, Deloitte Consulting LLP contributed to this article.

  • How To Address DevSecOps Skills Shortages

    How To Address DevSecOps Skills Shortages

    “If it’s scarce, it drives the price up,” said McAfee director of systems engineering Sahba Idelkhani. And DevSecOps talent is scarce, and expensive.

    Restrictions on international travel are having an effect on immigration in some countries, notably Australia. But there’s practically nothing employers can do about that.

    But some aspects of the supposed skills shortage are, in part, self-imposed. One example is recruitment ads that specify “5+ years’ experience required” (or something similar) when that level of experience is only a desirable characteristic.

    Such practices don’t just restrict the field of candidates for that particular vacancy, they also make it hard to find entry-level positions. If candidates can’t get a foot in the door, how can they gain the experience that employers say they want?

    DevSecOps Change is Needed

    Idelkhani suggests that organizations need to change their hiring practices and put more effort into reskilling existing employees.

    In particular, if you’re looking for DevSecOps people, he suggests it’s better to teach developers about security than it is to bring security specialists (who are also in short supply) up to speed about development. The result is less rework, reduced risk and shorter development timelines.

    However, there is a risk that security specialists will tell developers what they did wrong. Proactively educating developers about security is a more productive approach.

    Cloud Academy is one of many sources for online security training courses and includes hands-on labs, sometimes involving the same tools that criminals use to breach security. Other tips Idelkhani offered include adopting a “build secure” mindset to reduce the security effort needed after systems have been created.

    A similar perspective can be applied to entry-level positions.

    Idelkhani has hired new graduates, even though it requires effort to guide and train them to the point of being productive.

    He has even adopted this approach with experienced people that have no background in security, including a former CTO and mobile developers and a pre-sales engineer.

    Revamp job descriptions so more people can apply, urges Idelkhani, as aptitude and skill are more important than specific experience, which can be taught.

    For example, instead of a large financial services organization recruiting someone with experience in incident response for cloud systems, it would probably be better to hire an incident responder and then sponsor their cloud training, he suggests.

    Furthermore, a diversity program increases the supply of candidates, quite apart from the other benefits it may bring.

    DevSecOps Training

    Employers sometimes suggest training is a waste of time and money because people simply take their new skills elsewhere in search of higher pay.

    But Idelkhani reports that his staff turnover has, in fact, fallen over the last three years, and no one has left after being trained.

    He puts this down to establishing an “emotional connection” between employee and employer, at least in part.

    However, organizations do have to accept the need to pay people what they are worth as they master new skills. But standard HR practices don’t suit skills development situations, he warns.

    People usually won’t move from their current role or company for a 10% to 20% pay raise, Idelkhani said, but would be more willing to do so for the 200% to 300% increase that comes from being considered an accomplished worker rather than a mere trainee.

    At McAfee, he is able to argue for ‘pay for value’ raises for his team; that task is generally harder at larger organizations, he said.

    “It needs a rethink [of] HR practices,” he added.

    Planning

    Substantial raises tend to require approval from higher up in the hierarchy, and that requires a clear justification for the increase. He suggests this should be done in terms of the capabilities that are being built, not based on the numbers alone.

    Managers should look at the skills they are going to need in order to deliver on the business’s strategic goals and plans, and decide how best they can be obtained. An expected DevSecOps vacancy might best be addressed by hiring a cloud developer and training them in the necessary security skills, or by retraining a person with potential who is already on the payroll.

    “It’s a long-term process,” though, that requires a lot of management effort, Idelkhani said. Using this method means identifying people’s interests and skills, aligning them with company goals, identifying the skills gaps and then developing those needed skills. This requires a training budget and getting one approved means having clear plans.

    But once you have shown the value of this approach, senior management is less likely to question it in the future.