devopsy.kinsta.cloud

Category: DevSecOps

  • Checkmarx Report Highlights Need for AppSec Collaboration

    Checkmarx Report Highlights Need for AppSec Collaboration

    A research report published by Checkmarx finds the same basic malicious software developed using multiple programming languages as cyberattackers industrialize their malware development processes.

    Checkmarx, a provider of code scanning tools, shared examples of malicious packages written in multiple programming languages. These example packages share the same indicators of compromise that have gone undetected for years. A “junkeldat” PyPI package for Python applications, for example, that has been compromised also shows up in a Ruby version of the package.

    Tzachi Zornstain, head of supply chain security for Checkmarx, said much like any other development team that uses multiple programming languages, it appears cybercriminals are also sharing techniques. These examples highlight the need for development teams to share security intelligence even if they build applications using different programming languages, he added. There is a tendency for development teams using one programming language to ignore application security issues that appear to only impact applications written in another programming language, noted Zornstain.

    The fact that the packages remained undetected for such a long period of time is due—at least in part—to the lack of information sharing in the ecosystem, said Zornstain.

    Cyberattackers are, of course, trying to take advantage of the implicit trust many development teams have in open source projects. However, now that more cybercriminals are making a concerted effort to compromise downstream software components, it’s imperative that every component be vetted, said Zornstain. In fact, organizations should not use any code provided by strangers, he advises.

    The core issue is that many open source projects are maintained by a small number of programmers contributing their time and effort to building components that others are free to use. Many of them argue that the onus for making sure software is secure is on the organizations that decide to deploy that software. Nor is it their responsibility to keep track of cybercrimimals distributing malicious versions of their software.

    Unfortunately, many IT vendors and large enterprise IT organizations that rely on that code are, unfortunately, not contributing anything meaningful back to the project, either in terms of financing or helping open source maintainers find and remediate vulnerabilities. Many of those same organizations, however, are assessing whether the open source software they employ is, from a security perspective, actually sustainable in the absence of those contributions. As a result, it may be only a matter of time before these long-simmering open source software security concerns boil over into a larger crisis.

    One way or another, DevSecOps best practices will need to be applied to application development at a deeper level. Organizations can’t assume that the software components they are relying on have been scanned for vulnerabilities by someone else. It’s simply too easy for a development team to make a mistake. The need for higher levels of security may lengthen the development process, but the alternative—malware infestations wreaking havoc—is far less desirable.

  • DevSecOps: Realities of Policy Management

    DevSecOps: Realities of Policy Management

    Policy management is essential to scale cloud environments and is key to secure DevOps practices. It enables organizations to manage policies put in place that secure the cloud environment, ensure Kubernetes configurations are secure and enable the continuous monitoring of a company’s overall security posture. 

     As businesses migrate workloads across multi-cloud architectures to achieve the agility and scalability needed to keep up with the pace of digital transformation, the growing demands placed upon developers often leave a gap that exposes potential threats and risks in the configuration settings, making security an even greater focus in DevOps. In fact, IDC’s 2020 survey found that 67% of breaches in the cloud are caused by misconfigured applications or infrastructure, including some of the industry’s largest breaches like Marriott’s second breach.

     To add to this, the first State of Policy Management report by Nirmata and the creators of the CNCF project Kyverno revealed that nearly 50% of users in cloud-native environments have now adopted some type of policy management solution. This tipping point of mainstream adoption across production cloud-native environments is making it critically important for DevOps teams to look at their practices and simplify and operationalize policy management across their Kubernetes stack by eliminating vulnerabilities through built-in, curated policies, without the barrier of learning complex policy languages. But this widespread adoption also acknowledges that organizations are finally realizing the need to put attention, investment and innovation into addressing security and compliance gaps as they adopt Kubernetes through proper DevSecOps practices and tools so applications being built can empower businesses.

    To confidently build cloud applications in Kubernetes, DevSecOps teams need to accept these DevSecOps realities and apply policy management effectively. 

     Customization Creates Security Risks

    Kubernetes can be highly customized, but DevSecOps teams need visibility into what’s happening in each cluster as organizations scale to ensure application reliability and security. Exploits on containers—including malware installation, cryptomining, host access and privilege escalation—offer opportunities for more security vulnerabilities. They can exist in images, production-accessible container registries, failed builds and third-party admission controllers in Kubernetes clusters.

    To address these risks in applications running on Kubernetes, it’s important to protect your environment with three A’s: Authentication, authorization and admission. This should be done at the cluster layer which enables secure access to authenticated entities that are authorized to perform certain actions. One way to accomplish this is through policy management. In fact, according to the State of Policy Management report, the top use case for policy management is for Kubernetes admission control (31%). When a request is authorized, having a policy in place ensures the request goes through another set of filters. For example, an authorized request may be rejected by an admission controller due to quotas or due to other higher-priority requests. In addition to validation, admission webhooks can also mutate incoming requests as a way of processing request objects for use before reaching the Kubernetes API server. 

    Configuration Issues

    Container images, namespaces, runtime privileges, persistent storage and control plane, together with network policies that are not compatible with best practices, are a source of misconfiguration and risk exposures. It’s this potential for greater risk exposures that have led configuration management to be a key driver of policy management adoption. In the Nirmata State of Policy Management report, it ranked third in security tools that are adopted today and fourth for the organization’s plans for future adoption.

    There are several ways to define security policies to protect cloud environments. Policies can be used for auditing purposes, to reject pod creation or to mutate the pod and limit what it can do. By default, pods can receive traffic from any source and send traffic to any destination. Network policies allow you to limit the ingress and egress access for your pods. The network policy typically translates to firewall rules.

    Lack of Adequate Authorization 

    Cloud authentication allows authorized users to securely access information stored in the cloud with authentication provided through cloud-based services. In The State of Policy Management report, key findings revealed that more than 24% of respondents today are using tools like policy management to authenticate users accessing applications. With data theft one of the fastest-growing and most expensive cybercrimes, the ability to process information and have strong authorization measures needs to be part of DevSecOps best practices.  

    In Kubernetes environments, as a user request is authenticated, it goes through an authorization workflow that decides if the request should be granted. It evaluates the request attributes against all policies and allows or denies the request. The main authorization mechanism is role-based access control (RBAC). Each authenticated request has an HTTP verb like GET, POST or DELETE, and authenticated entities have a role that allows or denies the request. Other authorization mechanisms include attribute-based access control (ABAC), node authorization and webhook mode.

    As the trend of moving security further to the left in the application life cycle accelerates, developers are being required to take active responsibility for it, which creates a higher desire for automation. The rapid releases can expose applications to many vulnerabilities, raising the risk of a breach.  With DevSecOps, organizations can transform the development pipeline by shifting security and compliance to the left, enabling developers to check the code before every commit. In doing so, security and compliance vulnerabilities can be identified and fixed in development, saving the organization from high costs and negative publicity from potential breaches. 

    There’s no doubt that Kubernetes is complex and challenging to adopt. On top of this, the development landscape is flooded with tools and more demands are being placed on engineers.  These shifts are changing the traditional role of a developer, leaving a gap for organizations to address to get the most out of DevOps. But by taking a secure, continuous, iterative approach that also includes policy management, companies can reduce the risk and exposure of their cloud environments. The more mature an organization’s DevOps practices are, then generally, the stronger the security and compliance practices are—they grow in relation to each other. The most innovative companies accept policy management in DevSecOps as a necessity of development and adopt some level of policy management best practices. With the right implementation tools like policy management and security and compliance best practices, organizations can remain efficient in agile and DevOps while adhering to critical go-live deadlines—which can’t be missed in this fast-paced business environment. 

  • Twitter/Bluesky ADX Algorithm | Cloud Energy Use ‘Tripled’ | Apple Staff are Revolting

    Twitter/Bluesky ADX Algorithm | Cloud Energy Use ‘Tripled’ | Apple Staff are Revolting

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Bluesky—Twitter’s research spinout—opens its ADX algorithm, Irish data center electricity worries grow, and Apple employees are the latest to rise up against hybrid working. (more…)

  • Synopsys Sets Course After Agreeing to Acquire WhiteHat Security

    Synopsys Sets Course After Agreeing to Acquire WhiteHat Security

    Synopsys, Inc. plans to add dynamic application security testing (DAST) tools to its software-as-a-service (SaaS) platform in the wake of agreeing to acquire WhiteHat Security from NTT Security Corp. for approximately $330 million in cash.

    Jason Schmitt, general manager of the Software Integrity Group at Synopsys, said the DAST tools developed by WhiteHat will complement the existing static, interactive and software composition analysis tools that Synopsys currently provides.

    The goal is to provide an end-to-end application security platform, including consulting, to help organizations better secure software supply chains, he added. NTT Security Corporation previously acquired WhiteHat Security in 2019 to extend the reach of the services it provides. Since then, SaaS platforms for testing application security have become more widely available.

    The acquisition comes at a time when many organizations are trying to determine how far left to shift responsibility for application security toward developers. While developers have a role to play, Schmitt said that shifting responsibility for applications completely left is a fallacy. DevOps teams will need to rely more on platforms that provide guardrails that enable developers to build secure applications in a way that doesn’t create a lot of additional friction, he said.

    Unfortunately, cyberattacks against applications are increasing in complexity and volume. That makes it a challenge for both application developers, DevOps teams and security professionals to keep track of how threats to applications are evolving, said Schmitt. As more companies rely on software to drive digital business initiatives, Schmitt said the business risks those organizations will face are only going to increase. In an era where developers far outnumber security professionals, he added that the only way to rise to that challenge is to rely more on SaaS platforms that enable organizations to implement DevSecOps best practices within their existing application development workflows, he noted.

    Today, the challenge is that much of an organization’s security budget is allocated to networks and endpoints rather than applications, added Schmitt. It’s not clear to what degree that spending needs to shift toward application security or if a larger portion of the application development budget needs to be allocated to security. One way or another, however, it’s apparent that overall spending on application security needs to increase to combat the increasingly frequent attacks.

    In the meantime, the historical divide that has existed between developers and cybersecurity teams should narrow as more security tools are made accessible to developers and DevOps teams alike. Otherwise, security professionals will continue to point out security issues that might affect an application running in a production environment and developers will continue to ignore issues they don’t see as relevant or that they don’t have time to patch. Not surprisingly, most vulnerabilities in applications running in production environments remain unpatched; the only way forward is to rely on automation to eliminate them before the application is ever deployed.

  • Self-Service Helps Devs Solve Cloud Security and Compliance

    Self-Service Helps Devs Solve Cloud Security and Compliance

    Organizations that need compliance must follow a growing number of security standards—PCI, HIPAA, SOC 2 and GDPR just to name a few. Every new standard gives rise to an exhaustive list of hard-to-implement security controls.

    Cloud providers like AWS have tried to help, but there is still a lot left for developers to do to secure their infrastructure. Cloud providers give you the raw materials necessary to remain compliant, but you’ll have to learn how to use them.

    It may be easier to envision the scale of the compliance challenge by working through an example. PCI DSS is a typical security standard. When moving to the cloud, you’ll have to figure out how to take your compliant infrastructure and implement it using cloud technologies.

    PCI has several requirements regarding network architecture and firewall barriers. For example, specification 1.1.4 calls for a “firewall at each internet connection and between any demilitarized zone (DMZ) and the internal network zone.”

    Segmentation is the goal. Your network can’t allow traffic to move freely to wherever it wants. You need to set up rules and carefully guard sensitive areas of the system.

    In AWS, we’d suggest implementing this requirement using a mixture of services. Testing, staging and production regions of your application should each be in their own VPC. You’ll also need intelligent use of Security Groups, identity and access management (IAM) and instance profiles. Lock everything down and only open the necessary ports. A web application firewall (WAF) should protect the perimeter.

    IaaS services like RDS and Elasticsearch should be isolated via security group. Platform services like Dynamo, S3, SQS and Secrets Manager should be isolated via IAM. Lambda has one leg in the security group and another in IAM.

    PCI control 6.1 states that you must have a mechanism in place to identify security vulnerabilities within your compliant systems. How can you accomplish this in AWS?

    Automation is your best friend in application security. As the speed of development increases, security must keep up. And while there will always be a place for humans to dig into applications through penetration testing to find tricky vulnerabilities, automation will help you find the low-hanging fruit.

    AWS Inspector is an API-based service that will proactively scan and assess your application for vulnerabilities and warn you about them. This is an automatic process once it is set up, but it requires an administrator to choose what to test.

    Other tools exist to automate application security, such as Wazuh. As with AWS Inspector, there is effort involved in setting it up, initially. But once you complete the configuration, you’ll have a constant security scan running to find vulnerabilities before they reach production. And should some slip in, the scans will continue to search and find vulnerabilities before attackers exploit them.

    PCI Requirement 7 states that you must “restrict access to cardholder data by business need to know.” You’ll need to know who has access to what within your application and when they can access it.

    Restricting access in a cloud environment can be challenging because you require administrators to configure the services that your application needs to work. How can you limit access while allowing the admins to do their jobs?

    Orchestrating access control will require careful use of AWS Security Groups, IAM and federated tokens. Give your admins a token for access that expires quickly. Whitelist trusted IPs for access only to the areas of your environment that are necessary for the user’s role.

    The whitelist of IPs and the security groups will need to be kept up-to-date to make sure no holes open when personnel changes. Keep a tight grip on access control in your cloud environment.

    PCI Requirement 10 outlines the need to track and monitor all access to network resources and cardholder data. As your cloud environment grows, you’ll need more help to keep tabs on changes and user activity.

    AWS CloudTrail can be used to track user activity and API usage. But you’ll have to make sure that CloudTrail can’t be disabled without your knowledge to hide someone’s illicit activity. AWS IAM and Config services can be used to make sure CloudTrail can’t be disabled and to alert you if it is.

    CloudTrail can cover user activity, but what about infrastructure changes? You may need to bring in another tool, such as ELK, to track changes to your infrastructure. You can then marry the data from CloudTrail and ELK into a single SIEM for dashboarding.

    From this example and just these few requirements, you can see that the cloud is not a “push-button” solution.

    And this is only one example. Remaining compliant with SOC 2, HIPAA, GDPR, NIST and a host of other standards will require the same careful planning and execution.

    Planning for Compliance

    First, your team must stitch together many different software tools that help with compliance. Second, you must run periodic scans on your infrastructure and security controls after you provision your resources which essentially place Band-Aids on top of the holes you’ve created. Instead, applying controls during the provisioning process places a secure foundation under your developers’ code.

    DevOps teams try to maintain control over infrastructure and application deployment processes to avoid any mistakes from developers. Suddenly, developing software in the cloud begins to look the same as developing on-premises—delays, disappointment and frustration.

    Three things lead to successful cloud compliance:

    1. Careful planning and execution
    2. Automation to provision the necessary controls while you build your infrastructure
    3. Ongoing maintenance to adapt to changing regulations and standards

    You can help developers unlock the power and agility of cloud development while remaining compliant. But you must enable self-service for them as much as possible while maintaining security and compliance. The only way is to give them control of doing things they want while hiding low-level details that can get them in trouble.

  • Datadog Unfurls Application Security Service

    Datadog Unfurls Application Security Service

    Datadog, Inc. today made generally available an Application Security Monitoring (ASM) service that is based on the same agent software that many DevOps teams already use to monitor applications.

    Pierre Betouin, vice president of product for the cloud security platform at Datadog, said ASM is designed to make it simpler for DevOps teams to add additional DevSecOps best practices to their existing workflows. The ASM service is based on a runtime application self-protection (RASP) engine and web application firewall that Datadog gained with the acquisition of Sqreen a year ago.

    ASM then employs distributed tracing to discover code-level vulnerabilities such as server-side-request forgeries (SSRFs), SQL injection and cross-site scripting (XSS) flaws. It is designed to extend an existing Datadog Cloud Security Platform that includes cloud security posture management (CSPM), cloud workload security (CWS) and cloud SIEM services.

    The overall goal is to make it simpler for DevOps teams to address application security by eliminating the need to deploy and maintain a separate set of agents within applications, said Betouin. That approach reduces resistance among DevOps teams that would otherwise be concerned about the additional overhead another approach to application security would add to an application environment, he added.

    The number of organizations looking to implement DevSecOps best practices is expected to increase in the weeks and months ahead in the wake of a series of high-profile breaches and zero-day vulnerability disclosures. Many organizations are now performing security reviews across their entire software supply chain as part of an effort to discover any malicious malware that might have been inserted into applications.

    The challenge those organizations face is that as application environments become more dynamic, maintaining application security becomes more difficult as code is continuously updated. The best way to address that engineering challenge is to extend the reach of an observability platform that many DevOps teams already have in place, noted Betouin. Ultimately, the goal is to automate application security as much as possible but that’s not going to be achievable if DevOps teams lack the context required, he added.

    It’s not clear at what rate organizations are embracing DevSecOps best practices. However, it’s clear that DevOps teams are being held more accountable for application security. Most developers are now charged with becoming application security experts overnight, so the only way to effectively ensure application security is to uncover security flaws before applications are deployed in production environments.

    There are, of course, multiple ways of achieving that goal. Datadog is betting that the path of least resistance is via a cloud service that connects to agent software inserted within those applications. DevOps teams have been inserting agent software, in one form or another, into those applications for years. The issue is that with each new agent added there is yet another software component that needs to be deployed and regularly updated. If not carefully tracked, a DevOps team could find itself attempting to manage an entire portfolio of agent software for every platform employed.

  • What Should Elon Musk Do? | Passwordless Future: Tense | WebKit iOS Monopoly Ends?

    What Should Elon Musk Do? | Passwordless Future: Tense | WebKit iOS Monopoly Ends?

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Everyone has Twitter advice for Elon, passwordless vision is vacuous, and Apple prevented from forcing Safari. (more…)

  • Report Finds Most Log4Shell Vulnerabilities Unpatched

    Report Finds Most Log4Shell Vulnerabilities Unpatched

    A report published today by Rezilion, a provider of a platform for tracking and analyzing software vulnerabilities, found that despite all the attention the Java zero-day Log4Shell vulnerability attracted, it appears that nearly 60% of the affected software packages remain unpatched.

    Rezilion used Google’s Open Source Insights tool to scan open source software packages, including dependencies, and found that out of a total of 17,840 affected Java software packages, only 7,140 have been patched.

    In addition, the Rezilion report cited a Log4j vulnerability resource center maintained by Sonatype indicated that 36% of the vulnerable versions of the Log4j Java log management tool that were actively downloaded from Maven Central are still vulnerable to Log4Shell.

    Rezilion also made use of dive, an open source tool for exploring Docker container images, to verify what version of Log4j might be present in containers, and Shodan.io, a search engine for discovering internet-connected devices.

    Yotam Perkal, director of vulnerability research for Rezelion, said that the results suggested that many organizations that have deployed a Java application have no way of knowing whether it includes the widely used open source Log4j tool for tracking logs within Java application. Many of the instances of that tool are subject to a recently discovered zero-day vulnerability that can be easily used to execute malicious code within a Java application.

    The challenge is that many organizations are using Java software components provided to them by a third party, and they assume that software is secure. However, that third party is often not aware of how that software may have been deployed, noted Perkal.

    More troubling still, many organizations that deploy software today don’t actively manage anything that might be considered a software supply chain, he added. Software is deployed as needed with little to no regard for provenance, said Perkal.

    Even when organizations can track software components, patching Log4j is a challenge. Java files can be nested layers deep into other files. Java applications can also be packaged in ways that make searching for vulnerabilities more difficult.

    Naturally, much of the responsibility for discovering instances of vulnerable Java applications falls to DevOps teams. As organizations embrace DevSecOps best practices that revolve around a software bill of materials (SBOM), it becomes easier to track vulnerable software packages. The issue is that most organizations either don’t have an SBOM or fail to update it as applications are upgraded. In the absence of an SBOM, many DevOps teams are still looking for instances of Log4jShell four months after the initial vulnerability was disclosed.

    Unfortunately, this latest vulnerability crisis doesn’t appear to be the wake-up call that drives more organizations to implement DevSecOps workflows, said Perkal. While some organizations are proactively patching applications, many others are still waiting on updates from a third party they hope will address the issue. Those updates, however, may not arrive in time to prevent cybercriminals that know about the Log4jShell vulnerability from wreaking havoc.

  • Defining the Next Cycle of Technology

    Defining the Next Cycle of Technology

    We’re in the middle of what we at ScyllaDB dubbed The Next Tech Cycle. Not “The World of Tomorrow” nor “The Shape of Things to Come” nor “The Wave of the Future”—because it’s already here today. We’re right in the middle of it. It’s a wave that’s carrying us forward, but it began with trends that got their start earlier this century.

    Everything is co-evolving, simultaneously, from the hardware you run on to the languages and operating systems you work with to the operating methodologies you use day-to-day. All of those familiar technologies and business models are themselves undergoing revolutionary change.

    This Next Tech Cycle Goes far Beyond “Big Data”

    We’re talking about huge data. Welcome to the Zettabyte Era. This era, depending on who is defining it and what it is measuring, either started in 2010 (if you’re measuring total data stored on earth) or in 2016 (if you’re measuring total internet protocol traffic in a year).

    Right now, individual data-intensive corporations are generating information at the rate of petabytes per day and storing exabytes in total. There are some prognosticators who believe we’ll see humanity, our computing systems and our IoT-enabled machinery generating half a zettabyte of data per day by 2025.

    Yet, conversely, we’re also seeing the importance of small data. Look at the genomics revolution.

    Because the RNA gene sequence of, say, COVID-19 is actually not that big, data-wise—you can store it in less than 100kb; less than an ancient floppy. But it is increasingly important to understand every single byte of that information because vaccinating against this global pandemic requires understanding every change of that rapidly-evolving pathogen.

    So, this next tech cycle has to scale everything from huge data and small data systems. And the database you will use and the data analytics you perform need to align with the volume, variety and velocity of the data you have under management.

    “Great! Now Make it All Multi-Cloud!”

    Also, this next tech cycle is not just the “cloud computing cycle.” AWS launched in 2006. Google Cloud was launched in 2008. And Microsoft Azure was formally launched in 2010. So, we’re already well over a decade past the dawn of the public cloud. Yet this next tech cycle definitely builds on the ecosystems, methodologies and technologies these hyperscalers provide.

    The database you use also has to align with where you need to deploy it. Does it only work in the cloud, or can it be deployed on-premises far behind your firewall? Does it just work with one cloud vendor or is it deployable to any of them? Or all of them simultaneously? These are important questions.

    Just as we do not want to be locked into old ways of thinking and doing, the industry does not want to be locked into any one technology provider.

    If you’ve just been mastering the art of running stateful distributed databases on a single cloud using Kubernetes, that’s not good enough. Now you’re being asked to do it all over again; this time in a hybrid or multi-cloud environment using Anthos, OpenShift, Tanzu, EKS Anywhere or Azure Arc.

    Computing Beyond Moore’s Law

    It’s also not the basic broadband or wireless internet revolutions. We’re a full two decades into both of those. Yet the advent of gigabit broadband and the new diverse range of 5G services—also capable of scaling to a gigabit—enable incredible new opportunities in real-time data streaming services, IoT and more.

    So how does your database work when you need to connect to systems far and near? How important are the limitations of the speed of light to your latencies? How well do you deal with data ingested from hundreds of millions of endpoints at gigabit-per-second scale?

    And finally, underpinning all of this are the raw capabilities of silicon, summed up by the transistor and core counts of current generation CPUs. We’ve already reached 64-core CPUs. The next generation(s) will double that, to the point where a single CPU will have more than 100 processors. Fill a rack-based high-performance computer with those and you can easily get into thousands of cores per server.

    And all of this is just traditional CPU-based computing. You also have GPU advancements that are powering the world of distributed ledger technologies like blockchain. Plus, all of this is happening concurrently as IBM plans to deliver a 1,000 qubit quantum computer in 2023 and Google plans to deliver a computer with one million qubits by 2029.

    This next tech cycle is powered by all of these fundamentally revolutionary capabilities. It’s what’s enabling real-time full streaming data from anyone to anywhere. And this is just the infrastructure.

    If you dive deeper into that infrastructure, you know that each of the hardware architecture bottleneck points is undergoing its own revolution.

    We’ve already seen CPU densities growing. Yet vanilla standalone CPUs themselves are also giving way to full systems on a chip (or SoCs).

    And while they’ve been used in high-performance computing in the past, expect to see commonly-available server systems with greater than 1,000 CPUs. These will be the workhorses —or, more specifically, the warhorses—of this next generation: Huge beasts capable of carrying mighty workloads.

    Memory, another classic bottleneck, is getting a huge boost from DDR5 today and DDR6 in just a few years. Densities are going up, so you can expect to see warhorse systems with a full terabyte of RAM. These and larger scales are going to be increasingly common—and, for businesses, increasingly affordable.

    Storage is also seeing its own revolution with the recently-approved NVMe base and transport specifications, which will enable much easier implementation of NVMe over fabrics.

    Now, software will have to play catch-up to these capabilities. Just as it took time for kernels and then applications inside of a vertically scaled box to be made async everywhere, shared-nothing, sharded-per-core, and NUMA-aware, this next tech cycle is going to require systems to adapt to whole new methodologies of getting the most from these new hardware capabilities. We will need to reconsider many foundational software assumptions.

    Evolving Methodologies: Agile and Beyond

    Speaking of methodologies, just look at these from the dawn of the millennium and onward. As an industry, we’ve moved from batch operations and monolithic upgrades performed with multi-hour windows of downtime on the weekend to a world of streaming data and continuous software delivery performed 24 × 7 × 365 with zero downtime ever.

    And by migrating to the cloud (and this always-on world) we’ve exposed ourselves and our organizations to a world of random chaos and security threats. We now have to operate fleets of servers autonomously and orchestrate them across on-premises, edge and multiple public cloud vendor environments.

    While Scrum has been around since the 1980s, and continuous integration since 1991, in this century, the twelve principles of the Agile Manifesto in 2001 altered the very philosophy—never mind the methodologies—underlying the way software is developed.

    The Agile Manifesto’s very first line talks about the highest priority being “to satisfy the customer through early and continuous delivery of valuable software.”

    However, the specific term continuous delivery (CD), as we know it today, didn’t take hold until 2009. It was then joined to continuous integration and coincided with the birth of what we now know as DevOps.

    With that, you had a framework for defining change-oriented processes and software life cycles through a responsive developer culture that now, a decade or two into this revolution, everyone takes as a given.

    This graph shows how continuous integration (CI) and continuous delivery (CD) evolved independently. They were eventually conjoined by the term CI/CD, whose popularity as a search term only began to rise around 2016 and did not displace the two separate terms until early in 2020. It is now increasingly rare to refer to CI or CD separately, according to Google Trends.

    Onto that baseline were built tools and systems and philosophies that extended those fundamental principles. The Chaos Monkeys of the world, as well as the pentesters, want to break your system—or break into them—to uncover flaws and defects long before something stochastic and catastrophic or someone maliciously does it for you.

    Cloud-native technologies like Kubernetes and single-source-of-truth for infrastructure methodologies like GitOps were created out of sheer necessity to scale systems to the hundreds of thousands of production software deployments under management.

    DevSecOps

    And that’s still not enough. We’ve already seen software supply chain attacks like SolarWinds, low-level system attacks like Spectre, Meltdown and Zombieload, or human-factor threats like viral deep fakes and millions of fictitious social media accounts using profile images generated by generative adversarial networks, never mind millions of IoT-enabled devices being nefariously harnessed for distributed denial-of-service (DDoS) botnet attacks. Just recently, news broke of the Log4j vulnerability—our best wishes to anyone who was patching code this past holiday season.

    These are all just the bowshocks of what’s still to come.

    So now, your AI-powered security systems are locked in combat every day in real-time against the threat actors attempting to undermine your normal operations. We know this because a growing number of intrusion prevention and malware analysis systems are built at terabyte-and-beyond scale using distributed databases as their underlying storage engines.

    Hence, these days, rather than just DevOps, increasingly we talk about DevSecOps—because security cannot be an afterthought. Not even for your MVP. Not in 2022.

    And these methodologies are continuing to evolve.

    Summary

    This next tech cycle is already upon us. We’re in the thick of it. You can feel it in the same way you’d yearn for major life or career change. Maybe it’s a programming language rebase. Is it time to rewrite some of your core code as Rust? Or maybe it’s in the way you are considering repatriating certain cloud workloads or extending your favorite cloud services on-premises such as through an AWS Outpost. Or maybe you’re actually looking to move data to the edge? Planning for a massive fan-out? Whatever this sea change means to you, you’ll need rock-solid infrastructure that’s available today to take workloads into production right now, but flexible enough to keep growing with your emerging, evolving requirements.

  • MDR for DevSecOps: How Managed Security Can Help You Shift Left

    MDR for DevSecOps: How Managed Security Can Help You Shift Left

    What is managed detection and response (MDR)? Managed detection and response (MDR) is an outsourced service that helps organizations detect threats on endpoints, respond to them and carry out proactive threat hunting.

    MDR services typically include an endpoint detection and response (EDR) platform, which is deployed on company endpoints, and human security experts. MDR providers give their customers access to security analysts and engineers who can help with endpoint security, network security management, triage of alerts and responding to real security incidents (here’s some further reading and more background on managed detection and response platforms).

    Why is MDR Important?

    Traditional managed security services (MSS) offer basic monitoring and alerting that do not provide the context and guidance needed to identify, respond to and remediate real security incidents. It leaves organizations exposed to many threats that pass through these basic services.

    How MDR Helps Protect Organizations

    MDR provides a proactive, outcome-driven approach that goes beyond the scope of what MSS vendors can offer. Common MDR services include:

    • Continuous network and endpoint monitoring.
    • Security orchestration.
    • Threat hunting.
    • Integrated response actions like remote threat containment.
    • Advanced MDR services also offer extended detection across clouds such as AWS, GCP, Azure and common SaaS suites like Google Workspace and Office 365. Other providers can protect incident command systems (ICS) and supervisory control and data acquisition (SCADA) systems within operational technology (OT) environments.

    What is DevSecOps?

    DevSecOps is a software development methodology that unifies previously disparate development (Dev), security (Sec), and operations (Ops) teams. It aims to integrate security across all development life cycle phases, including design, development, testing, deployment and delivery. It involves using automation to integrate security across all phases.

    In the past, security tasks were performed at the end of the development pipeline by a separate security team. Next, the product was tested by a quality assurance (QA) team. This approach worked when developers released software updates only once or twice per year. However, once software development teams adopted Agile and DevOps pipelines to reduce the development time, security became a bottleneck.

    How DevSecOps Improves Security

    DevSecOps integrates security into Agile and DevOps pipelines. It ensures teams can address security issues during the early phases of the development cycle. As a result, teams can apply fixes when it is easier and faster to remediate before products are released to production.

    DevSecOps makes security a responsibility shared by all teams, including Dev, Sec and Ops. It is no longer the sole responsibility of one team that creates a security silo. Instead, it enables teams to automate secure software delivery, prioritizing security without slowing down the software development cycle.

    How Managed Detection and Response (MDR) Solutions Benefit DevSecOps

    DevOps has revolutionized application development. However, due to the high velocity of modern development methods, they can introduce security gaps and flaws.

    In addition to regular security breaches occurring across the DevOps pipeline, new and sophisticated attacks, most significantly supply chain attacks infect the development systems themselves or third-party software components. This results in mega-attacks that can compromise millions of devices before being detected.

    How can MDR help?

    MDR is a relatively new cybersecurity offering but is beginning to have a major impact on companies seeking better protection with lower operational overhead. There are many overalls between MDR and DevOps. To integrate cybersecurity into production and deployment pipelines, some organizations are turning to a DevSecOps approach and MDR can help.

    DevSecOps makes cybersecurity an integral part of the entire DevOps life cycle. As more organizations implement DevSecOps, they can supplement the knowledge and security best practices of in-house teams with the security expertise provided by MDR services.

    How MDR Keeps DevOps Ahead

    MDR keeps DevOps teams ahead of the latest threats by keeping developers up-to-date on emerging threats and vulnerabilities and providing advanced tools for continuous security monitoring and response in their development and deployment pipelines. A key benefit of MDR is that it provides access to experts who can take action to prevent attacks, not just provide recommendations.

    MDR becomes a supporting element that allows developers to write more secure code as well as better secure their DevOps environment. With the help of MDR technology and experts, it becomes easier to identify advanced threats that can bypass security controls before they impact the DevOps environment or the resulting software product.

    Considerations for Selecting an MDR Solution

    • There are several important considerations when choosing an MDR platform suitable for a DevOps environment:
    • Understanding of attack surfaces common in a DevSecOps environment, and the ability to monitor and control the relevant environments.
    • Measures are taken to eliminate false positives and prioritize alerts. DevOps teams operate at high velocity and do not have time to wade through irrelevant alerts.
    • Automated triage and response at all stages of the development lifecycle. In earlier stages, this should take the form of actionable recommendations for developers, and in later stages, full incident response for production environments.

    All of this is useful as you find the right way to shift your organization to a true DevSecOps process.