devopsy.kinsta.cloud

Category: IT Security

  • Synopsys Report Sees Steady Application Security Gains

    Synopsys Report Sees Steady Application Security Gains

    An analysis of the security automation practices of 130 organizations published today by Synopsys suggests significant progress has been made toward securing software supply chains in the last year. However, much work still remains to be done.

    The annual Building Security In Maturity Model (BSIMM) report found there has been a 22% increase in the number of organizations creating software bills of materials (SBOMs) this year. Additionally, there has been a 10% increase in the number of organizations tracking open source software risks.

    At the same time, there has been a 25% increase in the number of organizations that are fixing all defects found in software and a 15% increase in the number of organizations that can identify potential attackers and track attack patterns.

    The report also sees significant gains in activities related to software development practices (44%), penetration testing (35%) and compliance and policy controls (21%). Usage of application behavior monitoring and diagnostics grew 64% and monitoring automated asset creation grew 45%, respectively.

    The finding and publishing of secure design patterns, the required use of approved security features and frameworks and the use of application containers to support security goals all grew about 25%, according to the report.

    However, the report also noted that usage of possible attack lists dropped by 31%, while expert-driven tasks such as building and applying adversarial security tests declined 25% and use of centralized defect reporting dropped 18%.

    The most widely used processes are implementing security checkpoints and associated governance (91%), creating or interfacing with incident response (90%), identifying privacy obligations (88%), using external penetration testers to find problems (88%), ensuring host and network security basics are in place (87%) and automated code review tools (86%).

    Jamie Boote, associate principal security consultant for the Synopsys Software Integrity Group, said the report suggests more responsibility for cybersecurity is shifting everywhere as organizations rely more on automation to apply security controls. Application development and IT operations are, as a result, able to address vulnerabilities more proactively either before an application is deployed or as soon as a vulnerability is discovered, he noted.

    The challenge organizations will encounter when it comes to automating security processes is there is a tendency to set and forget. Once a process becomes automated, not enough organizations will reevaluate that process as the cybersecurity threat landscape continues to evolve, noted Boote.

    Of course, the rate at which security processes are being automated varies widely from one organization to the next, but the more automated they become, the less dependent organizations become on application developers who typically don’t have a lot cybersecurity expertise. All too often, application developers are rushing to meet software delivery deadlines at the expense of security best practices. Unfortunately, it’s usually only a matter of time before an issue that was avoided is later discovered in a production environment and is considerably more problematic to update, given all the dependencies between software and infrastructure that exist.

    One way or another, however, a pending wave of regulations will soon force organizations to pay more attention to securing software supply chains. The only thing left to determine in the absence of automation is how painful the reengineering of DevOps workflows to embrace DevSecOps best practices is going to be.

  • How Encryption Innovation Will Power Cloud Privacy for Developers in 2024

    How Encryption Innovation Will Power Cloud Privacy for Developers in 2024

    For developers, the surge in cloud computing adoption has brought both new opportunities and challenges. On the one hand, developers are turning to cloud services for data storage, processing and accessibility due to their flexibility, convenience and cost-effectiveness. And because the cloud takes care of these infrastructure and operational concerns, it’s allowing developers to focus on coding, innovation and delivering value to end-users. It also allows companies to scale more easily when their market grows or when new hardware becomes available.

    However, this paradigm shift has led to the accumulation of vast volumes of sensitive data on remote cloud servers—including personal, health, financial and proprietary business information. As the volume of sensitive data on the cloud continues to grow, it has naturally raised mounting security concerns, from data breaches and cyberattacks, to unauthorised access and the complexities in complying with specific industry regulations, such as GDPR or CCPA.

    For some, having to rely on the cloud provider to maintain robust security practices and data protection has also led to hesitancy in sharing data, both within and between organizations. This not only limits the potential for data-driven collaboration, research, and innovation—essentially halting progress in fields like health care, science, and social sciences—but businesses of all types and sizes could miss opportunities for cost savings, scalability, and efficiency if they’re not willing to adopt innovative technologies. There are also cases when companies are forbidden to do something by law because of privacy, again causing roadblocks.

    All of this has meant that up until now, maintaining data privacy while making the most of cloud computing has been somewhat of a balancing act for developers and companies. Companies want to fulfill their clients’ needs, while developers have to find technical solutions that provide the level of privacy required.

    Traditional Encryption methods Vs. Fully Homomorphic Encryption (FHE)

    Currently, there are several technologies and practices employed to protect data in the cloud, one of the most commonly used being traditional data encryption, which provides protection only during data transmission and storage.

    However, when data is processed, it must be decrypted—at which point it can expose data to eavesdropping, rendering it susceptible to potential threats. The aim of FHE is to ensure that the computations can be carried out on cloud-based machines while the data itself remains encrypted. With FHE, the data is really encrypted end-to-end: not only is it encrypted during transport and storage, but also it is encrypted during computations. It is only when the data or results are sent back to the client side that they are decrypted.

    This means that in the event of a data leak, the exposed information would be rendered meaningless without the decryption key, which stays securely in the hands of the owner. In other words, neither the cloud provider nor any potential spyware on the cloud machine would have the capability to decrypt the encrypted data.

    This approach, which ensures sensitive data remains encrypted throughout its entire life cycle on the cloud, even during processing and analysis, significantly enhances data security and privacy.

    Current Limitations and FHE’s Future Developments

    While developers using traditional cloud services previously had to decide whether to use the cloud with some privacy concerns or forgo its benefits altogether, with FHE we are starting to see a possible shift in attention from users’ reliance on the cloud provider to a more user-controlled approach.

    As FHE becomes more widespread, users gain the ability to make their computations over any cloud provider, even those they may not fully trust. This means the upfront costs of building new cloud platforms can be lowered by providing only FHE computation.

    While the encryption of data ensures that computations are secure and no unauthorized access or breaches can occur, this new tech is not without its limitations. For the enhanced security FHE offers, there may come a trade-off of longer execution times. Presently, we are mainly reliant on CPUs for computations. However it’s worth noting that as the technology advances and hardware accelerators become available, the execution time is expected to improve in the future. In fact, we anticipate that by 2026, FHE implementations will see a considerable increase in speed, potentially by factors of 100x or 1,000x, expanding the applicability of FHE to a wider range of use cases.

    Other benefits currently being worked on include usability. FHE had a reputation of being very complex and so used to be reserved for those with cryptography PhDs. By developing open source tools and extending the community’s knowledge around FHE, the aim is to democratize FHE so that anyone can use it, companies can experiment free of charge and check if it fulfills their needs.

    Looking to the future, privacy will likely remain high on the agenda for almost everyone. Thankfully, with new encryption technologies rapidly developing in terms of speed and usability, developers look set to achieve this, ensuring their cloud-based applications and services are as secure as possible.

  • Three Strategies for Reducing MTTD and MTTR as Outage Costs Spiral

    Three Strategies for Reducing MTTD and MTTR as Outage Costs Spiral

    According to a New Relic survey of IT professionals, the median annual cost of IT outages has reached an astronomical $7.75 million. Over one-third of the 1,700 respondents said critical business application outages now cost more than $500,000 per hour. In a business environment where most interactions with customers, suppliers and business partners are conducted digitally, downtime has become a problem and an existential threat.

    Most IT organizations carefully monitor two key metrics — mean time to detection (MTTD) and mean time to resolution (MTTR) — to track their success in identifying and remediating critical systems issues. The figures represent, respectively, the average time it takes administrators to identify that a problem has occurred and to remediate the underlying issues. They serve as a benchmark for understanding the organization’s level of awareness of the status of its systems and the speed with which problems can be diagnosed and acted upon.

    There are many ways to improve performance against these metrics, but three stand out as the most effective, as evidenced by New Relic and the survey results.

    Monitor Everything

    The less you know about a problem, the longer it takes to diagnose and fix. The New Relic survey measured 17 different observability categories, such as network monitoring, alerts, log management, browser monitoring and distributed tracing. Across the board, about two-thirds of the companies that used even one of those monitoring tools reported reduced MTTR, with many saying resolution times had fallen by more than 25%.

    One-third of respondents whose organizations implemented full-stack observability—which is the ability to see everything in the tech stack that could affect the customer experience—reported the fewest outages, fastest MTTD and MTTR, lowest outage costs and highest median annual return on investment compared to all respondents. For example, those who have full-stack observability experience a median outage cost that is 37% less than those without.

    As the complexity of enterprise technology stacks increases, so does the difficulty of pinpointing the root cause of an outage. Any monitoring is better than no monitoring at all, and the more visibility you have into applications and infrastructure the faster you can identify and resolve incidents. Strive for full-stack observability around integrated observability data and a comprehensive dashboard.

    Have an Incident Management Action Plan

    The worst time to figure out how to resolve a problem is when you’re in the midst of a crisis. Organizations with mature observability practices also have extensive and documented response plans.

    Your incident plan will be unique to your organization. Small companies and startups tend to have ad hoc response strategies based on the skills within the organization. Large enterprises may use a more formal methodology like IT service management that defines strict procedures and protocols. Companies that have embraced modern DevOps and Lean principles often use a hybrid approach that depends heavily on teamwork and collaborative problem-solving. All of these approaches can work if the team fully understands the chosen strategy.

    Document your IT architecture, identifying known vulnerabilities and outlining procedures for responding to the most common types of incidents. Plans should cover obvious disruptions like fires and power outages, but you should also think about “unicorn” scenarios such as a rogue query that ties up a database server or a communication outage at a key supplier. Mature observability teams devote a portion of their resources to constantly testing new and unpredictable scenarios and use chaos engineering to randomly inject problems in a controlled manner to see if systems respond as expected.

    As you develop incident response procedures, document the processes in runbooks, which tell responders exactly what to do when a specific problem occurs. This not only creates a database of organizational knowledge about response strategies but also helps with onboarding new employees and covers for skills gaps that occur when team members are unavailable or leave the company.

    Fix for the Future

    Technical debt is a long-term obligation that is created when a short-term – and incomplete – solution is applied. You should aim to minimize it in your observability operation.

    When a problem occurs, the temptation is to fix it as quickly as possible. Human nature is to move on to the next task without taking the time to go back and understand why a problem occurred. “Quick and dirty” fixes are an invitation to larger problems in the future. Your observability plan should include a forensics stage that documents root causes and the fixes that were applied. Even if it isn’t convenient to implement a long-term solution immediately, the documentation serves as a guide for implementing a permanent fix down the road.

    Building a resilient IT architecture is a marathon, not a sprint. The more rigor you apply to identifying and resolving problems when they happen, the better prepared you will be to prevent their reoccurrence and the more informed your team will be about the resources they manage. Reducing your MTTD and MTTR will not only improve the bottom line of your business, it will ensure that your customers have an amazing digital experience.

  • Lineaje Allies With Persistent Systems on Open Source Software Remediation Service

    Lineaje Allies With Persistent Systems on Open Source Software Remediation Service

    Lineaje this week revealed it has partnered with Persistent Systems to provide a managed service for remediating open source vulnerabilities that leverages artificial intelligence (AI) technologies.

    Persistent is extending an existing open source software maintenance service by incorporating a Lineaje platform that makes use of machine learning algorithms to analyze software bill of materials (SBOMs) to provide recommendations for fixing code and surface remediations such as updates that should be applied.

    Lineage CEO Javed Hasan said Persistent Systems is augmenting that capability with a dedicated team of specialists that IT organizations can contract to maintain open source code along with previous investments the managed service provider has made in large language models (LLMs) that add generative AI capabilities.

    Options for the services range from simply identifying issues that an internal IT team should address to a white glove offering through which Persistent Systems ensures all open source components are continuously updated.

    In the wake of an executive order issued by the Biden administration that requires federal agencies to better secure their software supply chains, more attention is being focused on the inherent cybersecurity risks associated with employing open source software to build applications. Many open source projects are led by a handful of maintainers that often lack the time and skills required to ensure the components they employ have not, for example, been compromised by malware that might find its way into downstream applications.

    Those maintainers are not being paid, so cybersecurity patches to open source software might not be readily made available, and even when they are, many organizations lack the skills and resources required to apply them in a timely manner. The majority of known vulnerabilities within application environments are still unpatched. Many IT teams are also reluctant to upgrade components for fear of breaking applications that have dependencies that are often difficult to track.

    It’s not known how much of the open source software that many developers routinely incorporate into their applications might contain vulnerabilities that could be exploited, but the level of technical debt that has accrued over the last several decades is considerable. While only a small percentage of those vulnerabilities have been exploited, cybercriminals are becoming more adept at discovering them.

    Hopefully, more contributions to open source projects will improve the overall state of application security, but in the meantime, it’s clear organizations will need to rely more on AI to drive DevSecOps workflows as ever-increasing amount of open source software continues to be relied on to build applications, said Hasan.

    The challenge, of course, is identifying which vulnerabilities, if exploited, will have the biggest impact on the organization. After all, at this point, it’s not possible to defend every application so the focus needs to be on prioritizing remediation efforts based on their actual severity rather than a general rating.

    In the meantime, DevSecOps teams would be well-advised to have incident response plans in place for remediating breaches involving both known and zero-day vulnerabilities that, in addition to being all but inevitable, can now be exploited within minutes of being discovered.

  • Redgate Automates Pulling of Test Data From Production Databases

    Redgate Automates Pulling of Test Data From Production Databases

    Redgate today added a Redgate Test Data Management (TDM) tool that automates the pulling of masked test data from databases running in production environments.

    David Gummer, chief product officer for Redgate, said this capability eliminates manual tasks that previously inhibited testing or resulted in personally identifiable information (PPI) being inadvertently used to test applications.

    Redgate TDM automatically classifies and masks data residing in SQL Server, PostgreSQL, MySQL or Oracle database before it is used to test an application. It then produces a copy or clone of that data that is a fraction the size of the original, said Gummer.

    That approach creates a repeatable process for DevOps teams that can withstand a regulatory audit of application development processes, he added. In fact, with the increased focus on software supply chain issues, more auditors are specifically reviewing how data is secured during the application development process.

    Designed to be invoked via a command line interface (CLI), within an integrated development environment or via a graphical interface, Redgate TDM reduces the friction that currently occurs when DevOps teams request test data from database administrators (DBAs), said Gummer. Many DBAs are either too busy to fulfill those requests or reluctant to provide access to sensitive data that would result in the organization running afoul of a compliance mandate.

    Developers then often resort to using anonymous data that doesn’t actually reflect the environment in which their application will ultimately be deployed.

    The amount of data that developers need to build applications is only going to increase. In the absence of any way to effectively automate the process of accessing that data, it ultimately takes longer to build and deploy stable applications. In many cases, applications are simply not tested as thoroughly as they should be before being deployed in a production environment, resulting in rollbacks that might otherwise be avoidable.

    Advances in artificial intelligence (AI) are making it easier to create test scripts, but much of the testing setup process is still based on manual processes that increase the overall level of toil.

    At a time when more organizations than ever are trying to increase developer productivity, automating relatively mundane tasks such as pulling test data can have a big impact. Developers want to spend as much time as possible focused on writing code. Everything else is a task that gets in the way of achieving that goal. While there is a general desire to empower developers, that doesn’t necessarily mean they want the cognitive load associated with building applications to increase. In fact, one of the reasons platform engineering has emerged as a methodology for managing DevOps workflows at scale is to reduce the current level of cognitive load developers experience today.

    Of course, DevOps teams are, by their nature, ruthlessly committed to automating as many processes as possible. The challenge is bottlenecks in those processes conspire to slow down the overall rate at which applications can be built and deployed despite the best intentions of all involved.