devopsy.kinsta.cloud

Category: DevSecOps

  • Managing Business Risk in a DevOps Context

    Managing Business Risk in a DevOps Context

    We hear a lot in the industry about the importance of automation in DevOps to enable speed. However, there is another element that is often missing in the discussion – risk, compliance and security. Traditionally we have a zero-sum approach, where we need to either go fast or be safe and secure. It’s one or the other. Or, maybe not! There is an 80%-80% middle ground to consider. Balanced development automation is a natural evolution of DevOps; it is not just about the technical side anymore, but also includes the risk and the compliance side, as well.

    Aligning Executives

    How do we get business executives and risk executives, at the strategy level, to align on this idea of balanced development automation? First, it is important to realize that what represents a risk for businesspeople is different than the risk that’s perceived by the development group.

    For example, let’s say there is an urgent requirement for some sort of additional business functionality in response to competitive action, or even in response to a pandemic. From a business standpoint, risk might represent a failure to deliver an effective solution within the particular timeframe required. From an IT standpoint, concerns about risk are likely going to be different from the business risk.

    That being said, it’s a futile exercise to convince business management to think in terms of perceived IT risk as opposed to business risk. IT must be able to translate the risks of their development work into business risk, or management may not see the potential impact of that risk. And so, pressure remains to “Get this thing done as quickly as possible!”

    Even at the executive levels, there is a discrepancy in identifying what risk really is. That is true at similar management levels at different organizations, even within the same industry. Let’s look, for example, at the whole issue of security and how much effort we should be paying to validate the security of a system that we’re putting in place, or that we already have in place. If an organization has experienced a breach, they are much more likely to have a management team that is concerned about security. In a different organization that has not seen any security breaches, they may not be paying as much attention or making the appropriate investments to make sure systems are secure.

    Aligning DevOps and Security

    We also need DevOps engineers and security engineers to align at the tactical level. So how can these teams, that are typically at the program or project levels, integrate and think about balancing development speed with risk and security? Operational teams are very important in achieving balanced development automation. If we look at the risks from the perspective of the development team, it doesn’t matter what technology you’re using to develop an application, or even if you’re implementing someone else’s application.

    From an IT standpoint, one of the most likely risks is failure to deliver functionality of the particular project that you’re doing. That is an example of delivery risk, which senior management is very concerned about. The way that tends to manifest is in delayed delivery or allowing the business to change their mind during the particular project. The risk of not delivering the functionality that’s required is increased. The process is just going to crack simply because the project has not been managed effectively, requirements were not stabilized or adequate testing was not done.

    That is an extremely high risk that development groups need to be aware of. A development group needs to apply some type of balanced methodology and minimize the likelihood of a gap between the expected outcome of the project and the actual outcome.

    Demand for Balanced Development Automation

    Today’s business context demands both speed and some awareness of risk from development teams. This will only be achieved through alignment at the executive level and at the tactical level. Focusing on areas of business risk are essential to achieving this alignment.

  • Teleport Adds Database Support to Security Gateway

    Teleport Adds Database Support to Security Gateway

    Teleport announced today it has added support for databases to a security gateway, delivered as a cloud service, that is currently used to secure Linux servers and Kubernetes clusters.

    Ev Kontsevoy, CEO, said Teleport intends to extend the reach of the security gateway up the entire stack of IT infrastructure that developers routinely use to remotely access databases. Initially, Teleport 6.0 adds support for open source PostgreSQL and MySQL databases.

    Teleport has gained traction as an access management tool because it provides a single binary that can be easily deployed by developers to encrypt IT platforms and enforce session controls. It automatically discovers all the resources in an IT environment, along with the protocols needed to access them. Teleport also provides a unified audit log, in a JSON format, that enables IT teams to track what resources are being accessed, when and by whom.

    Other features include the ability to authenticate identities via built-in single sign-on (SSO) and multi-factor capabilities, discover and see all database instances, integrate with command line interfaces (CLIs) and a set of workflows for managing privilege escalation.

    Access control is becoming a bigger issue due to a number of factors. The overall IT environment is becoming more complex as the infrastructure stack required to run applications continues to grow; most IT teams continue to work from home to help combat the COVID-19 pandemic. Teleport provides a fine-grained approach to streamlining access management across servers, clusters and databases in a way that eliminates the need to rely on virtual private networks (VPNs). In effect, Teleport enables IT teams to move toward a more identity-centric approach to unifying the management of access, Kontsevoy said.

    That’s critical at a time when the rise of DevSecOps is pushing responsibility for security further left toward developers, Kontsevoy added. While the rate at which that transition occurs will vary widely, Kontsevoy said it’s clear developers are taking more control over access control as part of a broader effort to roll out secure applications, faster.

    It may be a while before DevOps teams are able to aggregate all the access control protocols they currently employ under a single proxy. However, Kontsevoy said, the massive amount of time and effort spent managing access control today will drive DevOps teams to look for ways to automate what is currently a very manual process.

    Less clear is what role cybersecurity teams might play in supervising access management. The days when a separate overlay was needed to manage access may be coming to a close.

    In the meantime, it’s clear VPNs were not designed to address access management, in an era where the bulk of IT teams – and the employees they support – are working from home. More employees may be soon be heading back to the office more frequently, but it’s likely that remote work will remain prevalent. That means legacy approaches to managing remote access that were never designed to scale will becoming increasingly obsolete.

  • Without These 3 Things, You Don’t Have DevSecOps

    Without These 3 Things, You Don’t Have DevSecOps

    DevSecOps adds security to the DevOps software development and releasing paradigm. Everyone thinks this is a great idea, except actual Dev and Ops practitioners, for whom security can be a thankless, stressful time sink. Without the right approach and tools, an organization can run a DevSecOps process that actually contributes little to security. Security simply tags along after development and operations, ignored at every turn. The result is rapidly released, insecure code.

    Industry vendors will tell you they have a DevSecOps solution. You, in turn, may believe you have DevSecOps up and running. However, there can be a big difference between acquiring a DevSecOps solution and fielding a viable, effective DevSecOps program.

    What DevSecOps Isn’t

    1. Every task is manual, and done mostly by consultants.
    2. You send out myriad PDFs or spreadsheets and waste time in meetings.
    3. Your solution or program escalates a lot of security alerts, but never delivers a fix.

    DevSecOps, a Brief Overview

    DevOps, the merging of previously separate software development (Dev) and IT operations (Ops) workflows, has been a boon to businesses. When developers work directly with Ops, which releases and manages the code in production, the entire development-to-release cycle speeds up. This is great news, except when it comes to security.

    Rushing new code into continuous integration/continuous deployment (CI/CD) platforms invites risk exposure. DevOps can easily, but inadvertently, put vulnerable code straight into production on a daily basis. To mitigate this risk, the DevSecOps approach inserts a security function into the workflow.

    This is good, in theory. However, if this is all you have, you do not have a DevSecOps program; you have missed the bigger picture. Without automation, tool integration and results validation, simply injecting security processes into the DevOps workflow might actually make everything worse. Your code will be less secure. The security team will not move quickly enough for the DevOps team, which aims to rapidly release code, and will not always address the security issues raised.

    DevSecOps Requires True Automation

    DevSecOps has to include true automation in the security process. The practice of security pros copying code for security testing and then returning with a spreadsheet of remediation requests simply does not work. Good intentions aside, the Dev team does not want to deal with a long list of security problems, many of which are perceived to be low-risk or could generate false positives. Security is perceived as slowing everything down. There can even be organizational issues that keep the two groups in opposition to one another.

    Instead, code vulnerability assessments should be automated within the DevOps workflow. As code gets checked into Github and then compiled via the build pipeline CI tools, it needs to undergo automatic static, dynamic and interactive analysis. It should undergo a full stack assessment, too. The automated assessment must examine code for vulnerabilities at the mobile or web client layer, the API data transport application network layer and the back end cloud building block app services layer. Automated security testing can analyze microservices, serverless architectures, storage and databases. With this approach, the “sec” part of DevSecOps comprises a “build, set and forget” function. There will be security people involved, of course, but the majority of work is automated.

    This automated vulnerability assessment must then generate alerts and establish a priority hierarchy for their handling. Again, automation plays a pivotal role here, and needs to automatically, and in a meaningful way, triage the long list of findings based on issue severity, privacy concerns and app store blockers. If the assessment produces an overly long list of risks to fix, the DevOps teams commonly tune them out as noise that delays release schedules. However, if the automated process identifies the five or ten “must address” problems, developers are more likely to respond to a realistic, practical set of tasks that create an effective process and resolve issues at the roots.

    DevSecOps Must Integrate With Development and Security Tools

    Security processes are most effective if they integrate with the toolsets used by the DevOps team. These include development tools, cloud platforms and monitoring tools such as security incident and event management (SIEM) systems, as well as ticketing and remediation solutions. That way, security connects directly into the DevOps pipeline; it is neither a digression nor a bottleneck.

    For example, if issues get distributed via ticketing systems, they go directly into developer workflows. Developers might be accustomed to working on issues described in JIRA tickets, for example. If the alerts are suitably prioritized, the developers will likely not perceive the ticket as an imposition on their other work. As security issues appear in JIRA tickets, developers can work on them at a familiar, practical cadence. This improves security and DevOps team collaboration by providing details about issues, occurrences, recommendations and remediation. The results can help remediation of security vulnerabilities be more effective.

    DevSecOps Provides Validation of Results

    A viable DevSecOps program will also provide stakeholders with data about how the program is performing. Reporting and data visualization that documents the results of its vulnerability assessments, and the subsequent remediations, are critical to a successful program. While no application is always perfect on any given release, knowing the risks and having a measurable, clear course of action is critical to a solid DevSecOps program. Successful programs will feature reporting on metrics such as critical issues fixed before production, “business blockers” fixed before rejection, legal costs and regulatory fines avoided and security time and costs saved. Without such reporting and validation of results, there can be no actual DevSecOps. It will be DevOps with some ambiguous security activity surrounding it.

    Application security tools are essential to realizing these three tenets of true DevSecOps and an effective appsec program. The preferred tool should be, as these parameters suggest, highly automated and easy to integrate. It also has to have in-depth reporting capabilities. Armed with the right tools, a DevSecOps group can embrace an approach to the work that is fully automated and intuitively part of the DevSecOps workflow.

  • Sonatype Acquires MuseDev to Add Code Analysis

    Sonatype Acquires MuseDev to Add Code Analysis

    Sonatype today revealed it has acquired MuseDev, a provider of a code analysis tool, in addition to updating its Nexus platform for discovering vulnerabilities in software supply chains.

    Muse analyzes code each time a pull request is made, which makes it easier for developers to discover and address issues long before they commit code. Muse is integrated with 24 pre-configured code analyzers for GitHub, GitLab and Bitbucket repositories. It then analyzes each pull request to surface bugs, as part of automated code review, and includes analysis of interprocedural information flow and thread safety issue analysis, along with guidance to fix any bugs discovered.

    In addition to adding support for Muse, the latest edition of the Nexus platform integrates a container firewall from NueVector along with a set of tools for identifying and providing guidance on how to address misconfiguration issues that frequently arise when developers employ open source Terraform software to programmatically manage infrastructure as code.

    Finally, Sonatype added tools to provide better guidance on the implications of open source licensing terms attached to various projects, while at the same time starting its own community for organizations migrating from Bintray and JCenter, now that those tools have been sunsetted.

    Brian Fox, Sonatype CTO, said the expectation is Muse will create an opportunity to introduce the complete DevSecOps portfolio to developers as they analyze code. Most developers are keenly interested in both optimizing and securing their code. They would just prefer to achieve that goal on their own versus being informed of an issue after code has been committed to a repository managed by a larger DevOps team, noted Fox.

    An advanced development pack was added to the Nexus platform last year to make it easier to surface dependencies in code that are vulnerable to threats. It applies machine and deep learning algorithms to automatically identify and block software supply chain attacks based on typosquatting and malicious code injections. Collectively, these tools give developers control over third-party open source code, first-party source code, infrastructure as code and containerized code, Fox said.

    Sonatype claims it now counts 70% of the Fortune 100 as customers, and supports more than 2,000 commercial engineering teams. In 2020, it claimed it saw a 35% annual growth in Nexus repository installs, which now stands at more than 250,000 instances employed by nearly 15 million developers.

    Overall, it’s not clear how much progress is being made toward embracing DevSecOps best practices. Sonatype, however. is making a case for putting DevSecOps tools directly into the hands of developers to address software supply chain security. In the wake of some recent high-profile breaches involving software supply chains, that approach may soon gain additional traction. After all, for all the encouragement being provided by application development team leaders these days, there’s nothing quite as effective as providing developers with a set of tools that enables them to achieve that goal on their own terms versus requiring them to follow a set of procedures dictated by a DevOps management team.

  • How to Eliminate Incident Inefficiencies

    How to Eliminate Incident Inefficiencies

    In today’s complex, dynamic IT environments, the proliferation of disparate IT Ops, NOC, DevOps and SRE teams and tools is a given – and usually considered a necessity. This leads to the inevitable truth that when an incident happens, often the biggest challenge is collaborating between these teams to understand what happened and resolve the issue. Inefficiencies suffered during this critical stage can have huge impacts on how much each incident costs the business.

    I recently sat down (virtually) with Sid Roy, VP of client services at Scicom, to get a deeper understanding of how IT leaders can more effectively size up these inefficiencies and eliminate them.

    The Costs of IT Incidents

    When asked what a minute of downtime costs, analysts and vendors may provide different answers – but they are more or less aligned around the same order of magnitude – several thousands of dollars per minute. And with an average of five major incidents a month and an average time of six hours for resolution, this easily amounts to millions of dollars a year.

    The three key drivers of these costs are:

    Staffing and team member costs: This includes full-time employees (FTEs), consultants, and overhead when other teams are pulled in to deal with the incident. For many organizations, this can include offshore incident response teams.

    The direct and indirect costs of an IT incident: This includes your infrastructure or capital expenditures like software licenses for monitoring, log and event management, notification, ticketing, collaboration, etc.

    The business impact of an IT incident: This is one of the most challenging and unpredictable variable costs to calculate or manage, and is often the highest of all three drivers. It includes revenue loss/delay or reduction due to a major incident, and the profit or loss due to brand or goodwill impact. It also includes inefficiencies suffered by other parts of the business when critical services they depend on are degraded or unavailable.

    Fragmented Teams Magnify the Challenge

    The incident volume, complexity and throughput obviously affect the number of people and amount of time needed to deal with them and often drive more indirect costs as needed resources pile up. To save on these millions of dollars of costs, you need to be able to collaborate and lower MTTR. As mentioned above, this becomes a challenge in agile IT environments. To help streamline operations, teams need to start asking and answering several key questions:

    • Do you have an up-to-date map of your critical services?
    • Are they prioritized by business criticality (revenue, number of customers, other supported services in the supply chain)?
    • What are the upstream and downstream dependencies of these applications?
    • Have you identified the major infrastructure and application elements in your environment?
    • Are you aligned with the owners of these systems?
    • Do you have real-time knowledge of changes being done to the infrastructure and applications?
    • Do you have monitoring gaps?
    • Which monitoring tools provide you with the best value?

    Answering these questions involves overcoming fragmentation across teams of people, processes and tools – essentially integrating ITSM and ITOM to enjoy the benefits of contextual full-stack visibility and streamlined processes within the organization.

    The Right Combination for Incident Response

    What is the right combination of people, processes and tools we just discussed? Here are the two main guidelines:

    • Set up a major incident management team – ideally, from your existing staff. This team includes three vital roles:
      • The incident manager/incident response commander. This is a designated role in charge of declaring a major incident and taking ownership of it. Their job is to, essentially, stop the bleeding of revenue and costs.
      • The NOC/monitoring team. This is your front line defense. When things go bump in the night or boom in the day, they’re the ones picking it up with their “eyes on the glass” – 24/7. And, they’re in charge of reporting and creating full situational awareness for the incident command through bidirectional communications.
      • The production support team. This team actually effects the required changes and executes the remediating action.
    • Deploy event correlation and automation tools to enable the incident management team. These tools are key, allowing your team to perform the required actions.
      • First, correlate the alerts created by your monitoring and observability tools into a drastically reduced number of high-level, insight-rich incidents by using machine learning and artificial intelligence (ML/AI). Add context to these incidents by ingesting and understanding topology sources, as well. This creates the necessary full-stack visibility and situational awareness.
      • Then, use ML and AI to determine the root cause of these incidents, including correlating them with data streams from your change tools: CI/CD, orchestration, change management and auditing to identify whether any changes in your environment caused these incidents.
      • Finally, automate as many processes as you can to free your IT Ops team from manual, time-consuming tasks. By integrating with collaboration tools, you can also enable the above-mentioned bidirectional communications.

     

  • Linux Foundation Project Secures Software Supply Chains

    Linux Foundation Project Secures Software Supply Chains

    The Linux Foundation today embraced a sigstore project founded by Red Hat, Google and Purdue University to make it simpler for developers to employ cryptographic software, enabled by transparency log technologies, to secure software supply chains.

    Luke Hinds, security engineering lead in the office of the CTO at Red Hat, said he and Dan Lorenc, a staff software engineer for Google, led a small team creating a lightweight mechanism for signing software artifacts, such as release files, container images and binaries, in way that creates an immutable, tamper-proof log.

    Now, the goal is to take that project to the next level by contributing it to the Linux Foundation, at a time when the focus on software supply chain security has increased in the wake of a spate of high-profile breaches. As part of that effort, a free service, based on sigstore, will also be made available by the Linux Foundation to make the cryptographic software easily accessible to a wide range of developers.

    Hinds said one of the reasons that artifacts are not signed by developers is that the current processes employed are too cumbersome. The cryptographic software is designed to be integrated as an extension of existing workflows, Hinds noted.

    Because the log created is immutable, everyone participating in the software development process, including auditors, can now transparently track chain of custody for any software artifact, Hinds said. At its core, sigstore creates a set of short-lived ephemeral keys with a trust root based on an auditable public log.

    Existing approaches rely on digests stored on insecure systems that are susceptible to tampering. Cybercriminals can, for example, swap out digests if they can gain access to compromised credentials. Those types of targeted attacks can be thwarted using sigstore, because the log management system that underpins it is immutable, said Hinds.

    Of course, no system for securing software supply chains is going to be useful if developers won’t employ it. Key management, key compromise/revocation and the distribution of public keys and artifact digests are challenging to manage. Developers, then, need to determine which keys to trust in addition to learning how to sign them when different platforms are employed. Digests and public keys are also often distributed across vulnerable websites susceptible to hacks, or stored as a README file on a public git repository.

    As organizations embrace DevSecOps best practices, it’s only a matter of time before the entire software supply chain comes under greater scrutiny. Ultimately, the issue will come down to finding a way to secure those supply chains, either from the top down by deploying and maintaining a platform, or simply making it easier for developers to better secure artifacts from the bottom up.

    Regardless of approach, the signing of software artifacts should, one way or another, become more routine in the weeks and months ahead. The biggest challenge will be overcoming the simple inertia that currently exists among developers who routinely ignore the whole process.

  • GitGuardian Reports Careless Handling of Application Secrets

    GitGuardian Reports Careless Handling of Application Secrets

    A new report, the 2021 State of Secrets Sprawl on GitHub, published today by GitGuardian, a provider of a tool for monitoring usage of application secrets, suggests developers are not especially good at keeping those secrets safe.

    Based on an analysis of every single commit made to GitHub, the report finds there has been a 20% year-over-year increase in the number of secrets – such as application programming interface (API) keys, private keys, certificates, usernames and passwords –  discovered on a public repository.

    Developers, as they build an application, make secrets easily accessible as plain text for the sake of convenience. However, when those applications are deployed in a production environment, developers often forget to delete the secrets they stored in GitHub.

    GitGuardian CEO Jeremey Thomas noted that cybercriminals are now actively scanning repositories looking for secrets that would enable them to compromise applications.

    As the number of application development projects being launched increased, so too did the number of application secrets being stored in repositories like GitHub. The GitGuardian report notes 60 million repositories were created in the last year, representing a 35% increase over the previous year. GitGuardian claims it detected more than 5,000 application secrets per day. Most of those secrets have been detected in repositories that belong to developers (85%), while the other 15% belonged to organizations. The top four countries where secrets were disclosed were India, Brazil, the United States and Nigeria.

    GitGuardian also notes it sent out 937,539 pro bono alerts to 558,086 developers last year that informed developers that application secrets were exposed. The mean time for GitGuardian’s algorithm to detect a leak is four seconds. The average mean time to response of a developer when informed of the issues is about 25 minutes, the report noted.

    As a best practice, GitGuardian recommends not storing unencrypted secrets in git repositories, and that unencrypted secrets should never be shared via messaging systems like Slack. DevOps teams should also restrict API access and permissions.

    As more attention is paid to how software supply chains are managed in the wake of some recent, high-profile breaches, there is no doubt the number of audits conducted will increase. Many of those auditors will specifically be trying to ascertain how application secrets are being managed. Developers may have to get used to a new, higher level of scrutiny, especially as DevSecOps practices become more widely adopted.

    In the meantime, DevOps teams may want to review their dependency on public repositories. There are plenty of private repository options that provide most of the same source code sharing capabilities as a public repository. That may mean someone on the DevOps team is required to manage the private repository, but, given the fact that many regulatory bodies will soon be looking to make an example of organizations that don’t secure application secrets, chances are good those costs will be trivial compared to a fine that would be levied.

  • GrammaTech Allies with GitLab to Advance DevSecOps

    GrammaTech Allies with GitLab to Advance DevSecOps

    GrammaTech announced today it has partnered with GitLab to integrate its GrammaTech CodeSonar static application security testing (SAST) tools with the GitLab Ultimate DevSecOps platform.

    Vince Arneja, chief product officer at GrammaTech, said integration with continuous integration/continuous delivery (CI/CD) platforms such as GitLab is critical because it enables security scans to run automatically any time code is merged. That capability reduces the amount of code that is scanned at any one time, Arneja said.

    GrammaTech is partnering with multiple CI/CD platforms and integrated development environment (IDE) providers to make it simpler to create multiple points for scanning code during the application development process, Arneja noted.

    GitLab, meanwhile, is providing its own tools for analyzing artifacts as they move through the software development life cycle. The GrammaTech tools, available via the highest tier level made available by GitLab, analyze code at a deeper level, said Arneja.

    Ultimately, the goal is to enable developers to discover security flaws as early as possible in the application development life cycle. The later those flaws are discovered, the more expensive they become to fix, Arneja said.

    Developers, naturally, tend to postpone security scans as they race to meet an application deadline. That practice creates issues; the more code there is to analyze, the longer such scans take. It’s generally more efficient to scan smaller amounts of code more frequently. Otherwise, developers can become overwhelmed by the number of security bug fixes that need to be addressed at the back end of the application development process. Automating security scans allows an organization to move toward embracing DevSecOps best practices in a way that doesn’t rely on a developer remembering to initiate a scan.

    Most developers are not deliberately ignoring security issues – it’s just that the existing, manual processes for discovering those flaws is inefficient.

    Automated scans also provide the added benefit of simplifying discovery of common security flaws long before a code review, creating more time to address significantly more complex issues.

    Application development teams are also under pressure to reduce the total number of bugs that need to be fixed after an application is deployed. As the number of applications being deployed steadily increases, developers can find themselves spending more time fixing bugs than writing new application code.

    Most organizations are not very far along in their journey toward embracing DevSecOps. However, as it becomes easier to integrate a variety of scanning tools within DevOps workflows, the number of organizations moving up the DevSecOps maturity curve should increase. In the wake of some recent, high-profile attacks on software supply chains, the sense of urgency surrounding the adoption of DevSecOps best processes has undoubtedly increased.

    In the longer term, there may soon come a day when security is viewed as just one of many quality assurance gates that code needs to pass through before it’s allowed to be promoted. In the meantime, an ounce of cybersecurity prevention at the front end of any application development is most certainly going to be worth more than several pounds of cybersecurity cure applied too late.

  • Cybersecurity 2021: Are You Really Prepared for a Cyberattack?

    Cybersecurity 2021: Are You Really Prepared for a Cyberattack?

    As the majority of businesses are increasingly moving to the online world, employees keep working remotely and more cyberattacks keep happening all over the globe, there is no doubt that embracing DevSecOps should be the new normal for every company. Organizations need to be able to adopt DevSecOps practices and adapt to new and evolving threats in order to protect their data and systems from malicious attacks.

    At Cybersecurity 2021: The New Normal Virtual Summit, taking place March 4 and 5, the brightest minds in the security and IT industry will come together to discuss new security threats, empower DevOps teams with the latest security tools and provide practical tips and guidance to help developers and ops teams make the right security decisions to keep their data secure.

    The two-day virtual event features thought-provoking discussions, networking opportunities and educational sessions focused on:

    • DevSecOps tools and practices
    • The main challenges of security and development teams when it comes to AppSec
    • Identity and Access Management (IAM)
    • Passwordless and the long-term future of identity management
    • Policy-as-Code and how it impacts security
    • How security threats changed with COVID-19 and what to expect in 2021
    • How to manage AppSec
    • How to mitigate API vulnerabilities
    • How to break the silos and advance towards DevSecOps maturity
    • How to expand your security program through low-to-no cost initiatives
    • Time series database for security monitoring
    • Machine identity management
    • Top 10 Hacks From the Past Decade
    • Runtime observability techniques for security and compliance
    • Securing AWS credentials on DevOps machines

    Cybersecurity 2021 features an outstanding lineup of industry leaders, including:

    • Ira Winkler, author and president at Secure Mentem
    • Chenxi Wang, founder and general partner at Rain Capital
    • Ron Gula, president at Gula Tech Adventures
    • Richard Stiennon, founding member of The Analyst Syndicate and chief research analyst at IT-Harvest
    • Joe Levy, CTO at Sophos
    • Rajat Bhargava, founder and CEO at JumpCloud
    • Myla Pilao, head of security research communications for TrendLabs at Trend Micro
    • Upasna Gupta, senior product marketing manager for Prisma Cloud at Palo Alto Networks
    • Julian Waits, general manager of cyber business unit and public sector at Devo
    • Joseph Feiman, chief strategy officer at WhiteHat Security
    • Ian Murphy, founder and CEO at CyberOff
    • Mike Jones, security researcher at H4unt3d Hacker Podcast
    • Rhys Arkins, director of product management at WhiteSource
    • TJ Jermoluk, co-founder and CEO at Beyond Identity
    • Jim Ducharme, general manager of the anti-fraud business unit at RSA

    Attendees will have the chance to enter a raffle for a chance to win a free copy of “You can Stop Stupid” by Ira Winkler and another one for a free copy of “Security Yearbook 2020” by Richard Stiennon. There will be valuable resources available for download and attendees will be able to interact with sponsors to learn more about their security tools and services.

    To see the full agenda and to register, please visit the Cybersecurity 2021 website.

  • Cloud Migrations Demand Risk and Compliance Maturity

    Cloud Migrations Demand Risk and Compliance Maturity

    The COVID-19 pandemic brought undeniable disruptions for organizations and their employees whether business, personal or otherwise. Across the globe, businesses and governments alike were forced to try and manage these disruptions. For nearly all organizations, digitization initiatives were accelerated in a short period of time, from implementing work-from-home policies and launching new applications to support a distributed workforce to adopting artificial intelligence (AI) to adapt supply chain processes and more.

    According to Gartner, by 2022, 30% of all security teams will have increased the number of employees working remotely on a permanent basis and by 2023, 40% of all enterprise workloads will be deployed in cloud infrastructure and platform services. The distributed cloud enables organizations to provide products and services when they’re needed in this era of work-from-anywhere, whether to their employees or customers.

    Even in sectors such as energy and utilities, which are historically heavily reliant on standard on-premises installations and had often avoided cloud adoption, business leaders are realizing the value of migration, especially in light of the global pandemic. These businesses are able to deliver digital products with speed, experiment with tools such as artificial intelligence (AI) and robotic process automation (RPA) to increase productivity and to lower the total cost of ownership (TCO) across assets, among other benefits. Still, cloud migration risks abound, and new challenges may arise. A risk that cannot be ignored is the cybersecurity risk. Meeting regulatory IT compliance and managing risks involved with cloud computing are top challenges facing those migrating their workloads to the cloud.

    Cloud Migrations and Security: Clear Risk and Compliance Gaps

    Many cloud providers such as Microsoft Azure, AWS, Google Cloud and others have a global network of service models that include compliance teams and consulting organizations that help with risk and compliance for their cloud instances, whether public, private or hybrid cloud. Many of them have even built tools for customers to use to implement basic risk and compliance management in-house, leveraging relevant data and applications. However, monitoring and meeting security and compliance controls that span people, processes and technology for cloud environments, and in the broader context of the enterprise, is complex. This is one cause of cloud migration risk, and is a challenge for many other reasons; lack of measurement, visibility and accuracy are three of the greatest risks when migrating to the cloud. The point solutions that currently support most cloud instances don’t elevate the posture of cloud environments to that of the enterprise risk posture, and the majority of assessments still remain point-in-time and qualitative. Metrics are fractured and far from holistic, and very few, if any, solutions can provide insight beyond compliance and into real-time risk management.

    IT and security regulations and standards are filled with requirements that were created before the cloud became a commodity. In the energy sector, for example, cloud security isn’t taken into account because regulators and industry leaders couldn’t fathom those platforms becoming as pervasive as they have, because on-premises installations were standard to the industry. On-premises installations are still a mainstay in energy, power and utilities, and for those who have become more comfortable with cloud migration processes, there is a clear and pressing need to leverage their human capital, processes and technologies to implement robust risk management practices.

    Beyond regulatory compliance lags, many distributed organizations opt to have multiple providers in place, requiring a multi-cloud approach to compliance requirements and risk assessment. As more organizations consider cloud migration risks and begin shaping their cloud migration strategies, there are some innovations that address risk management and compliance in the cloud, but not many. Measuring, managing and reporting on compliance frameworks, making the shared responsibility model actionable, and getting a view into risk are all serious challenges. Cloud providers will continue to mature and bring new innovations to their services, but, to date, there hasn’t been a lot of anticipatory work done in this area. The focus has largely been on creating reactive solutions. In heavily regulated countries, the challenges only become greater.

    Leverage AI Automation for Compliance and Risk Management

    There is a shift occurring in cybersecurity and IT risk management, calling for the dramatic disruption of the legacy IT governance, risk and compliance (GRC) space and demanding a reevaluation of how we manage compliance and risk in the digital age. For years, data has been aggregated manually and analyses performed on out-of-date information. With the increasing availability of automation, the five functions of the NIST Cybersecurity Framework – identify, protect, detect, respond and recover – are becoming more continuous in nature and shifting into real-time management, from assessment to reporting and more.

    Leveraging this technology in the cloud is no exception, but those who look to reinvent their approach must look for solutions that go beyond the siloed capabilities of cloud security posture management solutions and similar markets.

    Ultimately, the true test of this next-generation approach comes when organizations are able to roll all of this data up to risk. With risk metrics that are supported by drill-downs, trend reports and risk profiles, executives can get the visibility they need into their posture with the most up-to-date data, informing their key business decisions. Using this next-generation approach to risk will inform global expansion, allow executives to evaluate risk across lines of business, and increase cyber maturity in any cloud-based organization.