staging-devopsy.kinsta.cloud

Tag: devsecops

  • Avoid Security Apathy with DevSecOps

    Avoid Security Apathy with DevSecOps

    Against the backdrop of rapid digital transformation accelerated by the pandemic, every industry has seen an increase in high-level cybersecurity breaches. As organizations continue to support distributed and remote work, organizations must address the risk of incomplete security policies and procedures resulting in exposure to IT risk of all kinds. SolarWinds recently revealed findings of its SolarWinds IT Trends Report 2021: Building a Secure Future, which analyzes the degree to which organizations are prepared to manage, mitigate and prevent risk in the future.

    Measuring Risk

    The survey found 46% of tech pro respondents admitted to having medium exposure to enterprise IT risk over the past 12 months. The level of perceived risk differs by size of the organization, where a sense of high or extremely high-risk exposure is perceived at enterprise organizations (19%) compared to their small business (11%) and mid-sized business (7%) counterparts. With the rise of high-level cybersecurity breaches this past year, this is a concerning reality for security within enterprises.

    However, the findings highlight a possible disconnect—although enterprise IT risk exists within their organizations, tech pro respondents are confident in their risk management and mitigation preparedness strategies. In fact, 73% of tech pro respondents “agree” or “strongly agree” their IT organization is prepared to manage, mitigate and resolve risk factor-related issues due to the policies and/or procedures they already have in place.

    How to Avoid Security Apathy

    As a tech pro, it’s easy to think of security as an afterthought or to expect ownership to fall solely on the shoulders of a dedicated security team. This is especially true for tech pros who have been with a company for a long time and are resistant to change.

    As we emerge from the pandemic, those continued perceptions reflect apathy and complacency when it comes to security and will only increase their business’ level of risk. They’ll be more apt to limit exposure to new technologies, ignore better ways of working, or worse continue to be oblivious to other areas of less obvious risk within an organization. Something needs to change.

    Tech pros must shift their mindset and accept security as one of their responsibilities. To start this process, IT teams must examine current processes from the outside in and apply rigor when evaluating solutions. Since it’s common to be bombarded with marketing messages, this means spending time verifying a tool or solution’s functions and capabilities to help separate fact from fiction.

    Next, tech pros must focus on providing complete visibility into all systems to identify areas of risk and opportunity. Even small adjustments, like speedier upgrades and patches, the adoption of password managers and multi-factor authentication (MFA) solutions can help improve an organization’s overall security posture.

    Most important of all, tech pros should be continuously assessing their risk management, mitigation, and protocols to avoid complacency and becoming “blind” to risk.

    After a year of “crisis mode” induced by the pandemic, it’s easy to be complacent and sidestep the responsibility of risk assessment and aversion. As the security landscape continues to evolve, tech pros must remain vigilant and deploy solutions that provide better visibility into systems to identify risk and opportunity. This year’s study reveals the opportunity ahead for tech pros and IT leadership to align on priorities and policies that can best position not only individual organizations but the industry at large to succeed in managing, mitigating and preventing risk in the future.

  • That Other Continuous: Data Protection

    That Other Continuous: Data Protection

    Looking around at things to add to our current project’s toolchain (that is one of the reasons we do these side projects; to check out all sorts of new ideas/tools/etc), and researching the company where a former coworker is the CMO, I was drawn into the resurgent world of continuous data protection (CDP). It is interesting that we could end up adding CDP to the list of ‘continuous’ activities, like CI/CD/… CDP, even though CDP was named long before any of our DevOps or Agile terms were born.

    The whole idea of CDP is that it is always backed up, so you are continuously protected. It largely failed when first introduced because it massively increased both the cost and complexity of your storage environment. Essentially, it required a hot copy of all of your storage. Not something most enterprises were willing to invest in. I mean, it was friggin’ expensive. And it used virtualized storage, which no one wanted to mess with. Long story short, at the time, virtualized storage introduced issues no one wanted to deal with.

    But several things have changed over the years, and it is interesting to see where CDP concepts have cropped up. You see, today it is being used to protect companies from ransomware. It’s still a bit of complexity, but we’ve become experts at hiding complexity. It still requires a lot of storage (I would argue that the current versions I’m seeing require more storage than the original CDP solutions did), but when your environment is taken over by ransomware, a clean machine can be used to restore data to a point before the ransomware took over. From a “continuous protection” standpoint—giving it a modern meaning along the lines of “continuous testing”—that is an astounding feat.

    The way it works—at least the way that the current implementations I’ve looked at work—is pretty simple at heart, though as my former coworker likes to say, “Easy in concept, difficult in implementation.” It keeps every write ever made to storage, with time and currency markers. So it knows what the disk currently looks like, but it can also get to what the disk looked like at 12:33 am yesterday. Or January first, or a year ago… You get the idea.

    It uses a ton of space because there is an implied truth here—nothing is destroyed. In traditional storage, if you change a document and hit save, the document is written over. In the new iteration of CDP, if you change a document and hit save, the changes are recorded, but the original is not altered. Call it “non-destructive writes,” if you will.

    It is worth checking out. The concepts are huge, and offer protection that is otherwise in short supply. If you have a dedicated DevSecOps team, they’re the ones I’d point at it, since the big reason for using this is a security reason at heart (though there are other uses; I’m currently gushing about security because this is a big deal).

    I’ll get back on track and report back about things directly in the toolchain for our newest DevOps project next week. I thought this was worth writing about, since most of you all could use the concept, even if only for peace of mind. You’re rocking it! Protecting your work against the newest range of attackers is just common sense. It’s worth seeing if the modern iteration of CDP is for you.

  • Building DevSecOps With Value Stream Management

    Building DevSecOps With Value Stream Management

    As teams develop software, testing for potential security risks and flaws is mission-critical, just as it has always been. Yet, cyberattackers continue to exploit code vulnerabilities as open source code remains the foundation for the majority of commercial applications across all industries. Security firms are churning out solutions at an aggressive rate, and both project managers and their teams hope they can purchase some bolt-on tool or license a service to take care of security, painlessly. In the end, vulnerabilities still occur.

    The most effective pathway to secure software code has always been to eliminate vulnerabilities. The question today is, “What is the best way to achieve that goal given such an accelerated, threat-laden landscape?” Before we dig into that answer, let’s take a closer look at the problem.

    Software Security Is Everyone’s Issue

    Even the largest organizations, from Adobe to Microsoft, have been humbled by the number and scope of code vulnerabilities that have been overlooked—and therefore escaped into public release—due to the frenzied pace of software updates. Here’s just one example:

    On May 11, 2021, Adobe issued a security update for Adobe InDesign that addressed multiple critical vulnerabilities. “Successful exploitation could lead to arbitrary code execution in the context of the current user,” the security bulletin read. “Arbitrary code execution in the context of the current user” is cybersecurity speak for “an attacker can execute arbitrary commands or code on a target machine or process.” Arbitrary code execution vulnerabilities are known to be one of the top attack vectors that lead to system penetration resulting in data breaches.

    Given the enormous effort companies and their software teams are exerting today, and the importance of avoiding software flaws in the current threat landscape, how is this happening? It doesn’t help to have publicly available lists of software vulnerabilities posted on the dark web and CVE (ironically, a database of vulnerabilities launched to help companies improve their cybersecurity). Hackers — from solopreneurs to nation-state teams — are having a field day with this information.

    Rearranging the Puzzle Pieces Doesn’t Guarantee Security

    In an attempt to resolve this challenge, industry professionals are coining new terms and calling for new approaches. One I have seen promoted recently is “SecDevOps” rather than “DevSecOps.” With SecDevOps, they assert, security is first—conducted at the start of the project and maintained all the way through.

    This approach isn’t new—it’s essentially a variant of shifting left, which for more than a decade has been an established mechanism in software testing for finding flaws and “failing faster.” In my experience, while failing earlier and faster with any software endeavor has considerable value, it is not automatically going to highlight all security challenges and enable their resolution.

    It is just as important for DevSecOps teams to collaborate and work together, not only to support development and operations, but also to ensure security, compliance and governance are built into every piece of code.

    Insight Is Preferable to Blind Interpretation

    Unfortunately, achieving that collaboration productively comes with challenges. DevSecOps teams need rich, real-time visibility into code vulnerabilities, early, so they can act on that information and update code as it moves through the pipeline. To do that, they need actionable insight—not a motley assortment of data that’s open to interpretation.

    In value stream management, we have seen firsthand while working with our clients that several techniques can be applied to eliminate vulnerabilities more quickly and effectively. All of these approaches hold value, whether a firm is seeking to deliver a new product to market or secure its current software pipeline.

    • Amplify feedback loops. Continuous feedback loops—from DevSecOps tools, for example—give developers more detailed insight into their code’s vulnerability.
    • Run security scans. Give testers the ability to run security scans on their code even before it is committed to identify security vulnerabilities as early as possible.
    • Leverage reporting and analytics. Gaining early access to as much insight as possible makes teams and management more confident regarding swift action to resolve code deficiencies.

    These approaches also support governance and compliance initiatives. As a bonus, they boost software quality, as well.

    The Business Case for Built-In Security, Governance and Compliance

    As mentioned earlier, these activities are integrally connected with the effort to eliminate code vulnerabilities. In case you are thinking, “This is obvious,” take a moment to reflect on this statistic: 60% of data breaches involved vulnerabilities for which a patch was available but not applied.

    The sheer scope of the problem also underscores the lack of attention to security and governance—and any compliance requirements that accompany it.

    Half of websites in production have high-risk vulnerabilities, and 82% of these are located in application code.

    The high percentage of errors in source code suggests it was not checked for vulnerabilities during development, signaling that developers focused on app functionality and gave short thrift to security. This often means they don’t have a program for governance and compliance, either.

    In my experience, a primary reason for these failures is that teams don’t have actionable information from the activities mentioned above, such as real-time feedback from DevSecOps tools. Developers need this insight when they are resolving sprint backlogs. Information relating to high-level security issues must be available so it can be addressed, with issues prioritized and resolved, and not left sitting in siloed DevSecOps tools.

    In many ways, DevSecOps is in the same stage of transformation as DevOps was a decade ago. Teams are frustrated by needs they do not know how to meet, and they hope for fast resolution in the form of tools and solutions. As with virtually every other software challenge over time, there is no replacement for getting in the trenches and fixing the problem rather than placing strategic band-aids.

    If you are not subject to compliance mandates and therefore dismiss the value of software governance, consider this: If your team misses a software vulnerability that results in a major data breach because you didn’t have the insight to identify it—or the governance to ensure it was addressed—your firm may not recover. The imperative for software security—and the governance that helps ensure it stays that way—should be sufficient for organizations to take vulnerabilities seriously.

    Effectively applying the insight gleaned from software code reporting and analytics is the surest way to eliminate vulnerabilities. As an added benefit, the reporting and analytics that informs the software effort can also make the case to upper management for the value of launching future improvement initiatives.

  • How DevOps Can Address CX Challenges

    How DevOps Can Address CX Challenges

    Delivering a seamless customer experience (CX) has become a top priority for companies undergoing digital transformation initiatives, as 85% of buyers are willing to pay more for a great customer experience. However, customers aren’t only willing to pay more for a positive experience–they’ll go elsewhere if their experience isn’t positive. In fact, 33% of customers will leave a brand they previously loved after just one bad experience, and 92% of customers will completely abandon a company after just two or three negative experiences. So, delivering a positive CX has become a major priority for companies that want to retain their current customers while winning over new prospects from competitors.

    To assure CX quality for customer-serving technology products and services, established DevOps processes and strategies should be applied to the unique aspects of customer experience software. DevOps for CX enables the delivery of software where the customer’s experience is paramount and quality is imperative. However, there are six major pitfalls in deploying DevOps for CX that customer-serving organizations must overcome.

    What is DevOps for CX?

    To understand the challenges, we must first understand the purpose of DevOps for CX.

    DevOps for CX refocuses the DevOps software methodology on the unique aspects of CX software to enable greater efficiency and quality. The constant delivery of expanded CX capabilities through new software developments and features has become a priority in organizations undergoing digital transformation. But when it comes to software products for CX and customer services, quality cannot be sacrificed for speedy development. At the same time, companies must still meet the demand for rapid innovations and tight deadlines on software delivery.

    Customers have higher expectations than ever before. These days, there aren’t any second chances when it comes to a customer’s experience. Social media has empowered customers to broadcast CX failures for the whole world to see. Due to the visibility of CX mishaps and negative customer interactions, a brand’s CX reputation depends on flawless execution from the customer’s first impression.

    The customer is always right; so, the customer’s perspective must be the primary consideration in software development and testing. This puts significant demand on the DevOps solutions and processes specific to user experience (UX) design, as well as CX testing and monitoring. Software must be designed, developed and continuously tested and monitored in real-time. Companies need to know all the different ways a customer might use the software to accomplish their goals and quickly identify and fix any potential issues before the customer experiences them.

    6 Potential Pitfalls of DevOps for CX

    Underinvestment in Executive Sponsorship and Cultural Evolution

    For CX transformation initiatives to succeed, they must be empowered by an executive leader who can champion the need to drive cultural change and strategic investments. An executive leader is necessary because CX initiatives typically span multiple departments: Operations, development, marketing, sales and services, for example.

    Whether the leader taking on this responsibility is an existing executive or a brand new position will depend on the company’s organizational structure. Some companies assign this duty to the COO, CIO or CMO, while others create an entirely new chief CX officer role so that the leader can give their full attention to the CX transformation initiatives at hand. Regardless of the DevOps for CX champion’s title, they must have a broad authority over budget, people and processes to make their role effective.

    Competing and Misaligned Incentives

    DevOps is a multi-team effort. Ensuring that the teams’ objectives and incentives are aligned is key to ensuring that DevOps for CX projects are executed harmoniously. Each team should have objectives that fit their team function but do not oppose other teams’ objectives, such as speed or a low defect rate on the development side and high reliability for the operations side. These functional team objectives should be centered around respective business objectives for customer satisfaction.

    Unclear Key Performance Indicators (KPIs)

    Adopting DevOps forces organizations to take on a more collaborative mindset. Due to the multi-team, collaborative nature of DevOps for CX initiatives, it’s critical that KPIs are clearly communicated, widely understood, and monitored across teams. KPIs should also be widely distributed so CX can be viewed at an operational level.

    Lack of DevSecOps Prioritization

    Many organizations fail to recognize the importance of DevSecOps from different aspects of DevOps. Not only must customer data be protected, but larger organizations that operate globally must also ensure they are complying with regional data privacy regulations. Organizations that don’t comply with regulatory requirements risk fines and other punitive setbacks.

    You must be able to test security features in production to protect both customers and your organization itself. Unfortunately, security is too often one of the last DevOps aspects to be discussed.

    Different Configurations Across CX Delivery Environments

    Shifting between development, quality assurance, staging and production is a major source of frustration for DevOps teams, as the environments are often configured differently. As code moves through the software life cycle and different environments, having a consistent approach to the solutions and environments via deployment automation will prevent wasted time fixing bugs that suddenly pop up when the code is moved.

    Errors Introduced by Manual or Outdated Processes

    Manual processes introduce opportunities for human error, causing delays and defects that result in unplanned work. Performing software testing manually is a sluggish process that not only causes quality issues and delivery delays but also reduces the amount of time developers have to execute any unplanned work or rework that must be done post-testing. Automating the CX systems’ testing results in higher quality and reliability at faster speeds, providing more time post-testing for developers to ensure the product meets quality requirements.

    DevOps for CX enables companies to innovate CX rapidly by delivering high-quality software and maintaining exceptional customer interactions. As CX leaders innovate new products and services through software, DevOps for CX practices will continue to be honed over the coming years. In the meantime, following the best practices outlined here to avoid the six major pitfalls of DevOps for CX will ensure customer experiences are maintained at an elevated level.

  • Infrastructure-as-Code Security will Improve Your Cloud Security

    Infrastructure-as-Code Security will Improve Your Cloud Security

    Moving to the cloud creates a tremendous opportunity to get security right and reduce the risk of a data breach. Most organizations start their cloud security efforts by ‘shifting security left’ thereby addressing issues in the CI/CD pipeline. Fixing known vulnerabilities and risky configurations before pushing images to production makes sense. But there is an opportunity to shift security even further left—as you set up your cloud infrastructure—to reduce risk. Infrastructure-as-code (IaC) security allows you to define security controls as you configure your cloud infrastructure.

    Getting Started on Your Cloud Journey

    Before we dive into IaC security, let’s talk about why platform teams want to deploy infrastructure-as-code as they move through their cloud journey. Most organizations have not yet tackled IaC. They start their journey by experimenting with cloud configurations until they have defined a stack that works for their teams. In this early stage, application teams may be defining their own cloud stacks. They are manually configuring infrastructure or using scripts. Configurations may not be standardized across teams.

    Standardization of Infrastructure Saves Time

    Although experimentation is reasonable early on in the journey, standardization of infrastructure saves time. Cloud services are no different than applications that run on premises. When your teams are using different versions of tools in their stack, getting an application up and running can be a nightmare. Interoperability between services is challenging, and it can feel like you are fixing a different flavor of the same problem over and over.

    Mature cloud platform teams typically prefer to create a ‘golden image’ with a baseline set of services for development teams. They may create a menu of a few standard options to meet different teams’ needs. Because they are standardized, the platform team can take time to validate that they interoperate and are secure. For example, these golden images will be regularly scanned for vulnerabilities and updated to ensure they meet internal security standards and any relevant regulatory requirements.

    IaC security cloud

    Automating Infrastructure Deployment Reduces Errors

    Manually configuring the environment in the cloud for each team is tedious. Once these configurations have been standardized, the cloud infrastructure can be provisioned as code using templates. A declarative approach defines the desired end state, whereas an imperative approach defines the detailed steps to achieve the end state. The templates are normally stored in a Git repository and version controlled. Automating the configuration of infrastructure not only saves time but also reduces errors that can disrupt operations.

    IaC Security Shifts Security Further Left

    Once you have templates that define your infrastructure, standardizing permissions and access rights for services-as-code is a logical next step. The security team typically defines the guardrails or policies for accessing cloud services. These policies can then be defined as code along with the infrastructure configurations. This IaC security is a further ‘shift left’, allowing security to be embedded into infrastructure, even before an application can be deployed. Implementing policy-as-code minimizes the opportunity for human error in configuring security services. By defining these policies and enforcement guidelines together, the DevOps and security teams can establish a trusted partnership.

    Although some organizations may start their journey by implementing IaC security, for most organizations it happens later in the cloud journey. The order is less important than ensuring you take a DevSecOps approach and embed security at each stage to manage risk. Be sure to address the following areas as part of your cloud and container security program:

    Continuously Check Cloud Permissions and Configurations

    Even if you have IaC templates, you need a program to regularly take inventory of all cloud assets and confirm permissions and configurations. The Center for Internet Security (CIS) benchmarks are commonly used to check passwords and access rights. Beyond enforcing these best practices for security on cloud services, continuously checking for changes to permissions and suspicious activity is critical. The cloud vendors capture logs across all of their services, and your security tool should continually monitor and alert using those logs.

    Scan Images for Vulnerabilities and Risky Configurations

    Scanning for vulnerabilities and ensuring configurations use best practices allows you to shift security left into the development pipeline. Scan everywhere you have images—including within registries, pipelines and also check for new vulnerabilities identified for images running in production. Be sure to scan hosts as well as containers. Defining scanning policies and enforcing through the development process creates guardrails for the development team and clarifies expectations. Most regulatory compliance standards have image scanning requirements as well.

    Detect Threats and Respond to Alerts

    Prevention is fundamental but must be supplemented with threat detection and response. Alerting on unexpected behavior can identify the presence of a threat. Initially, teams may use out-of-the-box detection rules as a way to get started and then customize rules over time. Checking configs against dockerfile best practices is a good way to get started. Overly permissive access rights for containers is common in Kubernetes environments and should be allowed only when required.

    As your team develops more expertise with containers and Kubernetes, you can also implement zero-trust network security policies to block unexpected communication between pods, services and applications.

    Some DevOps teams handle triage of alerts, as they can quickly determine if the issue is a configuration issue or an indicator of compromise. Teams often map detection rules to the MITRE ATT&CK framework, allowing their security teams to manage alerts consistently across their environment. For any team to effectively respond to a security alert, it is important to capture a detailed record of exactly what happened before, during and after that event. This visibility can be particularly challenging with containers but it is critical because containers have short lives. The 2021 Sysdig Container Security and Usage Report revealed that about half of containers live less than five minutes.

    Complying with Regulatory Standards

    Complying with regulatory standards can be painful. Some standards were written with cloud computing in mind, like NIST 800-53 and SOC2, and others were not. With those broader standards, it is important to understand the controls that are relevant to containers and the cloud.

    As you consider your compliance program, be proactive—don’t wait until you are ready to roll into production. Start early by engaging your compliance team and helping them get up to speed. Your role is to provide evidence of compliance to pass an audit at any time using the documentation from your security platform.

    Getting Cloud and Container Security Right

    The move to the cloud creates a tremendous opportunity to get security right and reduce risk. The fact that physical security and a chunk of operations are delegated to cloud vendors frees up security and development teams to focus on their more narrow scope within the shared security model. By taking a secure DevOps approach and inserting security into every stage of the application life cycle, your team can confidently and securely run cloud and containers.

  • How to Prepare Your DevOps Environment for DevSecOps

    How to Prepare Your DevOps Environment for DevSecOps

    The COVID-19 pandemic has created a deep, irreversible change within work environments, as most organizations are reimagining this “new normal” with a combination of fully remote or hybrid work. DevOps practices are being increasingly normalized and relied upon to respond to the needs of modern, digitized companies. Coming out of the pandemic, organizations now better understand the need to efficiently deploy the software applications necessary to thrive in this new world of work.

    This isn’t surprising given organizations have realized the value of DevOps to help product teams deliver quality code at a fast pace. DevOps enables them to be more agile and move more quickly to respond to evolving market changes and business demands. To maintain the speed of software delivery, product teams are integrating various tools within their CI/CD pipelines and minimizing tool citations and validations outside of their pipelines.

    As the rate of change increases alongside these DevOps practices, automating compliance to enterprise security controls becomes more important than ever, especially given that security vulnerabilities in code and configurations present dire business risks. For DevOps to truly succeed, organizations need to modernize and automate security processes, making them an integral part of the DevOps build and delivery pipeline—readying the overall DevOps environment for DevSecOps.

    But successful DevSecOps deployments depend heavily on the maturity of an organization’s current DevOps environment and security operations workflows. This includes prioritizing the core principles of automation, measurement and collaboration because these same principles also drive positive security outcomes. Referencing these principles, here are four best practices organizations should consider incorporating when evaluating how to mature their DevOps ecosystem and security operations processes to be ready for DevSecOps.

    Embed Security Tools in Developer Workflows and Governance Processes

    The first step in the journey prioritizes a “security-first” mindset and related skills for development teams. Security shouldn’t be an afterthought, and development teams shouldn’t rely on security teams to check vulnerabilities later in the life cycle. Instead, security experts need to become an integral part of the development phase so that the code accounts for security from the get-go.

    This can be achieved either by moving responsibility for security skills into the development teams or by having the security team play an advisory role earlier in the life cycle. Development teams can then automate the necessary security vulnerability checks—like static application security testing (SAST), software composition analysis (SCA) and dynamic application security testing (DAST). But more importantly, sharing insights and streamlining communication between development and security teams is crucial to ensure policies are working and are being consistently applied across the organization.

    Continue Automation Beyond the Pipeline

    Puppet’s 2020 State of DevOps Report revealed that organizations have matured their DevOps environment by improving governance processes such as change management, preparing enterprise infrastructure and applications for organizational change. In fact, they found that organizations with automated change management and governance processes are nearly three times more likely to outperform competitors in DevOps transformations.

    This is because automation improves change management processes, which in turn eliminates barriers to applying governance to DevOps. This is also backed by Puppet’s survey, which cited that automation makes organizations more confident that their change management solutions are effective. A comprehensive, automated change management process instills governance by applying policy-based rules to a code or configuration change before allowing it into production. It does this in real-time by leveraging data collected from the pipeline. When applied correctly, DevSecOps tools prevent vulnerabilities and automated change management conducts a ‘last mile’ check to ensure the correct scans were run and adhere to compliance policies.

    Provide End-to-End Traceability Across DevOps

    Product teams—and all involved in the delivery of an application—should have an accessible audit trail, providing visibility into security checks, users, code and configuration changes, code quality, testing and more. This paints a clear picture of what happens to the software from ideation to production. In an ideal world, product teams include both operations and security personnel, but these functions often remain siloed in large organizations.

    Companies can break down these silos and make it easier for teams to collaborate by centralizing visibility. Providing visibility and centralizing security policies makes it easy for teams to efficiently operate the delivery process of software since they are provided a single source of truth. Additionally, an automated system for gathering audit data improves the consistency and reliability of audit information. Automatically collecting data from the entire pipeline and eliminating the need for developers to enter information diminishes the likelihood of data anomalies—saving valuable time and resources.

    Empower Cross-Enterprise Collaboration to Address Security Issues in the DevOps Pipeline

    Applying artificial intelligence and machine learning to DevSecOps processes helps organizations quickly identify and remediate security issues before they are manifested in production, enhancing proactive and actionable collaboration and coordination across product teams.

    As Puppet cited in its 2019 State of DevOps Report, sharing and collaboration are two of the most impactful things teams can prioritize to improve DevOps initiatives, including DevSecOps, and this still holds true today. The 2020 survey results signaled how many more organizations are reaching this peak point of DevOps maturity.

    Ultimately, we’re already seeing how operational activities—like checking software for security vulnerabilities—are moving into the DevOps pipeline and are being handled as “code.” But organizations should take this a step further by keeping in mind factors such as reliability, predictability, measurability and observability across DevOps deployments to foster more secure environments and pipelines.

  • Google Unveils Tool to Better Secure GitHub Repos

    Google Unveils Tool to Better Secure GitHub Repos

    Google today launched a GitHub app that provides automated continuous enforcement of security best practices for GitHub projects.

    Kim Lewandowski, a product manager for open source software security at Google, said the Allstar application enables IT teams to assess any project on GitHub to check for security policy adherence. In addition, Allstar sets desired enforcement actions and automatically applies those rules when triggered by a setting or file change in a repository.

    The goal is to provide the open source community with a tool that makes it possible for organizations to have more confidence in the open source software that is being employed within a software supply chain, said Lewandowski.

    Allstar is intended as a companion application for Security Scorecards, a tool that Google made available last year to assess whether, for example, an open source project employs branch protection to ensure that malware isn’t inadvertently committed to a project. Allstar continuously checks expected GitHub API states and repository file contents against security policies and the enforcement actions defined by an IT organization. After it detects a policy violation, the tool can be configured to simply send an alert or to automatically enforce a specific policy to remediate the issue, said Lewandoski. Specifically, she said the options available are to log the security policy violation without taking any additional action, open a GitHub issue or modify the GitHub setting to match the original Allstar configuration.

    At present, Allstar provides a limited number of security policy checks, but more will be made available over the coming months, said Lewandowski. Current security policy checks include branch protection, vulnerability disclosures, access controls and detection of binary artifacts that can’t be scanned. Additional checks that will be added include automatic dependency updates and frozen dependencies.

    Lewandowksi said Allstar and Security Scorecards are part of an ongoing Google effort to give back to the open source community that is being targeted by cybercriminals attempting to compromise software supply chains. Just about every application is now dependent on open source components, to some degree. The maintainers of those projects, however, don’t always have the tools or expertise required to check for malware that has been injected into a codebase, she noted.

    In general, Lewandoski noted that achieving DevSecOps best practices will require a lot more automation of application security. It’s not possible for each developer to become a world-class cybersecurity expert. The challenge is finding a way to introduce that automation into the application development process as early as possible, which, she noted, in many cases starts with open source components that are incorporated in applications.

    It may take a while for every maintainer of an open source project to revamp the processes through which code is added to their project. However, the easier it becomes to continuously review that software, the more confidence organizations that use it will have in its security. In fact, the maintainers of those projects should expect the downstream users of that software to be asking some pointed questions about how security is being managed in the wake of a series of recent high-profile breaches of software supply chains.

  • Datadog Cloud Security Platform Advances DevSecOps

    Datadog Cloud Security Platform Advances DevSecOps

    Datadog has launched a Datadog Cloud Security Platform that promises to advance DevSecOps by identifying potential threats using the same agent software many DevOps teams already rely on to instrument applications.

    Renaud Boutet, senior vice president of product for Datadog, said organizations that rely on the Datadog software-as-a-service (SaaS) platform can now more easily invoke security services based on the same data model used to observe applications.

    The security services provided by Datadog include a cloud security posture management (CSPM) offering that identifies misconfigurations and applications that are not compliant with industry standards such as the Payment Card Industry Data Security Standard (PCI DSS).

    A cloud workload security (CWS) offering, meanwhile, detects threats to production workloads by monitoring file and process activity, while a monitoring tool identifies threats to cloud environments by analyzing operational and security logs. It also provides integrations and threat detection rules that are easy to extend and customize.

    Finally, there is an application security tool, currently in beta, that identifies and blocks attacks that target code-level vulnerabilities, such as SQL injections and cross-site scripting (XSS) exploits.

    Boutet noted that many DevOps teams are reluctant to roll out security platforms that require them to deploy, manage and update an additional set of agents across their application environment. Datadog is now effectively unifying application observability and security in a way that makes it simpler for those DevOps teams to embrace DevSecOps best practices, added Boutet.

    In some cases, the dashboards surfaced by Datadog will be employed by DevOps teams that have assumed responsibility for cybersecurity as part of an effort to shift more responsibility for application security further left, noted Boutet. In other instances, cybersecurity teams will be able to view the same alerts shared with their DevOps colleagues, he added.

    Pressure to address DevSecOps is mounting in the wake of a spate of high-profile software supply chain breaches. While the majority of organizations have not been breached, questions are now being asked at the boardroom level as concerns over application security increase. Many organizations are wondering if they should slow down the pace of application development to ensure better security and to what degree.

    Regardless of the path forward, awareness of application security has never been higher. An executive order issued by President Biden calling for improvements to security will likely have a cascading effect across not just government agencies but also on organizations that do business with those agencies. One way or another, DevOps teams and cybersecurity professionals will be required to work more closely together. The challenge is striking the right balance between security and productivity. Most developers are never going to become world-class security experts. Conversely, most security professionals know next to nothing about coding. That doesn’t mean, however, that efforts shouldn’t be made to educate both camps as much as possible. After all, even a small amount of education can have a profound impact when most of the attacks being made against applications are not especially sophisticated.

  • Establishing Trust in Multi-Cloud Environments

    Establishing Trust in Multi-Cloud Environments

    Modern applications are transforming enterprises into digital innovation factories. However, the distributed nature and complexity of modern apps have made it extremely difficult for organizations to maintain trust and compliance across multi-platform, multi-cloud environments. 

    Although Kubernetes is the standard for application platforms today, each cloud service provider (CSP) has a different offering for infrastructure-as-a-service (IaaS) or their own platform-as-a-service (PaaS) with varying capabilities and APIs. Not only are these APIs incompatible (with the exception of Kubernetes if no vendor extensions are used), each infrastructure and platform are treated and managed in silos. These silos act as an isolated and non-overlapping administrative boundary,  preventing cross-boundary visibility and trust between microservices.  This makes it much harder for enterprises to know and consistently remediate their security posture across clouds and platforms, opening them up to attacks.

    To solve this problem, organizations are extending enterprise security controls to cloud environments. The problem is that application teams and security teams have traditionally had competing goals—agility versus risk and control—and security operations have not evolved at the same pace as application operations. This creates friction between the teams and forces application operation teams to make a choice: 

    1) Slow down application delivery and operations to reduce risk and miss out on the transformative benefits of multi-cloud or 

    2) Continue to develop and ship applications as quickly as possible without considering security and compliance. 

    Neither is a good option. To unlock the power of modern applications running in multi-platform and multi-cloud environments, organizations need to find a way to integrate security seamlessly throughout the software delivery life cycle at the speed users expect.

    Integrating Zero-Trust into the Application Delivery Cycle

    The key to securing applications in a multi-cloud world is zero-trust. Building zero-trust principles directly into modern applications allows organizations to identify threats early, reduce attack surfaces and ship security functions alongside the rest of the application stack—regardless of the underlying application platforms and cloud stacks underneath.

    In this use case, one of the key components of zero-trust is application segmentation; in other words, how to make access decisions between different applications or components of applications. Zero-trust must provide identity-aware, adaptative and on-demand access to any app from any user or app in a way that improves the flexibility and the agility of application access through a scalable model.

    Application segmentation must be provided to application operation teams so that they can embed it into their application quality processes as another gate. Application operation teams can do this by implementing application segmentation policies that identify workloads as they are created through rich, dynamic attributes. The more intrinsic/static attributes (IPs, digital certificates, namespaces, labels, etc.) and extrinsic/dynamic attributes (user behavior, workload behavior, network behavior, etc.) that are identified, the more fine-grained your access decisions can be. 

    Incredibly, application segmentation today continues to be done manually. But with millions of transactions happening across multiple cloud environments, there’s no way a person—or even a team of people—can manually assign policies to each workload. Organizations need a way to deliver zero-trust application segmentation in a scalable, transparent and automatic fashion. 

    A Connectivity and Security Platform 

    The way to do this is through the use of a modern application connectivity and security platform. Through a service mesh, an attribute-based access control (ABAC) model consolidates multiple third-party tools that provide visibility and security across application platforms and multi-cloud environments. This single view operational model gives application teams the ability to seamlessly and simply orchestrate security services across multi-cloud environments, automatically and at scale. 

    Unfortunately, granular policy management through microsegmentation increases complexity, which is the enemy of security. Suddenly, an organization may find itself with thousands of policies that dictate how different workloads access and interact with entities inside the network. These policies need to be continually updated and maintained, creating massive headaches for both application and security teams.

    When a workload is deployed, the associated policies are created along with it and move through the environment with the workload until the workload reaches the end of its life and is decommissioned. As applications run over time, they are being characterized by their unique behavior. This runtime security characterization allows policies to be automatically selected and applied directly to the workload.

     However, for a service mesh to work and enable secure applications in a multi-cloud environment, it needs to follow zero-trust principles without adding complexity and without slowing down the agile delivery cycle. Here’s how you do that:

    1. Baselining trust: A modern app connectivity and security platform should have native observability and self-discovery capabilities, such as being able to automatically discover APIs, catalog APIs and generate API documentation based on the OpenAPI standard. The modern app connectivity and security platform should be able to continuously baseline application behavior and detect anomalous application behaviors. This needs to alert on unknown and zero-day attacks, especially exfiltration of sensitive data.
    2. Establishing trust: It is critical to define the interconnectivity needs of different pieces of the application right off the bat. This explicit declaration of intent is typically done manually by application teams during the deployment of the application as part of a CI/CD pipeline. Another option is to automatically discover the connectivity intent during the testing phase of the application and allowing the service mesh to identify and record the resulting communication flows between microservices’ APIs. These are the basis of the application’s segmentation policies.
    3. Enforcing trust: There also must be a mechanism to automatically apply the appropriate application segmentation policies to enable the necessary communication for the application to run as intended. In the microservices model, different pieces of the application are spun up and down dynamically to enable the application to run as intended. It’s critical that the application segmentation policies that govern accessibility also adapt to these changes. This is done through the service mesh control plane that interacts with the application platform to gather the inventory of workloads.
    4. Dynamically adjust trust: As the applications run over time and clients interact with them, they are being characterized by a behavior. In this case, a security behavior. Observing this behavior can be accomplished through various runtime analysis tools that organizations already have in place that detect process, container, network and user behavior to provide security context. However, to maintain trust, there needs to be a way to integrate these tools through the service mesh to create a single source of truth. 
    5. Extending the trust model to the edge: Applications also interact with software-as-a-service (SaaS) platforms such as Salesforce or SAP, and other apps outside the data center. Ideally, the service mesh/zero-trust application segmentation model can integrate with other security solutions in the cloud such as secure access service edge (SASE), secure web gateway (SWG), cloud access security broker (CASB) and other zero-trust security components. This standardizes the processes for establishing trust across the data center, multiple cloud service providers, SaaS platforms and web apps—ensuring consistent security and compliance posture across the entire organization.

    Modern applications are transforming how business works by enabling agility and real-time decision making, but they will never reach their full potential unless application teams work with security teams to protect users, data and applications in multi-cloud environments. It’s clear that organizations need an evolved security model that application teams can use to seamlessly establish trust and orchestrate application segmentation across multi-cloud, multi-platform environments. Service meshes can provide the visibility and control needed to establish and continually evaluate trust.

  • Sophos Acquires Refactr to Advance DevSecOps

    Sophos Acquires Refactr to Advance DevSecOps

    Sophos this week revealed it has acquired Refactr, a provider of an automation platform that makes it simpler to add static and dynamic security scanning and application testing to a DevOps pipeline. Terms of the deal were not disclosed.

    Joe Levy, Sophos CTO, said Sophos will extend the Refactr DevSecOps automation platform to add security orchestration automation and response (SOAR) capabilities. This will provide DevOps teams with access to its managed threat response (MTR) and extended detection and response (XDR) platforms. The goal is to make it simpler for DevOps and cybersecurity teams to collaborate once those integrations are achieved in early 2022, added Levy. Sophos will also continue to develop the Refactr platform as a standalone offering in addition to maintaining the current community edition of the platform, noted Levy.

    Refactr Sophos

    Sophos has acquired a range of cybersecurity companies since it rearchitected its core platform to create an extensible security framework known as the Adaptive Cybersecurity Ecosystem. That platform is built on a modern microservices-based architecture that simplifies integration of acquisitions. Collectively, those acquisitions enable Sophos to collect a wider range of data that can be used to train artificial intelligence (AI) models and continuously better automate DevSecOps processes, noted Levy.

    Recent Sophos acquisitions include Capsule8, a provider of a platform for securing containers and BrainTrace, a provider of managed security services. Sophos also acquired Rook Security, another managed security services provider, in 2019.

    In general, Sophos is making the case for a security platform that both DevOps and cybersecurity teams can navigate. In addition to integrating with continuous delivery and continuous deployment (CI/CD) workflows via application programming interfaces (APIs), the Refactr platform can also be accessed via visual tools that can be employed to create launch tests using a drag-and-drop tool.

    In the wake of a spate of high-profile software supply chain breaches, there’s now more focus on implementing DevSecOps best practices. The challenge organizations face is finding a way to achieve that goal without unduly slowing down the rate at which applications are built and deployed. Achieving that goal requires finding more ways to automate, for example, scans of code during the build process.

    In the meantime, however, a recent Sophos Active Adversary Playbook 2021 illustrates how organizations find themselves outgunned by their cybercriminal adversaries. The report details how 37 different attack groups used more than 400 different tools between them to launch cyberattacks. The attackers’ median dwell time before the attacks were detected was 11 days.

    It’s clear that without advances in automation and AI, the odds of securing software supply chains are slim to none. The challenge organizations face is finding a way to affordably tap into AI and automation technology and expertise. Individual organizations are not really in a position to build, for example, AI models capable of automating a cybersecurity process. Most organizations will wind up using APIs to invoke advanced security services delivered via the cloud within the context of a DevSecOps workflow. The issue is determining which service provider offers the most integrated and robust capabilities at the lowest cost.