devopsy.kinsta.cloud

Tag: devsecops

  • Securing the DevOps Pipeline: Tools and Best Practices

    Securing the DevOps Pipeline: Tools and Best Practices

    The DevOps pipeline refers to the set of practices and tools designed to automate and integrate the processes between software development (Dev) and IT operations (Ops) teams. This pipeline facilitates continuous integration (CI), continuous delivery (CD) and rapid deployment practices, aiming to shorten the development life cycle and provide continuous delivery with high software quality. 

    The DevOps pipeline typically includes planning, coding, building, testing, releasing, deploying, operating and monitoring, enabling teams to develop and deploy software more efficiently and with fewer errors.

    By automating workflows and integrating various development and operational activities, the pipeline supports the rapid iteration of software releases. This not only accelerates the pace of software development but also ensures that quality and performance standards are met throughout the application’s life cycle.

    Due to the critical nature of the DevOps pipeline, security is becoming a top priority. Some of the most devastating cyberattacks in recent years were related to breaches in DevOps pipelines, which led to global-scale supply chain attacks.

    The Need for Security in DevOps

    DevOps, by its very nature, encourages speed and efficiency. However, this drive for rapid software development and deployment can sometimes overlook the critical aspect of security. That’s why it’s essential to weave security into the fabric of the DevOps pipeline, an approach known as DevSecOps. By doing so, we can ensure that security isn’t an afterthought but an integral part of the development process.

    Incorporating security into the DevOps pipeline offers multiple benefits. First, it helps identify and rectify security vulnerabilities early in the development process, reducing the risk of security breaches. It also fosters a culture of shared responsibility, where the development, operations and security teams work together toward the common goal of creating secure software.

    Tools for Securing the DevOps Pipeline

    Securing the DevOps pipeline requires a set of tools that align with the DevOps philosophy of automation and continuous improvement. Let’s explore some of these tools.

    Static Application Security Testing (SAST)

    SAST, also known as white-box testing, is a tool that helps locate security vulnerabilities in the codebase without executing the application. It makes it possible to identify issues early in the development process, even before the code is run.

    SAST works by analyzing the source code, bytecode or binary code, looking for patterns that might indicate a security flaw. The strength of SAST lies in its ability to pinpoint the exact location of the security vulnerability in the codebase. This makes it easier to fix the issue, thus saving time and resources.

    Dynamic Application Security Testing (DAST)

    DAST, a type of black-box testing, involves testing the application in its running state. It’s designed to find security vulnerabilities that can’t be spotted during static analysis.

    DAST works by simulating attacks on the application and observing its response. It can identify security issues like cross-site scripting (XSS), SQL injection and security misconfigurations. The beauty of DAST is that it views the application from an attacker’s perspective, thus providing a real-world assessment of its security. However, DAST can’t identify vulnerabilities in the source code and relies on the application being in its running state for testing.

    Software Composition Analysis (SCA)

    Software composition analysis (SCA) is designed to provide visibility into the open source components used in the software. It helps identify any security vulnerabilities, licensing issues or outdated libraries in the open source components.

    SCA works by creating a bill of materials (BOM) that lists all the open source components used in the software. It then compares this list against various databases that track open source vulnerabilities. If a match is found, SCA flags the component, allowing the developers to take necessary actions.

    Endpoint Detection and Response (EDR)

    Endpoint detection and response (EDR) is a cybersecurity technology that addresses the need for continuous monitoring and response to advanced threats. EDR tools continuously monitor endpoint and network events and record the information in a central database where further analysis, detection, investigation, reporting, and alerting take place.

    EDR is like a surveillance system for your DevOps pipeline. It keeps an eye on endpoint activity, and if it detects a potential threat, it alerts developers and security staff. EDR is not just about detection; it also provides tools for responding to security incidents. It helps isolate affected systems, block malicious activities and even roll back systems to their pre-attack state.

    Container Security Tools

    In a DevOps environment that increasingly relies on containerization, container security cannot be overlooked. Container security tools provide a means to enforce security policies and protect containerized applications.

    These tools offer functionalities like image scanning, runtime protection and network segmentation. Image scanning helps identify vulnerabilities in the container images. Runtime protection monitors the container’s activities in real-time, looking for any signs of compromise. Network segmentation allows for isolating containerized applications, thus limiting the blast radius in case of a security incident.

    Best Practices for Securing the DevOps Pipeline

    Integrate Security Early (Shift Left)

    The concept of ‘shifting left’ in DevOps refers to integrating security measures early in the development process. Instead of treating security as an afterthought, it becomes a part of the software development life cycle from the get-go.

    Implementing security early allows us to identify and address potential vulnerabilities before they become a significant issue. It saves us time and resources by preventing security breaches instead of responding to them. Besides, it fosters a proactive approach to security, emphasizing prevention over remediation.

    SAST and DAST are useful in integrating security early. SAST tools analyze code in its static state to identify vulnerabilities, while DAST tools test applications in their running state to detect security flaws.

    Automate Security Processes

    Automated security scans can be incorporated into the continuous integration/continuous delivery (CI/CD) pipeline. Each time a code push occurs, these scans are triggered, allowing for immediate feedback on potential security issues. Automated scans can detect a broad range of vulnerabilities, from code defects to configuration errors.

    Configuration management tools like Chef, Puppet, Ansible and Terraform can help manage configurations and enforce security policies. They ensure that all systems are configured correctly and consistently, reducing the risk associated with manual configuration.

    Regular Security Audits and Compliance Checks

    Regular security audits and compliance checks are essential in securing the DevOps pipeline. They provide an opportunity to review and update security measures, ensuring they are effective and up-to-date.

    Security audits should be comprehensive, covering all aspects of the DevOps pipeline. They should evaluate security controls, identify potential vulnerabilities, and recommend remedial measures. Compliance checks ensure that security practices align with relevant regulations and standards.

    In conclusion, securing the DevOps pipeline requires a holistic approach that integrates security into every aspect of the development process. It involves shifting security left, automating security processes, conducting regular audits and compliance checks and fostering a culture of collaboration.

  • Why DevOps is Key to Software Supply Chain Security

    Why DevOps is Key to Software Supply Chain Security

    DevOps is designed to increase business value and responsiveness through rapid, high-quality service delivery, made possible through fast-paced, iterative IT service delivery. The term DevSecOps emerged as a way to remind us that security was always intended to be part of the software delivery process. However, with the barrage of attacks on the software supply chain showing no signs of abating, the question now is whether even the tightest DevOps pipelines can maintain the pace-protection balance.

    It’s important to note that the term “software supply chain” has been used primarily to refer to the tools and processes used to build and deploy software applications. Now, however, with the rise of infrastructure-as-code (IaC), the term also refers to tools and processes used to build and deploy IT infrastructure.

    Meet Mandates, Reduce Risk

    Software supply chain attacks such as SUNBURST, HTTP/2 Rapid Reset or the breaches associated with the MOVEit vulnerability have fed news cycles for the last few years, and that likely won’t change anytime soon. Attacks on the software supply chain increased 742% since 2020. What we are seeing as a result are new concerns about supply chain security and DevOps requirements. This has led to confusion and often a mish-mash of tooling that may exacerbate rather than mitigate supply chain security issues.

    Arguably the most impactful salvo over the software supply chain security line was president Biden’s 2021 Executive Order 14028, which established new mandates, including the delivery of SBOMs, as minimum requirements for software used by the U.S. federal government. More recently, the FDA has mandated that “all medical devices running software must create and maintain” SBOMs. I expect to see government and industry requirements increase over time.

    These are just a couple of relatively recent examples. There are many more—and no doubt many more to come.

    So, if you’re moving at the speed of DevOps, how do you address these current and future mandates for software supply chain security, as well as the continually emerging vulnerabilities and attacks? I would venture to say that only by moving at the speed of DevOps—and within the parameters of the DevOps model—can organizations not only meet mandates but also effectively reduce risk for the business.

    Indeed, it’s not a matter of whether DevOps is viable within the current security climate but what requirements need to be added to support and enhance current DevOps work.

    New Guidelines, New Processes, New Tools and New Data

    In response to these new threats and regulations, the software community has been working on developing and updating guidelines to help organizations improve the security of their supply chains—for example, SLSA, NCSC UK supply chain security guidance and NIST cybersecurity supply chain risk management. However, these new guidelines can be complicated and require new processes and new tools.

    Before adding any new tooling or changing any processes, it’s critical to examine existing tools to determine whether and to what extent they satisfy supply chain security mandates. Organizations must also evaluate how well existing processes work to protect the business, then strategically add/subtract from there as needed.

    No matter what solutions are leveraged, more and different tools generate reams of more and different data. What’s important — and to whom? How do I manage the data? When can I trust it? Where do I store it? What problems does the new data help me solve? Organizations will need a way to effectively sift this information and deliver the right data to the right teams at the right time. To preserve the ability to quickly and continuously innovate, it will be important to focus on shifting security left as well as integrating automation whenever and wherever possible.

    As new security metadata becomes available, such as from SBOMs, new solutions for managing that metadata will be key. An open source initiative sponsored by Google, GUAC is designed to integrate software security information, including SBOMs, attestations and vulnerability data. Users can query the resulting GUAC graph to help answer key security concerns, including proactive, preventive and reactive concerns.

    Continue to Shift Security Left

    Another way that organizations can maintain their DevOps momentum while protecting the software supply chain is to continue to invest in shifting security left in the software supply chain. The software community has been talking about this for some time, but many organizations struggle to implement impactful changes. Security teams must work to understand how software is built and collaborate with development and DevOps teams to ensure that improvements are made to both application and infrastructure-as-code supply chains.

    We need to go beyond shift-left vulnerability analysis to ensure that we are evaluating the quality of configuration-as-code (for both applications and infrastructure), that we are taking advantage of new recommendations, and that we are leveraging new attestation solutions designed to work with pipelines such as sigstore and Tekton Chains. After all, the sooner an issue is discovered, the more quickly it can be addressed and the less disruptive and costly it is to fix it.

    No One-Size-Fits-All Solution

    While all of these solutions mentioned here are helpful, there is no single product or framework that will enable organizations to maintain the security-innovation balance. Success, rather, will require a focus on agility, flexibility and effective communication and collaboration—the very hallmarks of the DevOps model.

    Rather than being obviated by the demands of software supply chain security, DevOps provides the opportunity to integrate the kinds of protections that can prevent or mitigate supply chain vulnerabilities and breaches. DevOps also enables organizations to quickly and effectively respond to new threats and new requirements.

    With that said, there’s no doubt that organizations will need to think differently about how they manage software security, including the strategic evaluation and integration of tools that will meet current and future regulatory mandates and, more importantly, protect the business over time. Organizations may also need to think about weighing security over speed, at least until all of the pieces of the software supply chain protection puzzle are in place—but also when future circumstances warrant a fresh look at how to best balance the DevOps pace-protection balance.

  • Squaring the Circle: How to Make Public APIs Private

    Squaring the Circle: How to Make Public APIs Private

    APIs have become an integral part of enabling seamless data exchange and functionality between systems and businesses. In fact, APIs are trebling every year. Public APIs are, by their nature, designed to be open and discoverable. By definition, this also means that APIs are open to attacks from the networks. This is why APIs have become the number one attack vector.

    APIs becoming the top attack vector makes sense. All our other business apps are hidden behind private networks–usually MPLS (AWS Direct Connect, Azure ExpressRoute, etc.), VPN or zero-trust network access (ZTNA). But APIs are exposed to the public Internet.

    Day 2 API Security Solutions and Snowflakes

    This network exposure is why there are so many ‘Day 2′ API security solutions – WAFs, API security platforms, IDS, etc. These solutions do a great job of blocking threats that have already been identified, yet there are successful API attacks each day. Why?

    Each API is unique and evolves rapidly–constant changes in business logic, authentication, authorization and configurations. APIs are snowflakes. The result is that many API attacks are effectively zero-day attacks–novel attacks that exploit recent and unique changes to specific APIs.

    A Difficult Race to Win

    Network exposure and snowflake characteristics are why API-related vulnerabilities multiply each day.

    The ‘snowflake’ issue means many attacks are unknown to the Day 2 solutions – they attack vulnerabilities that didn’t previously exist. So, after the novel attack, we race to apply a fix. Who are we racing against? Every attacker on the internet. The API is public–exposed to the networks–not like our other business apps, which are private behind an MPLS, VPN or zero-trust solution. Racing against attackers on the internet is difficult–and coming second may result in a service outage, data breach or customer compromise.

    Why Not Avoid the Race?

    So why not make the APIs private, avoid exposing them to the internet, put them behind MPLS, VPN or ZTNA, like we do for all our other business apps? API clients are too distributed and dynamic; there is no good way to manage agents or dedicated circuits across all those API clients. Those solutions were not made for APIs–it is like fitting a square peg in a round hole.

    Zero-Trust API Networking Needs to be Built for APIs

    To make our APIs private like the rest of our business apps, we must first meet the business need. API providers need to achieve the business velocity and agility they require. On the technical side, we need a secure networking solution which is built to manage the distribution of the API clients, and assume that there will always be snowflake-like vulnerabilities.

    Let’s look at an open source solution for zero trust APIs which is purpose-built for those business, technical and operational requirements:

    There are usually three reactions to the diagram above:

    1. OK, tell me how it works. See below.
    2. Looks complex. Nope. All software, spun up in minutes, centrally managed.
    3. Seems like a proprietary solution for users accessing their applications. Yes! It uses principles similar to the user-to-app zero-trust world but secures APIs.

    How Zero-Trust API Networking Works

    Here are the four pillars of zero-trust API networking:

    1. Eliminate public access. Your API clients will use private IPs or domains to reach your APIs. If your company name is Acme, then your clients might now use api7.acme.unreachable (you make up any domain you want). Envision an attacker trying to interrogate *.acme.unreachable to find snowflake vulnerabilities. Not possible because it is not a public domain—your API server is no longer reachable.
    2. Identity, authentication, authorization, mutual TLS. Authorized API clients do need to access your APIs from the internet. Your zero-trust API overlay network is accessed from the internet only with X.509-certificate cryptographically authenticated identities, continuous authentication and least privileged access authorization via mTLS links. You move the policy enforcement point (PEP) from your DMZ to your API clients. Your API clients add a few lines of zero-trust networking code to enable this model. This code replaces VPNs, MPLS, etc. (there are non-code options too). For example, some of your API clients likely use Resty, a popular open source REST client library for Golang. Their existing Resty code adds a few lines of zero-trust API networking code: 
    3. Outbound-only. You eliminated the inbound access. Your server will instead open identified, authenticated and authorized sockets to your zero-trust API overlay network (you’ll close all your inbound ports and only enable outbound ports to specific overlay network router IPs or to your x.acme.unreachable domain).
    4. Management. API networking security is not very valuable without simple management. The zero-trust API overlay cloud is software-only and cloud-native. You spin up your private API clouds in minutes, anywhere, without deploying hardware. If an API client is compromised, one click or automated action removes its access. Network usage for each client/API is in your web console or management dashboard.

    The above is based on the open source OpenZiti zero-trust networking platform, but any zero-trust API platform should provide similar functionality. Specifically, it should enable:

    • Speed. Securing APIs but slowing down business or complicating operations is not the trade-off most organizations want. Security and speed is the goal.
    • Minimize the threat surface. Close all inbound ports in front of your API servers. Use private, unreachable addresses or domains to minimize your attack surface and stop racing against network-based attackers.
    • Extensibility. Software-only, cloud-native architectures. Preferably open source based.
    • Operations excellence. Centralized visibility, controls, policies and identities. Rich telemetry data. Performance-optimized overlay networks.
    • Zero-trust security. Identity-based networking, continuous authentication, strong authorization, mutual TLS (mTLS), encrypted delivery, microsegmentation.
    • Flexibility. API clients add a few lines of code to get zero-trust API networking. Other API clients use API-specific agents or DNS to access the overlay, if desired, while your API server/gateway is still private.
    • Recovery. Assume breaches. Implement microsegmentation, prevent data exfiltration and provide simple controls to immediately remove threats.

    Zero-Trust API Networking

    While APIs will always be snowflakes, they no longer need to be our only business app that is exposed to the networks. By minimizing the attack surface, without compromising business velocity and API client experience, we can finally mitigate against our greatest API security risk. This also simplifies our day two API security, the solutions that inspect API queries after they enter our DMZ.

    Rather than trying to filter the internet, day two solutions can focus on detecting authorized API clients that may have been compromised. Similarly, our operations teams are freed to focus on sessions from authorized API clients rather than wading through oceans of data from port scanning, DDoS attacks, unauthorized API queries and attempts to interrogate public APIs to find new snowflake vulnerabilities.

  • Legit Security Adds Sensors to Detect Usage of Gen AI Tools to Write Code

    Legit Security Adds Sensors to Detect Usage of Gen AI Tools to Write Code

    Legit Security today announced it has added the ability to detect when developers use generative artificial intelligence (AI) tools to write code to its application security posture management (ASPM) platform.

    The ASPM platform developed by Legit Security already has discovery capabilities for application secrets, for example, enabled by sensors that are now being extended to include generative AI tools.

    Legit Security CTO Liav Caspi said the overall goal is to allow DevSecOps teams to identify who uses these tools to write which types of code. Each DevSecOps team can then decide how stringently to enforce policies to either ban or limit usage of those tools, he added.

    There is no doubt that generative AI tools are increasing developer productivity, but the large language models (LLMs) that provide the ability to generate code were trained using examples of code of varying quality collected from across the web. Much of that code either contains known vulnerabilities or is simply inefficient, which can manifest itself in the output surfaced by a generative AI platform.

    The Legit Security ASPM platform, in addition to identifying generative AI tools being used in real-time, can also be employed to scan the LLM itself to identify security risks such as prompt injection and insecure output handling. Unfortunately, most cybersecurity teams are unaware of the extent to which application code generated by a machine might be insecure, so it currently falls to leaders of DevSecOps teams to determine what is an acceptable use of these tools. It may be perfectly fine to rely on a generative AI tool to create a script that will be used for an internal-facing application. However, using the same tool to write business logic that will be exposed to the internet may not be especially prudent.

    It’s not clear how much of the code finding its way into software builds is being generated by a machine versus a human. In the longer term, the goal is to be able to identify that code by, for example, detecting substantial changes in the way code is normally written by a human developer, said Caspi.

    Of course, while an ASPM may detect usage of generative AI tools that are connected to a corporate environment, there are still plenty of opportunities for developers to use these tools offline to create code that can later be added to a build using a code check-in tool. After all, many developers have used various shadow IT tools to write code for decades. Regardless of who or what wrote that code, however, it should still be reviewed.

    In the meantime, the overall size of the codebase that DevSecOps teams will need to manage and secure will only exponentially increase as developers become more productive. Hopefully, more AI capabilities will soon be embedded into DevOps platforms to further automate the management of software builds at a time when many DevOps teams were already finding themselves overwhelmed even prior to the rise of generative AI.

  • Survey: Cyberattacks Aimed at Software Supply Chains are Pervasive

    Survey: Cyberattacks Aimed at Software Supply Chains are Pervasive

    A survey published today finds 91% of respondents work for organizations that have experienced a software supply chain incident in the past 12 months.

    The survey polled 368 IT, cybersecurity and application developer professionals responsible for application security in North America and was conducted by the research firm Enterprise Strategy Group (ESG) on behalf of Data Theorem, a provider of an application security platform. The survey found zero-day exploits of vulnerabilities within third-party code (41%) were the most common attack vector, followed closely by misconfigured cloud services (40%), vulnerabilities in open-source software and container images (40%), stolen secrets/token/passwords (37%) and breaches of application programming interfaces (APIs) (35%).

    The biggest areas of impact of those breaches are identified as cryptojacking (43%), inability to meet service level agreements (41%), malware infestation (39%), unauthorized access (39%), stolen developer credentials (37%), data loss (37%) and the levying of fines (37%).

    Despite these issues, however, nearly three-quarters (74%) of respondents claimed their organization has “robust” software supply chain security capabilities even though a similar percentage said they are making significant investments in software supply chain security, with an additional 25% making moderate investments. More than three-quarters (77%) said they have increased their effort to secure third-party software components and container images in the wake of an attack. The top two areas of focus are new detection rules/analytics (33%) and the adoption of multifactor authentication (MFA) (33%).

    Top investment priorities over the next 12 to 18 months include scanning open source code components and third-party libraries for vulnerabilities (44%), followed by discovering and inspecting APIs in source code (39%), using composition analysis tools to create software bill of materials (SBOMs) (38%) and applying runtime API security controls (33%).

    The most widely used tools today are automated open source package risk management (34%), static application security testing (SAST) tools (34%), vulnerability scanning of cloud services (32%), automated security as code policy enforcement (31%) and dynamic application security testing (DAST) tools (31%).

    Data Theorem COO Doug Dooley said while the survey makes it clear progress is being made, there is still a lack of urgency. It may require additional high-profile breaches to create a large enough public outcry to pass the legislation that is going to be required to address software supply chain security issues more vigorously. In fact, 83% of respondents noted industry regulations are a key driver to ensure they create accurate SBOMs.

    In general, the survey finds nearly two-thirds of respondents (65%) have more than 50 Git repositories, with 40% reporting that more than half of their code is composed of third-party software. Half of respondents (50%) said they expected that to rise to more than half in the next 12 months. Well over half (58%) noted more than 30% of their code would be of open source software.

    Only 43% report they are completely confident that their developers are only using secure open source software. On the plus side, 90% are prioritizing efforts to shift security left to developers.

    Overall, 86% said it’s critical or important to know the composition/inventory of application code in use, where code is stored, and who has access to code components connected to their code. A total of 88% also noted it’s critical or important to have accurate inventory of their third-party APIs and cloud services.

    The one thing that is certain in the months ahead is that cybercriminals will put software supply chain security to the test. The challenge and the opportunity now, regardless of what regulations are ultimately passed, is to thwart those attacks before the damage inflicted ultimately forces lawmakers to act in ways that make software development a lot more difficult than it already is.

  • OpenText Extends Tool for Auditing Source Code Using Machine Learning

    OpenText Extends Tool for Auditing Source Code Using Machine Learning

    OpenText this week updated a static analysis tool it provides to audit code using machine learning algorithms to provide deeper insights into on-premises IT environments.

    Announced at the OpenText Security Summit 2024 conference, the latest generation of Fortify Audit provides additional artificial intelligence (AI) models capable of learning the unique attributes of custom source code.

    The latest version of Fortify Audit Assistant also adds the ability to detect drift in a model and, if necessary, automatically refresh it. OpenText is now committing to refreshing those models every quarter.

    The discriminant AI model from OpenText enables machine learning algorithms to learn how humans conducted an application audit to then run similar tests on other applications. Previously, Fortify Audit relied on the same core model to audit both on-premises and software-as-a-service (SaaS) applications based on data collected by OpenText. Fortify Audit Assistant now provides support for more than 30 language-specific models to improve testing performance.

    Dylan Thomas, senior director for Fortify engineering and product for OpenText Cybersecurity, said this capability ensures that any sensitive data never leaves an on-premises IT environment.

    The overall goal is to streamline the number of alerts that would otherwise overwhelm a DevSecOps team trying to identify the root cause of an issue, he added. For example, Fortify Audit Assistant will identify test code that is not vulnerable because it was never deployed in an actual production environment. That approach makes it easier for DevOps teams to prioritize which vulnerabilities to fix first in their source code using a lightweight AI model that still enables them to deeply scan source code, noted Thomas.

    Historically, DevSecOps teams need to make a trade-off between lightweight approaches and deep scans of source code that is no longer required, he added.

    As regulations pertaining to software supply chain security become more stringent the number of development teams that will be subject to some type of audit is only going to increase. The cost of failing an audit will also inevitably increase as regulatory bodies look to make examples of organizations that are not properly securing their software supply chains.

    It’s not clear how aggressively organizations are embracing best DevSecOps practices to address myriad software supply chain security issues that were highlighted in an executive order issued by the Biden administration to Federal agencies. However, with the rise of AI and other forms of automation, it should become simpler to identify more vulnerabilities before they wind up being exploited in a production environment.

    There will always, of course, be a need to secure production environments because there’s always a probability mistakes will be made. However, given the lax practices many organizations have employed to build and deploy applications, it’s probable the number of vulnerabilities that exist in production environments today is beyond counting. In many cases, the better part of valor might be to replace many of those applications entirely with ones built using DevSecOps best practices.

    Regardless of the path to better application security chose the one thing that is certain is cybercriminals are only going to become even more adept at discovering those vulnerabilities.

  • Salesforce Adds Ability to Apply Custom Security Policies to APIs

    Salesforce Adds Ability to Apply Custom Security Policies to APIs

    Salesforce today added the ability to customize security policies for application programming interfaces (APIs) to the Mulesoft Anypoint API management platform.

    Gerry Egan, vice president of product management for Mulesoft at Salesforce, said this capability makes it possible for organizations to use an Anypoint Flex Gateway Policy Development Kit to streamline development of custom API security policies that can be implemented as code.

    In addition to providing integrations with integrated development environments (IDEs), the Anypoint Flex Gateway Policy Development Kit also provides test policies that can be employed to ensure API security.

    That approach makes it simpler to ensure APIs are secure as they are being built and deployed within the context of an automated DevOps workflow versus having to rely entirely on a separate API security platform, he noted.

    The Mulesoft Anypoint Gateway already comes with security policies that DevSecOps teams can readily implement. Salesforce is now adding the ability to apply custom policies that DevOps teams can apply as it becomes apparent cyberattacks against APIs are becoming more sophisticated, noted Egan. Those policies can, for example, be used to remove sensitive data or replace it with a token, he added.

    Responsibility for API security is often not well established in many organizations, but as more accountability for API security shifts left toward DevSecOps teams, there is growing interest in addressing the issue as code when APIs are developed and deployed. While cybersecurity teams are responsible for maintaining cybersecurity after APIs are deployed, few of them have any insight into how an API is crafted. That’s a significant issue because cybercriminals have become more adept at both exfiltrating data via external facing APIs in addition to manipulating the underlying business logic to compromise a digital process, noted Egan.

    The Mulesoft Anypoint Gateway automates the process of building and applying security policies to APIs as part of the software development life cycle (SDLC) in a way that minimizes any impact on developer productivity, he added. That approach provides the added benefit of reducing the level of cognitive load developers would otherwise experience if they had to manually create software policies, said Egan.

    In general, most APIs are internally facing, but it’s not uncommon for them to suddenly be exposed to the internet as application use cases evolve. The best way to ensure API security is at the point of creation. Providing developers with API security tools gives them an opportunity to address security issues at the beginning of the application development process.

    There have already been several cybersecurity breaches involving APIs in the past year. It may only be a matter of time before there are additional breaches that could prove catastrophic. Regardless of the size of the API breach, the application development team that created and deployed the API in the first place is ultimately going to be held accountable for fixing it. The challenge is to find the simplest way to eliminate the issue in the first place at a time when the number of APIs being built and deployed only continues to explode.

  • Graylog Makes Free API Security Tool Available to Developers

    Graylog Makes Free API Security Tool Available to Developers

    Graylog this week made available a free version of its platform for securing application programming interfaces (APIs), intended to encourage developers to adopt best practices to secure them.

    The free version of Graylog API Security has all the capabilities of the paid version but is limited to 16GB of local rolling storage on a single node with a one-year renewable license.

    Graylog CEO Andy Grolnick said the goal is to make it simple for developers to use this edition of the platform as they are building APIs. As applications are deployed in a production environment, the expectation is organizations will then need to access the version of the platform that is designed to scale, he added.

    Based on technology Graylog gained with the acquisition of an API security platform originally developed by Resurface.io, this free version of Graylog’s API security platform is trying to help bridge the divide between the application development teams that create APIs and the cybersecurity teams tasked with protecting them, said Grolnick.

    Capabilities of the platform include API classification, discovery, risk scoring, an ability to capture API request and response payloads and continuous monitoring of API and threat signatures in real-time. Collectively, these capabilities enable Graylog API Security to provide high-fidelity alerts using a data lake that is embedded in the platform, noted Grolnick.

    That approach enables Graylog API Security to capture all API requests and response details to distinguish valid API traffic from malicious activity involving, for example, data exfiltration hiding under valid response codes.

    In addition, Graylog API Security automatically surfaces remediation guidance for developers who typically lack cybersecurity expertise.

    API security has become a major DevSecOps issue because cybercriminals are increasingly targeting APIs to steal data. As more externally facing APIs are deployed, the overall size of the attack surface that needs to be defended increases exponentially.

    A recent survey conducted by Enterprise Strategy Group (ESG) on behalf of Graylog found more than three-quarters of respondents (76%) have an average of 26 APIs per application. Most respondents are using open APIs for public consumption (67%) or are connecting applications with partners (64%).

    In general, most of those APIs are internally facing, but it’s not uncommon for those APIs to suddenly be exposed to the internet as use cases for applications evolve. The challenge is that few cybersecurity teams have visibility into APIs that, when manipulated by malicious actors, can expose code or provide a mechanism through which business processes can be compromised. This issue often exists because, in many organizations, it’s still not clear who is actually responsible for API security.

    Arguably, the best way to ensure API security is at the point of creation. Providing developers with API security tools gives them a chance to do the right thing from the beginning of the application development process, said Grolnick.

    There have already been several cybersecurity breaches involving APIs in the past year. It may only be a matter of time before there are additional breaches that could prove catastrophic. Regardless of the size of the API breach, the application development team that created and deployed the API in the first place is ultimately going to be held accountable for fixing it.