devopsy.kinsta.cloud

Category: DevSecOps

  • When AI Met DevOps: Machine Teaching

    When AI Met DevOps: Machine Teaching

    One of my favorite quotes about artificial intelligence (AI) isn’t from a data scientist or tech industry analyst. It’s from a doctor.

    When asked if AI would eventually replace radiologists, Dr. Curtis Langoltz of Stanford University pithily replied “No, but radiologists who use AI will replace those who do not use it.”

    This great insight is highly applicable to IT. Yes, there are many ways we can use AI methods to fully automate a broad range of DevOps tasks. Companies, including CA Technologies, are actively involved in the development of solutions that enable our customers to do exactly that.

    Algorithmic machine learning, however, doesn’t just empower systems to perform tasks and solve problems autonomously. It also makes them great active partners with human beings. In fact, much of what machines learn they also wind up teaching.

    The synergy between AI and human radiologists, for example, stems in part from the fact that digital systems can differentiate about 200 levels of gray in a diagnostic image—compared to only about 16-20 that are discernable by the human eye. Train an AI system with enough images, and that precise cognitive power can more effectively detect that something is going on.

    But for the most effective diagnostic process, you don’t just depend on that detection alone. You use that detection to empower a human diagnostician who can apply a broad understanding of pathologies and deep experience with the complexities of individual patients to deliver the highest quality care.

    In DevOps, we can do the same. We can use AI to capture insights that teach us how to continuously optimize our workflows and processes. We can also use our AI learnings to push our work up higher on the value chain.

    More specifically, the synergy between AI and human intellect can:

    Make development smarter. The speed, quality, and efficiency of development pipelines can be affected by all kinds of subtle factors. A less-than-optimally designed API, for example, can be a small but chronic stumbling block to everyone who has to use it. Scrum outcomes can be undermined by anything from a particular type of technical challenge to a nascent personality conflict.

    By capturing a rich set of DevOps metrics and applying machine learning to those metrics, development leaders can discover process bottlenecks and skilling shortfalls. They can better coach individuals and promote team collaboration. The result: a better working environment that facilitates digital agility for the enterprise and higher satisfaction/retention for valuable employees.

    Make ops smarter. Enterprises are running increasingly volatile and complex workloads on increasingly hybridized infrastructure. At the same time, the tolerance of internal and external users for latency and outages continues to approach zero. There are also real costs associated with performance problems.

    The elastic capacity of public and private cloud does much to help with workload volatility. But adding cloud capacity also has its costs—and end-to-end application performance often depends on back-end systems that are not cloud-based. So not every performance issue can be solved by simply throwing more capacity at it. Nor should it be, if a rearchitecting can fix a bottleneck less expensively.

    Here again, AI can teach us a lot. We can uncover opaque interdependencies in processing load and data throughput. We can spot conditions when it may make business sense to throttle cloud costs that aren’t cost-justified. We can even better understand the real-world conditions—whether patterns in customer behaviors or our own marketing programs—that are driving our demand spikes and troughs. All of this helps us deliver consistently responsive digital experiences at a cost that makes good business sense.

    Make security smarter. AI is already being broadly implemented in security solutions such as endpoint protection and threat response to automate the detection and neutralization of anomalous activities in the enterprise environment. But effective multi-layer security isn’t just about finding and stopping exploits. It’s also about building applications that are themselves inherently less vulnerable to hacking. This is the essence of DevSecOps.

    AI has huge potential value here. We are writing a rapidly growing volume of increasingly sophisticated code. It is very easy for subtle vulnerabilities to hide in that code. As our development practices become more complex—often including multiple contractors—it becomes more difficult to understand exactly where and why these vulnerabilities were introduced into our code. Machine learning can teach us the answers to these questions, so we can more proactively secure our data and our businesses.

    It’s especially interesting to consider what may happen as we start to apply AI to DevSecOps across our organizations, as well as within them. More diverse inputs enable machine learning to discover more factors that impact code pipeline performance. By aggregating our knowledge about how we build, deliver and secure our code, we are all likely to benefit with better practices and stronger guardrails.

    — Cameron Van Orman

  • Implementing DevSecOps in the Mainframe-Driven Enterprise

    Implementing DevSecOps in the Mainframe-Driven Enterprise

    DevSecOps is emerging as an important trend in corporate IT. It makes sense. With each passing day more applications serve a larger user base. Whereas in the past the typical business application was accessible only from within the confines of an enterprise’s internal network, today, the software-as-a-service (SaaS) paradigm enables millions of users work with a single application.

    In the SaaS paradigm, a single application will service a number of companies and give each user in the company access to data and functionality based on a given company’s subscription plan. Take Saleforce.com for example: There is but one Salesforce.com providing service to thousands of companies worldwide, each with one to thousands of employees. Each company and each employee within a company will have particular access rights to the application. A paradigm in which there is one application servicing millions, perhaps billions of users requires a comprehensive approach to security. The slightest breach can result in havoc. Imagine what would happen if a SaaS application contained a flaw that allowed a company to see the financial data of its competitor that also subscribed to the SaaS.

    Given that the internet is the de facto network for all worldwide, today’s security concerns go way beyond restricting network access. Keeping bad actors away is becoming more difficult all the time. The sad fact is that a seemingly good actor can turn into a bad actor instantly and wreak havoc not only on the servers with the network—as is the case of a DDos attack—but on the application layer as well. In fact, according to IBM, an enterprise’s network layer is half as vulnerable as the application layer, yet more money gets spent protecting the network.

    This is an eye-opening fact and one not on the minds of most application developers. But, it might be, if developers had the benefit of the expertise and ongoing guidance required to implement bulletproof security at the application level.

    Which leads us to the mainframe.

    In today’s world of modern, web-based cloud computing, the mainframe is a major player. Seventy percent of corporate data lives on a mainframe. Also, now that the Linux operating system is pervasive in the mainframe environment, enterprise-level application developers can—and do—write Java, Python and NodeJS code for the Big Iron just as they do for X86 commodity environments. Technologies such as IBM’s z/OS Connect EE and StrongLoop make it possible to use an industry-standard specification such as OpenAPI to expose mainframe services as REST API without a lot of low-level fiddling around.

    This is good news.

    The bad news that application developers are just not that adept at security best practices. They don’t have the experience of a CISSP professional who has spent years, if not decades, in the trenches battling the bad guys in cyberspace. But that was then and this is now. Today we have DevSecOps.

    DevSecOps is the next generation of IT transformation. The goal of DevOps is to create an IT culture that is unified, automated and self-correcting. DevOps combines development and operations into a single organization focused on creating and deploying quality software at ever-increasing rates. DevSecOps adds security into the mix. The scope of DevSecOps activity is not confined to software development for commodity-based X86 servers and mobile devices. DevSecOps is intended to apply across all facets of the enterprise, from mobile to mainframe.

    DevSecOps is about a lot of things. It’s about the adoption of tools such as IBM’s AppScan, a tool that allows an enterprise to implement and monitor a variety of tests (web, mobile, dynamic, static and interactive) in a unified dashboard. It can include leveraging Secure Service Containers to ensure external security and safety from insider threats.

    DevSecOps is about putting in place a set of policies, along with appropriate operational checks and balances, that ensure that the enterprise follows security best practices at all times. It’s about following practices that go beyond episodic security testing. This means continuously analyzing the IT infrastructure to identify vulnerabilities as well as defining ways to mitigate risks and prioritize prevention activities accordingly. It means making compliance to regulations such as GDPR, PCI-DSS, PA-DSS, ISO 27001 and ISO 27002, HIPAA, GLBA and Basel III  an enterprise-wide responsibility, not just something that’s siloed away to the Compliance Department.

    DevSecOps is about acting proactively by using automation to rigorously inspect all code to uncover potential hazards. It means using HTTPS as the default protocol for public-facing URLs. It means making sure that all third-party components are built from source code when possible—and, if building against source is not possible, ensuring third-party components and libraries are certified safe by an accepted authority.

    DevSecOps is about a lot of things, but there is one principle that overrides all others:

    When it comes to DevSecOps, the most important principle to follow is to make sure that a security expert is a starting member of any team involved with making software for the enterprise.

    It doesn’t matter if the company is 30 years old running on a mainframe or 30 days old using native cloud services, there must be security experts as part of its development work from the start.

    This may sound obvious, but it’s easier said than done.

    It’s not a new challenge. It took the enterprise a long time to get QA personnel involved at the start of development process. Before the DevOps/Agile sensibility took hold, QA personnel showed up at the end of the release cycle, well after code was hardened.

    The same is true of release personnel. Before DevOps, release management was given some code and told to just get it out as soon as possible. There was limited knowledge as to what the code was about or the potential impact it might have on the infrastructure. As a result, weekends were spent in war rooms struggling to deploy code that was sparsely documented and mysteriously tested. You can bet that once release management showed up at the first project planning meeting, things changed.

    Now, with the emergence of DevSecOps, it is security’s turn in the tumbler. Security has always been an important part of enterprise IT. The number of compliance regulations on the books attest to the fact. However, security was usually the responsibility of the Compliance Department more than part of the IT organization overall. For many companies, the only time security ever came to the forefront was during audit time. As a result, security practices were more reactive than proactive. And, for many companies, they still are—think back to reactions to the Equifax and Target breaches.

    However, the success of DevOps has not gone unnoticed. The standard features of DevOps—unifying groups toward a common purpose, implementing automation whenever possible and using sprints and retrospectives to facilitate fast releases and address shortcomings quickly—has had positive results. Forward-thinking companies understand that DevOps works, and its successor, DevSecOps, will work provided the essential principle is followed: Make sure security experts have a seat at the table from the beginning.

    For many companies this means transforming from a culture of isolated silos in which managers serve as gatekeepers and powerbrokers to one of unified open groups in which a manager’s job is to assemble self-directing groups and to make sure that all the right people are involved from the beginning of a project. It’s a fundamentally different way of doing business.

    When it comes to realizing the promise of DevSecOps, tools are important. So are processes. But, the most important thing is to make sure that security is built into the fabric of the development life cycle, from start to release.

    DevSecOps will fill the missing link in the software development chain. It has to. There is little choice otherwise. Adhering to the most important principle of DevSecOps—to have security involved as an equal player from the beginning of the process—will go a long way toward ensuring that all software, from mobile and IoT to native cloud installations and mainframe instances, will provide the degree of safety and reliability required to serve the needs of users and companies in the digital economy of the modern world responsibly.

    — Bob Reselman

  • Threat Modeling: The Why, How, When and Which Tools

    Threat Modeling: The Why, How, When and Which Tools

    You may have heard of threat modeling as a structured activity for identifying and managing threats. Threat modeling can be applied to a wide range of things, including software, applications, systems, networks, IOTs and business processes.

    Threat modeling’s motto should be, “The earlier the better, but not too late and never ignore.” Without threat modeling, your security is a gamble—and in today’s business environment,  you’re sure to lose.

    When you design an application, you will face several security issues during different phases of the software development life cycle (SDLC), and so having threat modeling in the SDLC from the beginning can help to safeguard that applications are being developed, with security built in.

    Simply put, threat modeling is a procedure to identify threats and vulnerabilities in the earliest stage of the development life cycle to identify gaps and mitigate risk, which guarantees that a secure application is being built, saving both revenue and time.

    Why Threat Modeling?

    • It is better to find security flaws when there is time to fix them.
    • It can save time, revenue and the reputation of your company.
    • To build a secure application.
    • To bridge the gap between developers and security.
    • It provides a document of all the identified threats and rated threats.
    • It offers knowledge and awareness of the latest risks and vulnerabilities.

    How To Do Threat Modeling

    Many people think only security engineers can do threat modeling. That’s not true. Anyone, from developer to software project manager, can threat-model. In fact, I would suggest they should also know a little bit of threat modeling as part of their work.

    Let’s look at the elements of threat modeling:

    Assets: What valuable data and equipment should be secured?

    Threats: What the attacker can do to the system?

    Vulnerabilities: What are the flaws in the system that can allow an attacker to realize a threat?

    Steps to Threat Modeling

    Step 1: Identify the assets (database server, file servers, data lake stores, Active Directory, REST calls, configuration screens, Azure portal, authenticated and anonymous web user, Azure AAD client apps, database users, DB administrators)

    Step 2: Outline details of architecture on which the valuable asset is being processed. It may include the software framework, version and other architectural details (ASP.net web application connection to cloud data stores and third-party services using JWT tokens).

    Step 3: Break down the application regarding its process, including all the sub-processes that are running the application. We create a data flow diagram (DFD).

    Step 4: List identify threats in a descriptive way to review to process further.

    Step 5: Classify the threats with parallel instances so that threats can be identified in the application in a structured and repeatable manner.

    Step 6: Rate the severity of the threat.

    Threat Modelling Methodologies

    STRIDE (Uses application-centric approach)

    PASTA (risk-centric approach): Process for Attack Simulation and Threat Analysis

    TRIKE (risk-based approach with unique implementation and risk-modeling process)

    VAST (Visual, Agile and Simple Threat modelling)

    OCTAVE (focused on assessing organizational (non-technical) risks that may result from breached information assets.)

    When to use Threat Modeling

    In simple words, at the early stages of the SDLC, perform threat modeling:

    • Every time there is a change in the system’s architecture.
    • After a security incident has occurred or new vulnerabilities are introduced.
    • As soon as the architecture is ready.

    It is not a mandate to perform threat modeling at the early stages of the SDLC; you can still pick up threat modeling at any stages even if it is close to deployment.

    Threat models are continuously changing, and the models you prepared today may not be efficient tomorrow. And it is difficult to say that you are covered from all the threats. But if you have performed threat modeling and done whatever it takes to minimize your exposure to security risks, at least the impact of something very bad happening will be manageable (again, hopefully, but not a guarantee).

    Tools to Perform Threat Modeling

    I have used two tools for threat modeling, both of which are free to use.

    1. OWASP Threat Dragon
    2. Microsoft Threat Modelling Tool 2016.

    Let’s take a look at both the tools:

     

    Microsoft Threat Modelling Tool 2016         OWASP Threat Dragon

     
    Full version available for free (as of now) Alpha version available, flaws are still there. It is an OWASP incubator project, so it is at its early stage.
    Installable desktop application available. The tool comes in two variants: an online web application for GitHub and second an installable desktop application.
    Documentation easily available on Microsoft website. Default threat template is available. You have to search, default threat template is present
    I found the UX better, unique methodology available, the user can understand threats better. Guidance and feedback in drawing a model. Good UX. Fun and engaging user experience.
    Presently using this tool for threat modelling. Maybe I will use. I think will continue to improve.
    End-user documentation is available. End-user documentation is also available. Automated threats.
    Threat Grid, Template editor, Mitigating existing DFDs. Mitigating existing DFDs. Powerful threat mitigation. Rules have not yet been coded as it is the Alpha stage.
    Comes with a base set of threat definitions using STRIDE categories. Even in its current stage (alpha), you can create threats from those STRIDE categories.

     

    — Debarghya Pandit

  • Speed and Security Can Coexist in Mainframe DevOps

    Speed and Security Can Coexist in Mainframe DevOps

    DevOps teams face a constant tug-of-war in their daily work, balancing the need for speedy rollouts of high-performing (fast, reliable) applications that are secure also. If the team moves too quickly, an overlooked security vulnerability may make its way into production. If the team is not nimble enough to identify those security gaps, it can slow down the entire development process, hampering organizational agility.

    The need to strike this critical balance has led to the rise of DevSecOps, or the integration of security into DevOps best practices through automated techniques. Much has been written about the importance of bringing the mainframe fully into the DevOps fold, evolving the platform to keep pace with the speed of modern software development. But what about the security of mainframe code and mainframe data specifically—incorporating the mainframe into the third leg of the DevSecOps stool?

    A recent survey found that 72 percent of customer-facing applications are completely or very dependent on mainframe processing, which means there’s a lot of personal, sensitive information flowing through mainframe code and into mainframe data repositories. The mainframe platform itself is the most secure system on the planet, due in large part to its unique function and design. IBM’s new pervasive encryption is a groundbreaking development for enhancing data security on the mainframe even further, enabling data at rest (in traditional VSAM files and databases) as well as in transit to be encrypted at a pace of 12 billion transactions per day, all with no impact on system throughput speeds.

    Bulletproof Mainframe Security

    Still, highly personal and sensitive data can be compromised if steps aren’t implemented to ensure mainframe code and data are as inherently bulletproof as the supporting platform. What steps can help mainframe users achieve the conflicting goals of fast mainframe development combined with superior security?

    Privatized Test Data

    Speed is critical in all aspects of DevOps, including application testing. Mainframe transactions are the heartbeat of modern applications, making testing critical to ensure these components are working properly. Many organizations prefer using live, mainframe-based production data in testing, as this provides the most realistic view of how an application will work “in the wild.” However, in the rush to pull testing data, many organizations have fallen into sloppy practices including failing to disguise this data, which puts sensitive, personal data at risk of exposure. Companies needing to comply with the EU’s Global Data Protection Regulation (GDPR) face another risk—non-compliance—since they may be using customer data for a purpose (application testing) beyond that for which it was originally procured.

    Mainframe users can continue to use real production data in application testing, but they need to take special steps such as using pseudonism, which entails randomly scrambling certain values in a database (for instance, names) so that real customer names are disassociated with other personally identifiable information such as addresses or credit card information. Making it reasonably difficult to associate individual customers with their personally identifiable information is one way to achieve a higher level of information security for production data used in testing. Creating privatized application testing data sets must be a repeatable, automated process that allows testers to quickly get access to the test data they need to expedite testing processes.

    Credentialed User Auditing, User Role Management

    The DevOps concept entails greater frequency of code changes, which naturally leads to more testing and more developers and testers accessing data and applications. Unfortunately, the involvement of more team members, all working at a faster pace, can sometimes lead to carelessness and inadvertent and unintended security risks. There are techniques available now that allow organizations to see exactly what credentialed users did and what data was accessed. Some may view this as bordering on “Big Brother” type of behavior, but the fact is, with so much sensitive data continuing to reside on the mainframe and growing compliance requirements (GDPR, for example), such surveillance is vital to protecting both the enterprise as well as workers, the majority of whom have no ill intention.

    However, user auditing comes with an important prerequisite, and that is better management of user roles. “Least privilege” is a long-held security best practice of restricting access for users only to those resources absolutely required for them to do their jobs. The challenge is when workers change roles, they often are not removed from their previous role definitions and privileged access points, and simply given new ones. Since they may no longer need their old credential sets, this violates the least privilege concept and represents a significant security threat that auditing may not be able to fix. The benefits of auditing—in terms of fostering faster testing and overall development without compromising security—depend on strong user role management.

    Automated Rollouts/Rollback

    Automated rollouts make the process of releasing code into production faster and more efficient. A dwindling pool of mainframe specialists means that in many cases, workloads spend significantly more time being queued up waiting for available resources, than they do actually being implemented. Removing the need for a developer to manually push new updates into production can be a major benefit in speeding up the mainframe cog. However, approval layer and audit capabilities must be built-in to ensure code security has been tested and verified and the source of any potential problems can be traced back quickly and accurately. Automated rollback functionality is also critical in the event that a security flaw does make its way into production, by enabling developers to immediately roll back to a previous version of the software until the flaw is fixed.

    Much progress has been made in recent years when it comes to evolving the mainframe for DevOps, as several examples can attest. But given the sensitive personal data that is often running through, and residing in, mainframe code and data, the scope must expand to DevSecOps, and the steps described here represent a solid initial plan for getting there. Organizations that do this will enjoy the maximum benefits derived from a highly agile, secure mainframe environment delivering unparalleled scalability and reliability for its digital transformation initiatives.

    — John Crossno

  • Connectivity as Code: Making Network Security DevOps-Friendly

    Connectivity as Code: Making Network Security DevOps-Friendly

    DevOps is all about agility, with fast, short delivery cycles and automation for software development and applications. Enabled by recently introduced technologies such as virtualization, cloud and software-defined networking (SDN), spinning up new servers, provisioning storage in a public or private cloud or even launching whole environments can take just minutes or even seconds. But if that new application, service or environment needs a change in network connectivity or firewall rules to enable it to work, then the pace of delivery can often slow to a crawl.

    Unlike the typical DevOps scenario, in which developers create a CI/CD pipeline that includes running build processes and tests and delivering the new application completely automatically, provisioning new network connectivity usually involves a slow, laborious process. The application developer needs to manually open a change request and then wait for approvals and implementation of the new connectivity flow before proceeding with the DevOps flow.

    The Application Development Security Disconnect

    As part of this, the developer is usually required to provide information about firewalls, zones, subnets and other information related to the underlying network infrastructure in these change requests—information that is not always known or clear to the application developer. On the other hand, the application requirements and context are not always understood by the network security team assigned to implement the changes. This can result in back-and-forth communication between the developer and network security, making the entire process extremely long, error-prone, inefficient and frustrating to both teams.

    The challenge here is building in the necessary checks and balances to ensure that DevOps processes are not rapidly introducing security problems, while equally ensuring that security is not stepping on the brakes and slowing down the organization’s agility. So, how can this be achieved?

    The Solution: Connectivity as Code

    The answer is connectivity as code, a methodology that supports not only automation and agility in the application delivery process but also bridges the gap between application developers and network security teams on an ongoing basis, even after the application is deployed into production.

    Connectivity as code creates an abstraction layer that translates between the two worlds, giving application developers more control over their applications while helping network security understand the business impact of their day-to-day tasks, and thus ensuring business continuity.

    Establishing Connectivity Requirements

    In the first stage of this approach, the application developer describes the application connectivity requirements in a simple machine-readable text file, listing all the logical flows that represent these requirements, including those for the different application environments (e.g. test, development, production, etc.). It is presented as a list of abstract flows that typically include the source (who initiates the connection), destination (who accepts the connection), service and additional information.

    There is no need to know where the servers are located or what the underlying network topology is—such as whether there is a firewall between them or cloud security controls—or even their IP addresses or subnets. Furthermore, there also is no need to know whether connectivity is already available, because it’s also required by other applications.

    The Connectivity Phase

    Once this list is created, a new phase in the DevOps process, the connectivity phase, will automatically take care of things with no further involvement required from the application developer. The connectivity phase is where the actual connectivity provisioning and validation happens, leveraging a network security policy management (NSPM) solution to automate the network connectivity provisioning as part of the DevOps process just like any other configuration or provisioning step in the DevOps pipeline.

    The NSPM solution will read the file before automatically checking whether the connectivity requirements have changed. If no changes were made, the solution will verify that the required connectivity remains in place, and that the application will work correctly. This provides the application developer with the assurance that the necessary connectivity is in place and connectivity-related failures are not anticipated when moving into production.

    Automating Connectivity Changes

    If the connectivity requirements have changed, the NSPM solution will use the connectivity file to provision the required connectivity while retaining it for future reference, so that the application’s connectivity remains intact in the event of future network architecture changes or application or server migrations.

    If one or more of the required flows is currently blocked, a security policy change request process is triggered. Through this process a NSPM will verify that the new flows comply with the organization’s preapproved security policy, as well as security best practices and industry regulations, and will then design and implement the required changes directly on the different security devices on the network, automatically and within minutes.

    If, however, a change request is non-compliant, it will be escalated for approval and, once approved, it will be implemented automatically, thereby saving the developer the need to manually open an out-of-band change request.

    Furthermore, whenever a new version of the application is developed, this list of connectivity requirements is updated by the developer and the connectivity phase will ensure that the new flows are provisioned. With the connectivity phase completed, the DevOps process can securely proceed onto the next phase.

    The Benefits of Connectivity as Code

    Introducing the connectivity-as-code methodology into the DevOps process achieves a range of benefits. These include:

    • Seamless management of network connectivity: This makes DevOps process far faster and more agile, and enables problem-free application delivery, rather than as an external out-of-band issue that requires separate—and manual—handling.
    • Continuous compliance and auditability: Throughout the application delivery process organizations will remain fully compliant with all relevant guidelines, while all changes are fully logged for auditing purposes.
    • Business continuity: Application connectivity requirements are clearly documented and up to date, ensuring minimal disruption to the business even during network, infrastructure or architecture changes.

    Ultimately, connectivity as code bridges the gap between application developers and network security throughout the entire application life cycle, from planning and development through to deployment, production and decommissioning.  It ensures both developer and security teams get what they want: Dev teams don’t have to worry about security slowing them down, and security teams know that risk and compliance checks have been built in to the continuous delivery process, complete with a full audit trail of changes. By weaving network connectivity into the DevOps process, organizations can ensure fast delivery without any compromise in security or compliance.

    — Anner Kushnir

  • Best Practices for Application Security Testing in the Era of DevOps and AI

    Best Practices for Application Security Testing in the Era of DevOps and AI

    Application security testing is no easy feat. And yet, it’s usually the first topic that most articles about application security address. The reasons are simple: As the pace of application development techniques (and their inevitable vulnerabilities) evolve, AppSec personnel have found themselves caught between the desire to keep pace with their management of security testing requirements and their ability to allow the developer teams to operate in the modern, fast-paced ecosystem of DevOps and artificial intelligence.

    To better understand the best practices for conducting AppSec testing in the era of DevOps and AI, it is important to first appreciate the technologies available to us, that allow us to do so.

    At the heart of the modern application security testing,  there are five main technologies to be aware of:

    1. Static application security testing (SAST)
    2. Dynamic application security testing (DAST)
    3. Software composition analysis (SCA), third-party code
    4. Fuzzing
    5. Penetration testing

    These five technologies account for the bulk of most of the activities around application security testing. However, many aspects of application security testing are rapidly changing, including efforts to incorporate automation and artificial intelligence into the equation.

    By including automation or AI, for example, code testing is allowed to be released in rapid fire sequence, with production use approvals baked inline through automated logic and decision-making. This idea of continuous integration/continuous delivery (CI/CD) can lead to a widening of fractures between the security and development teams. Therefore, DevOps users today need the ability to program their code and test it through automated code scanning techniques before pushing the code into secure staging environments.

    To successfully conduct application security testing in today’s era of advancing developer operations through automation and artificial intelligence, there are three critical best practices to keep in mind.

    1. The Earlier, the Better: Introduce appSec testing into the software development life cycle early on for maximum results: Regardless of the type of testing being conducted, waiting until the very end of the development process will only create more work. Users will either end up with more bugs than they could feasibly fix or find themselves a part of an overworked AppSec team as they attempt to document and deliver on discovered vulnerabilities and code flaws. Statistically speaking, code changes that happen later in the development life cycle are also more costly to the business.
    2. Conduct testing of business-critical applications as often as possible: When deciding which assets are next in line for application security testing, one should consider the applications and systems that are of critical business value to the organization’s revenue stream. Think of these systems in particular as the “crown jewels” for the majority of attacker motives, since they define the amount of money a given organization will procure for that day and, if attacked, could disrupt the business in myriad other ways.
    3. Test for third-party code security and interoperability flaws as you would your own software: The growing complexity of modern applications means there is a need to leverage open source or third-party components. As this is the case, these components must also receive the same level of scrutiny as the applications in one’s own enterprise. All third-party code referenced in the software delivery process must also be checked by performing software composition analysis for security and interoperability flaws.

    While the pace and techniques for AppSec testing will undoubtedly continue to advance, and while there are some AppSec testing techniques that may never become obsolete, it is imperative to ensure that one’s system for maintaining application security testing always adheres to the best practices to preserve a secure software environment for the future.

    — Anthony Lauro

  • Survey Finds EV Certificates Impact User Confidence, Revenue

    Survey Finds EV Certificates Impact User Confidence, Revenue

    Do consumers notice or care when a site is more secure? Is it worth the extra cost for a company to invest in the more strenuously verified Extended Validation (EV) certificate? devopsy.kinsta.cloud conducted a survey to explore these questions and determine what, if any, impact an EV certificate has on consumer behavior and spending. The results are significant.

    What is an EV certificate? The “Learning to Trust Your Browser” report explains, “The EV certificate was created to address the weaknesses in the traditional certificate process and provide greater confidence in the websites you connect to. EV stands for ‘extended validation’ and refers to the much more strenuous and exhaustive process used to comprehensively verify the identity of the company or individual requesting the certificate.”

    We showed side-by-side mockups of websites to survey participants. One with a standard SSL certificate, and a duplicate website with an EV certificate. One was a banking website in a desktop browser and the other was a retail website in a mobile browser. We asked a series of questions about how users feel about internet security in general, and which website they are more or less likely to perform various actions on.

    Here are some of the key findings we discovered from the survey results:

    • For every measured behavior, a website with an EV certificate shows an uplift in user trust.
    • Half of the respondents indicated that the green address bar of the EV certificate websites has a significant influence on their perception of the brand or company.
    • Almost 60 percent of survey participants are worried about being the victim of an online phishing scam.
    • Nearly two-thirds of those surveyed stated that they feel slightly or much safer doing business with a site that is verified with an EV certificate.
    • The presence of an EV certificate leads to a higher probability that a consumer will share sensitive information, or be willing to complete a transaction online.

    Consumers are worried about security and there are a variety of concerns that keep them up at night. Will their personal health information be stolen? Will their social media accounts get hacked? Will their banking and financial details be compromised? Will their identity or credit card information get pilfered?

    More than 8 out of 10 of the survey participants are worried about these issues, which is why 91 percent stated they want to business with companies that invest in best-of-breed security solutions, and 96.3 percent indicated that they want to do business with companies that protect their confidential information. Based on all of that feedback, it should come as no surprise that they also revealed a significant preference for websites with an EV certificate.

    “There are two axioms that drive businesses—perception is reality, and the customer is always right,” according to the survey. “The results of this survey illustrate that an investment in an EV certificate plays a significant role in influencing customer perception and fostering trust. The increased consumer confidence has a direct impact on revenue and improves the bottom line for companies that use an EV certificate.”

    Check out the full report to learn more about consumer perception and the value of an EV certificate. Click here to download Learning to Trust Your Browser.

    — Tony Bradley

  • DevOps: Making the Development Cycle More Secure

    DevOps: Making the Development Cycle More Secure

    The promise of secure DevOps can be realized through security technologies such as dynamic authorization

    Fundamentally, DevOps is all about speed and agility. Customers expect companies to deliver and update applications at an accelerated pace and businesses must adopt modern technologies to meet customer expectations. With DevOps, organizations can implement a continuous development and deployment cycle to reap a multitude of benefits.

    Not only can organizations operate and evolve applications at high speeds with DevOps, but they also can do it more cost-effectively by automating all steps involved with software construction to avoid manually deploying code or configuration changes for each application.

    While speed and security are not necessarily enemies, if the security or access control technologies deployed are not in tune with a continuous deployment flow, the full promise of DevOps will not be realized. Waiting until the end of a development cycle to review security opens organizations up to security issues that could have been more easily resolved had security controls been implemented in the first place. Late discovery of security concerns also slows down the process—which is, of course, counter to some of DevOps’ primary objectives. To obtain the full potential of DevOps, organizations must ensure that security controls, such as externalized authorization, are an integral part of the security process from the very beginning.

    The Importance of Security Controls

    Security controls can proactively and consistently address different security aspects across the enterprise. A continuous integration/continuous deployment (CI/CD) cycle is a critical piece of the DevOps process; it implies that the application environment is potentially changing at any moment and possibly on a frequent basis. With constant changes to the production environment, it is critical to ensure that security controls are a part of this process—hence, the term “DevSecOps.”

    If security processes are not part of the overall process, then you risk the chance that security controls have not been vetted properly or consistently enforced with every new release or new application/API/microservices. However, the security controls must also conform to a DevOps approach, meaning they must fit into a model that is streamlined via automation to be deployed and managed in a manner much like modern-day applications.

    Conforming to a DevOps approach can have different perspectives. What we are focusing on here is to suggest that security and identity services should be deployed and managed in the same manner as your application code. Cloud-native capabilities, clearly defined interfaces, REST and JSON enabled interfaces and containerization are some of the characteristics that make security and identity services look and feel like the business applications and services.

    Integrating the Right Security Controls

    To realize the full benefits of DevOps, organizations must deploy security or identity management technologies that are in sync with a continuous deployment/integration cycle. If identity and access management (IAM) systems cannot be deployed and managed in the same manner as your APIs and microservices, then it makes the DevOps process more cumbersome and less streamlined.

    One technology to consider is externalized dynamic authorization delivered with attribute-based access control (ABAC). With dynamic authorization, users are authorized access to resources based on attributes. Authorization is then determined dynamically at runtime by evaluating centrally managed rules and policies.

    With dynamic authorization, you can automate policy changes the same way you can automate code changes. In addition, the ABAC service itself can be managed like a microservice, giving it the same flexibility, deployment and automation characteristics as your application microservices. Ultimately, the life cycle of redeploying the application and security components can be fully automated. Similarly, any changes to policies can also be part of the automation process. Furthermore, you can automate the activation of additional authorization servers for peak load conditions and remove them when less capacity is required.

    With an automated approach you can relieve pressure on developers, because they no longer will have to write security rules into their code. In addition, access rules are enforced consistently across applications, APIs, microservices and data resources, reducing the risk of overexposure to information and security breaches. This also means that your developers can spend their time on business functionality, not worrying about access security.

    Security technologies such as dynamic authorization are a critical part of the DevOps process. With dynamic authorization embedded directly into the development cycle, organizations can automatically address a wide variety of security aspects across the enterprise and ensure a continuous and secure development cycle.

    — Gerry Gebel

  • Integrating Blockchain and DevOps

    Integrating Blockchain and DevOps

    Blockchain is one of today’s hottest technology buzzwords. And at the same time, the concept of DevOps has achieved acceptance and is gaining momentum. Blockchain and DevOps already offer a number of benefits individually. Together, they can provide significant tactical and strategic advantages. However, some challenges must be overcome simply to adopt blockchain, as well as to successfully merge blockchain and DevOps.

    What is Blockchain?

    Let’s start with an overview of blockchain. Many people mistakenly conflate cryptocurrency and blockchain, because many of the key features of cryptocurrency are a function of blockchain. But blockchain is a separate and unique concept that has applications and benefits far beyond cryptocurrency.

    Blockchain is a distributed account ledger, the use of which enables data to be processed and stored securely. Blockchain relies on three core concepts—peer-to-peer networks, public-key cryptography and distributed consensus that is based on the resolution of a random mathematical challenge. Reliance on these three concepts allows blockchain transactions to be secure and relatively anonymous. Every transaction is recorded in the ledger as a data block that is appended to the end of the chain of previous transactions. No group or individual owns or controls the ledger, and all parties can view the chain of transactions, ensuring transparency and integrity.

    A number of key features make blockchain attractive. Data is validated across all participating nodes, which eliminates the need to reconcile transactions. The use of distributed consensus provides a high degree of confidence, but transactions in the chain also can be verified easily. Blockchains are immutable—new data can be appended, but blocks of data already in the chain cannot be modified or removed. Finally, blockchain reduces costs and improves the efficiency of processing transactions and storing data due to its decentralized architecture.

    The challenge facing organizations wanting to adopt blockchain, however, is how to incorporate it seamlessly with DevOps development processes and culture.

    DevOps for Blockchain Development

    Organizations need to address challenges in three major areas to take advantage of blockchain: culture, process and tools.

    On the culture front, the success of blockchain depends on support at the executive level as well as adequate budget and resources for proper implementation. If you can’t find champions within the organization to drive the blockchain cause, your project is doomed before it starts.

    Whether you’re building a blockchain within a single company or a blockchain network that includes nodes outside your organization, obtaining widespread agreement on the technology and blockchain processes can be an issue. The absence of widespread industry adoption or any sort of standardized tools or processes adds complexity.

    Finding the right talent can also be a problem—and once you find it, you may have to pay a premium to obtain it. According to a recent article in TechCrunch, “Blockchain-related jobs are the second-fastest growing in today’s labor market; there are now 14 job openings for every one blockchain developer.”

    From a process perspective, blockchain is an emerging concept that lacks mature management principles or design standards. The process framework, and the different roles involved, are still unclear. Most organizations lack expertise concerning the blockchain application stack and environment; in addition, the metrics that should be monitored to measure efficiency and performance are not yet well-defined.

    The absence of development tools is another major hurdle for blockchain. The developer tools currently available for the blockchain ecosystem are unreliable. The blockchain ecosystem still needs an integrated development environment with good linters and plug-ins, a build tool and compiler, a deployment tool, documentation, testing frameworks, debugging tools, logging tools, security auditing and analytics. While some versions of these tools exist, they are not yet adequate to meet the needs of blockchain developers.

    It is also important to understand that, although many blockchain implementations are based on open source technology, blockchain isn’t free. Keeping track of transactions requires hardware, networking bandwidth, electricity and processing power. Because a blockchain ledger is distributed, transactions aren’t just processed once—they are processed on every node in the blockchain network. As a trusted network grows, the associated costs skyrocket. These expenses can be a barrier that prevents smaller organizations from experimenting with the technology.

    Integrating Security into DevOps

    If you are thinking about implementing blockchain, some of the core principles of DevOps—specifically DevSecOps—come in handy. DevOps is built on the concept of breaking down silos within an organization and enabling each team and individual to take responsibility for the project as a whole, rather than separating tasks by role.

    To implement blockchain successfully, you need a system that rewards innovation and supports teams of individuals who work together to address any issues. Integrating DevOps and security fosters stronger application security throughout the software development life cycle and helps with blockchain development efforts as well.

    The shift-left philosophy and the push for automation are DevOps principles that also will serve you well with blockchain. Integrating security earlier in the life cycle—shifting left—and incorporating automated security testing and security bug tracking are essential. The blockchain network needs to be tested for performance and latency, which will vary depending on the size of the network, the expected transaction size, the consensus protocol used and the associated required latencies. It is also important to determine whether the integrity of the network and the shared blockchain ledger is maintained while testing throughput.

    To maximize efficiency and productivity, put processes in place that allow you to consistently monitor and adjust, based on feedback. Track individual and overall security vulnerabilities, the amount of time it takes to detect them, the amount of time it takes to remediate them, and other factors relevant to application security. These metrics should be visible to every individual so that each can understand and take ownership of the appropriate elements.

    Blockchain and DevOps

    Blockchain technology is poised to change the way business is conducted today due to its promises such as of secure, immutable, peer-to-peer decentralized trust networks with distributed consensus, shared account ledgers and smart contracts.

    These same advantages, however, introduce a host of additional considerations to blockchain-based applications and make for greater testing challenges. Not only is the change in technology significant, significant changes are also necessary from a business process standpoint. While blockchain applications will have to go through standard testing and validation, including functional testing, integration testing, security testing and performance testing, they also will require additional specialized testing for smart contracts and peer/node testing.

    DevOps practices can provide great value to organizations under pressure to become more customer-centric and innovation-focused. The efficiency, quality and consistency that adopting DevOps provides is exactly what is required for traditional organizations looking to embrace the leading-edge technology known as blockchain.

    — Tej Aulakh

  • DevOps Chat: How Cyxtera Uses DevOps to make AppGate SDP Better

    DevOps Chat: How Cyxtera Uses DevOps to make AppGate SDP Better

    In this DevOps Chat, we speak with Kurt Glazemakers of Cyxtera. Kurt is the CTO of the Software Defined Perimeter group within the security and analytics group at Cyxtera. Kurt discusses how his group uses a DevOps approach to making AppGate SDP better and how that, in turn, makes it better for DevSecOps-enabled organizations.

    In case you are unfamiliar with Cyxtera, it is the company that resulted from the acquisition of 57 data centers and the co-location business of CenturyLink (which then used that money to complete its acquisition of Level 3), plus the acquisitions of Cryptzone, Catbird, Easy Solutions and Brainspace. The company brands itself as the “secure infrastructure company” and is now one of the leading co-location players globally. Managed by most of the former senior management team at Terremark, which itself was acquired by Verizon (Oh, what a tangled web we weave in the tech world), Cyxtera is now something like a $2.8 billion business.

    During our chat, Kurt gives us some great insight into how DevOps, automation and CI/CD have helped make Cyxtera’s product better. As usual, the streaming media of our conversation is below, followed by the transcript.

    Audio

    Transcript

    Alan Shimel: Hi, everyone, it’s Alan Shimel and you’re listening to another DevOps Chat. Today’s DevOps Chat has a distinctly DevSecOps/security bent to it, and I’d first of all like to welcome my guest, Kurt Glazemakers of Cyxtera. Kurt, welcome to DevOps Chat.

    Kurt Glazemakers: Hey, Alan. Hi.

    Shimel: Thanks for being here, Kurt. So Kurt, let’s start off with this first. What’s your title over at Cyxtera?

    Glazemakers: I’m the CTO for our Secure Access product families, so I’m basically managing the whole development themes and the product for our Secure Access product family in Cyxtera.

    Shimel: Excellent. And among the Secure Access products that Cyxtera is offering is something called AppGate.

    Glazemakers: Yes, that’s correct. 

    Shimel: Give our audience a little background. What’s AppGate about?

    Glazemakers: So AppGate is a tool that’s based on some of the fundamental principles of zero trust, to provide clients, wherever they are – in the office, in the airport, maybe in a Starbucks – secure access to their core applications and in such a way that the applications are securely accessed wherever you are and from whatever device you have. That’s basically in a nutshell what it does. It _____ a wide network _____.

    Shimel: Got it. And Kurt, you know, bigger picture, Cyxtera, give me if you can, our listeners a little background there.

    Glazemakers: Well yeah, sure. So Cyxtera is pretty new in the market. We’ve existed exactly one year and 25 days today, so it’s pretty new. And it’s an acquisition of 57 data centers that we acquired from CenturyLink, and where we added security software in order to provide secure _____ and hosting _____ _____ .

    Shimel: Excellent, excellent. So is AppGate – I imagine it’s not offered just to your datacenter customers, or is it?

    Glazemakers: No, actually AppGate came from one of those software acquisition teams, so we actually are widespread. We have widespread customers all over the world, actually. But most of the data center customers have a need for it, because they need to access their own data center _____ _____ requirements. Maybe they have access needs in the cloud, like the _____ clouds of this world, like the 80S or the ____ of this world. And with AppGate you can actually accommodate all of them with one solution. And with our footprint in the data center we can even offer it as a secure access service to our customers. So that’s a combination of the software and the data center footprint, which makes it very interesting from that perspective.

    Shimel: Got it. So we’ve got the groundwork laid, Kurt. Let us now jump into what you and I really want to talk about, and that is that, you know, Cyxtera and the AppGate team have been on their own DevOps journey, their own DevOps transformation in how you’re actually developing and continue to develop AppGate as a product. And what’s really kind of unique about it – it’s like one of those Russian dolls where it’s a doll within a doll within a doll – is you’re using DevOps to help develop a product that helps DevOps. Right? Other DevOps _____.

    Glazemakers: Yes, that’s actually correct.

    Shimel: Tell us.

    Glazemakers: Yeah, so what AppGate basically does, it provides secure access to applications, but the applications are dynamically discovered and added to the network, which is a real DevOps case, right? If you spin up an environment and you want to connect to that environment, even if it’s only lost for like a few minutes, AppGate is able to detect that and basically provide access in the moment that the environment is live. And when it’s gone, all of the access rules are gone as well. So it is nakedly a DevOps-driven security technology, which helps a lot of or actually most of our customers already in a public cloud or DevOps style of company, as a majority. Also we have enterprise customers, but this has actually been very well adopted in the DevOps _____. Yeah, so it definitely is a doll in a doll from that perspective, for sure.

    If I go back to where we started, I started these tools about four years ago. And the reason why DevOps for us was so important is, first of all, it’s a network security product, which is very, very complicated in testing, because it requires a lot of security skills, a lot of networking skills and also software testing skills, which makes it very hard to basically perform the amount of testing in _____ hours, to give quick feedback to the user side or to the developer, in this case. So one of the things we’ve done in the very first place is we really spend a lot of time on creating our own tools, and that actually took even more than a year or a year and a half, to transform what, at the time when I entered the organization, was a more traditional way of developing with a developing process, a QA process, a delivery process. And that process was too slow and didn’t get or give the right outcomes.

    So the first thing we’ve done – we spent about one and a half years on only developing the automations and the DevOps _____ _____ case. So yes, that’s where we spent a lot of time and actually that’s also helped us in gaining a lot of efficiency in the dev team after _____ _____ _____ in this case.

    Shimel: Excellent. So Kurt, you know, we’ve spoken to several – more than several. We’ve spoken to a lot of organizations that have kind of undergone their DevOps transformation. If you can, share with our audience, how did this come about? Was it top-down, bottom-up, middle-out? You know, whose bright idea was it to do DevOps here?

    Glazemakers: Yeah, okay. I think you need actually a little bit of both, right? So when I entered the company, I had some experience in the past and I really wanted to bring it to the same level, because first of all, the QA profiles are very hard to find and they don’t have the same throughput than if you do it in a proper DevOps way. So I definitely wanted to put guidelines in here, but you cannot do it if you don’t have buy-in from your own devs right now. And these devs were immediately onboard and we started actually as a _____. So basically I would say this is a top-down and a bottom-up approach at the same time.

    But that definitely brings challenges, because if you go from a traditional way to a new way, it means that certain people probably will not be a fit in the reorganization, right? So if you have too many people that have never been a coder, that actually brings challenges on their skillsets. So that was not the easiest way to progress in the organization, but once everyone saw the benefits, I think we really shifted from a traditional-driven organization to a full DevOps and really a _____ _____ _____ organization. We did it in that year and a half I was talking about. So yes, that’s the guideline. But you need buy-in from both your developers as well as the management team, in this case.

    Shimel: Excellent. And now, Kurt, since you’ve moved to a DevOps sort of framework here, have you guys done any sort of ROI or any sort of analysis as to what – I mean, because one of the things that we always see with DevOps is it just feels that it’s better, right? We’re doing it faster; quality seems a little higher. But have you actually done any benchmarks or metrics that really get to that?

    Glazemakers: Yeah, that’s actually a very good question. Actually it’s always hard to measure exact benchmarks, but if you look from an overall perspective, before, we were literally doing maybe one release every year, and that shifted almost to a multi-year release when this was adopted, which is a huge difference in this case. And the way we release is typically we have some quarterly release that contains all of the new features and then a monthly release which contains smaller fixes and patches. But what the biggest outcome was for us in this case is, by having a quarterly release and these smaller releases, it’s very easy to follow up with your customers on requirements.

    Especially in the beginning when AppGate was the complete new concept. So it’s _____ _____ _____, and you need to convince customers. At that very, very early stage, “Yes, it’s great, but I need this feature or whatever before I can work.” And if you can actually deliver that by the end of the quarter and even prove to the customer it actually works, that definitely helps driving sales and getting the numbers in, in the quarter. So I would say from that perspective it’s not only about releases but the fact that we were so dynamic and were able to convince customers. To inject a last missing feature before they could sign a deal is probably the most visible item that even _____ _____ _____ by sales or management. Because you are actually fulfilling needs from a customer at a much faster pace in each case, which results in better financial results and more happy customers as well 

    Shimel: Excellent. Excellent. So what’s been the feedback? You know, as you said, it makes for happier customers and everything else, but let’s concentrate on your own internal development team. What’s the feedback been from them?

    Glazemakers: In the beginning, a little bit skeptical, because you need to do all this move and the work and also you don’t involve the right group files. The nice thing is, what happened is, when they start to see the power of a properly-done DevOps file – and actually we have a little bit of a benefit with our product, because we’re not only leveraging DevOps as the _____ _____, making sure that we have all of these automated tests _____ _____ feedback, but we’re also using always our latest code base to basically upload the codes and to work with it. So even the code right now, I’m actually using the latest version at this moment, through a secure _____, to basically provide _____ _____. So you see that you immediately get feedback from that perspective.

    So the first thing that we really saw beneficial for the devs is that they get very, very quickly feedback, to see how the software performs. But secondly, also when we were _____ _____ the organization – you get a lot of new talent in and the new talent is typically a little bit shyer, because if they commit something and it breaks a process, then you get – that’s not how you want to start in a new company. And with this DevOps style, where people cannot commit code before it went to the test _____ and before it can be merged and all of those things, you have first of all a very strong development process, which is not followed by developers, because they hardly feel there’s any process. And so it gives the developer at the same time a lot of freedom and a lot of trust in whatever code they produce.

    And those three elements are incredibly key to raising the amount of efficiency, because people are not blocked because someone has entered the wrong code that actually breaks the builds. We have a lot more freedom to basically optimize or _____ _____ certain codes in the products. And last but not least, also from a security perspective, you need very, very tough certification sometimes, even if you are producing for government agencies and those kind of things. And that automation also provides a lot of feedback there, positive feedback, for the certification process, because everything is automated and enforced by the DevOps system as well in this case. 

    Shimel: Mm-hmm, excellent. So Kurt, I told you the time goes so fast. We’re almost out of time. But I wanted to talk a little bit about the other side of the house, which is, how are customers using this to help their own DevOps initiatives and their own DevOps development and deployments?

    Glazemakers: Yeah. Yeah, that’s actually a very good question. Yeah, what you have with DevOps environments is, when you’re deploying in DevOps environments, you basically always typically want to deploy and actually forget about it, unless there is an issue when you want to go in. And this is typically administrative access for the development outside the system. And in a real production environment, in a DevOps environment, you really, really want to have strict, strict controls of that. And we have a lot of customers, for example, that maybe _____ _____ _____ that actually have this kind of discipline. And what we were able to provide was when they – even when it’s their own dev environment and they test, or if it’s a production environment, we can actually enforce different layers of access in this case. Maybe for the public environments you need two-factor application and a company-approved device in this case, or a security device that has all of the endpoint protection software and stuff like that running. And maybe for the DevOps environment itself, where all they’re doing is pre-tests, we might be a little bit less restricted. So normally like a normal device, “Okay, it’s just _____ _____,” and you’re able to access without – with just login and password, as an example.

    The nice thing is, what our software does, it can actually provide both of these things at the same time. And also, when the environment is being sped up, the metadata that you provide by creating the environment can be used as the security mechanism. And this is really where we bring a lot of value for customers. Because if you have a DevOps environment that changes all of the time – changes IP addresses, changes operating systems and all of those things – even if they’re lost for maybe 10 or 15 minutes, we can automatically detect those and be able to provide _____ _____ if needed. If they have an open ticket or whatever, we can all combine those elements. And once that is received, we also have a proper _____, the records for which developer has access with the system, even if the system doesn’t exist anymore.

    And that has been a great value for DevOps, especially in the financial world where DevOps becomes now _____ _____ _____ interesting. Financials are seeing the need that they need to develop at a higher pace, so they’re embracing DevOps. But at the same time they are very, very highly regulated, and that doesn’t change. And what we can do with our software is really provide the same or even sometimes better control of these regulations at the same time they keep their agility on the DevOps process _____ _____ _____.

    Shimel: Got it, got it. So Kurt, as I mentioned, time does go fast. We’re running out here. But just last question – what’s the future look like with this?

    Glazemakers: Well I have no idea what it will look like, but the way I see the adoption right now, the way I see the need for DevOps and actually the DevOps embraced in many companies these days, I’m pretty sure that the old way of securing clouds or virtual environments, using a primitive _____ defense or _____ _____, it’s too dynamic ______. There are too many hacks going around. And so from our approach, I would say this is definitely a completely new way of securing DevOps environments and, they’re also the first signs of _____ DevOps are on the horizon right now. And this is a fit. I think the first product that really takes into account whatever security _____ _____ _____ DevOps environments is immediately enforced on the network, all the way down to the user device. And that basically extends whatever you’re programming in your DevOps environments, to make sure it’s always secured down to the device of the user itself.

    And I think that is going to be a huge driver of better security, but also in a much more dynamic security type of approach, which – DevOps has done a lot of great work on deployment and infrastructure. The network and security elements didn’t go as fast, and I think this is probably one of the next new waves that will drive that and maybe be even more secure than traditional environments using the dynamic approach _____ _____

    Shimel: Okay. Excellent. Well, that was a great kind of insight, Kurt. I appreciate it. We’ll be looking – you know, a year? What did you say, a year and 30 days or so?

    Glazemakers: Yes, that’s exactly – a year and 25 days. That’s how old Cyxtera is right now.

    Shimel: Well, continued success and we’ll be watching Cyxtera’s growth. Thanks for being our guest today on DevOps Chat, and we hope to have you back on again soon.

    Glazemakers: Thank you very much as well, and have a great day. 

    Shimel: All right, Kurt Glazemakers, CTO for Secure Access for Cyxtera joining us today. This is Alan Shimel, and you’ve just listened to another DevOps Chat. Have a great day.

    — Alan Shimel