Author: Tony Bradley

  • The Best Approach to Help Developers Build Security into the Pipeline

    The Best Approach to Help Developers Build Security into the Pipeline

    Speed and agility are at the core of digital transformation and DevOps culture, and have quickly become a business imperative for organizations that want to remain competitive. Speed cannot come at the sacrifice of security, though. The pace of software development requires that security be baked into the code from the start rather than tacked on after the fact. Developing secure code fast requires empowering developers with the skills and tools they need and building security into the DevOps pipeline.

    Embracing DevSecOps

    DevOps culture and the drive to work faster and more efficiently affects everyone in the organization. When it comes to creating software and applications, though, the responsibility for cranking out code and producing quality code falls on developers.

    The pace of DevOps culture doesn’t allow for anything to be an afterthought. It’s important for developers to support security directly as a function of application development in the first place, and to operationalize security within the continuous integration/continuous deployment (CI/CD) pipeline.

    Unfortunately, traditional education does little to prepare them. It’s possible to get a PhD in computer science and never learn the things you need to know to develop secure code. As organizations embrace DevSecOps and integrate security in the development pipeline, it’s important to ensure developers have the skills necessary. You also need to focus on both the “why” and the “how” in order to build a successful DevSecOps training program.

    Don’t Just Check the Box

    Not all training is created equal. Consider why you’re doing the training and the outcome you hope to achieve rather than doing training for the sake of training. Many organizations focus on training developers in secure coding practices from the perspective of compliance. It’s crucial to engage developers in a meaningful way, though, and not just check a box.

    Many compliance frameworks, such as PCI-DSS, require ongoing application security training, but compliance training often reinforces the wrong lessons. Developers learn the most expedient way to check the box and achieve compliance rather than learning the most efficient way to develop secure code. This approach also causes developers to feel like the security team looks down on them or doesn’t understand the challenges they face or the expectations they have to meet.

    The Carrot and the Stick

    How you do security is also important. Training works better when developers feel like they are part of the process and when they have a reason to want to excel.

    For nearly everyone, doing something in practice reinforces lessons better than just reading content or listening to a webinar or video. Interactive labs are more engaging and provide feedback as developers go through the training. They can practice writing secure code with guided practice that is self-paced. They can also get hands-on experience exploiting vulnerable applications, then patching them back up.

    You should implement developer training that creates incentives for developers by gamifying training. Create custom Capture the Flag events, track individual progress and provide a leaderboard that enables healthy competition among the developers.

    You also want to provide developer training that is relevant to your organization’s preferred coding languages and business objectives. The training should teach skills and strategies that are applicable to the code your developers work with and give them tools they can use immediately to improve the security of the applications they’re working on.

    Speed is essential for businesses to maintain a competitive edge today, and security is more important than ever. Make sure you have the training in place to help shift application security knowledge left and integrate security to mature DevSecOps practices.

  • Better Apps and Better Security When You Shift Left

    Better Apps and Better Security When You Shift Left

    Tens of thousands of people and hundreds of cybersecurity vendors descended on San Francisco at the end of April. While the RSA Conference was the primary draw, there are a number of peripheral events that go on throughout the week as well, such as the Cloud Security Alliance Summit, the CIO/CISO Interchange, BSides San Francisco and the Qualys Security Conference.

    I was able to attend some of the Qualys Security Conference and I had the opportunity to see Alex Mandernack, security solution architect for product management at Qualys, presenting on the need to shift left when it comes to cybersecurity.

    Mandernack outlined some of the issues organizations face today when it comes to security. Migrating to the cloud and embracing DevOps culture means more ephemeral, elastic environments and compressed development time frames. He pointed out that these trends make security more challenging, but also described the opportunity they present to change our approach to streamline and improve security.

    The Traditional Pipeline is Broken

    The traditional model of application development is much more linear. Each app team builds their own image—often in a silo or vacuum disconnected from other teams. Penetration testing is conducted on a sporadic or infrequent basis, and eventually the app is deployed. Vulnerability scans are run on the app in production, and issues or deficiencies are reported back to the developers to address or incorporate into the next build.

    The process is slow and cumbersome. It also has the potential to introduce redundancies that waste resources and make the organization less efficient. As companies embrace DevOps and move to the cloud, the traditional development pipeline simply doesn’t work—especially not for security.

    DevOps, and Cloud, and Containers — Oh My!

    The cloud and DevOps fundamentally change the development lifecycle. Development time frames are compressed, and the process is a self-feeding, iterative circle rather than a repeating linear approach. The traditional approach of identifying and resolving security issues after an application is deployed won’t work in a DevOps environment because by the time issues are identified and fixed, the app itself may have already moved on to the next version.

    Cybersecurity and the development pipeline have enough challenges with the cloud and DevOps, but there is also a newer technology trend that exacerbates the problem—containers. Containers are designed to get code quickly and to operate fast. They are also built for scalability—spawning and spinning down hundreds or thousands of containers constantly to keep pace with demand.

    There is a diverse array of tools and platforms associated with cloud, DevOps and containers. Organizations often employ a complex collection comprised of some combination of AWS, Azure, Docker, Kubernetes, OpenShift and others. The result can quickly become a black hole when it comes to security—which is why it’s important to push security left into the CI/CD pipeline.

    Shift Left to Help Security Teams Do Better

    In a DevOps culture, developers and security teams need to think about security sooner. It’s important to get the security tools into the process earlier. Thankfully, with the DevOps lifecycle and the tools commonly used within a DevOps environment, it can be done.

    For starters, companies should build a golden image. Developers shouldn’t have to patch and update the base operating system before they even start developing. The golden image takes a baseline operating system such as Ubuntu or CentOS, and completely patches and configures it so everyone has a standard, consistent image to develop on.

    With the golden image in place, the next step in shifting security left is to implement testing and scanning in the CI/CD pipeline. Put vulnerability information at the fingertips of developers as they’re developing and implement vulnerability gates in the pipeline to ensure that applications that don’t comply with policies and meet minimum requirements are not allowed to be deployed.

    New Role of the Security Team

    Part of shifting security left includes providing tools that make security self-service for the DevOps team. Automating actions with scripting, APIs and CI plugins ensures that security is simplified and streamlined to provide value for developers.

    In this shift left scenario, the security team has to redefine its role in the process. The security team is still vital, but rather than being the police or a roadblock in the development process, the role of security focuses on verifying and auditing the process. The security framework should have dashboards and live data that enable the security team to monitor activity and identify trends that may need further attention.

    Better Security, Faster

    There is often conflict between developers and security teams, but there doesn’t need to be. Mandernack stressed that developers don’t want to create insecure apps either.

    Shifting security to the left into the CI/CD pipeline streamlines the whole process. Ultimately, the result is higher quality, more secure applications that are developed faster.

    — Tony Bradley

  • The Road Ahead for Security, DevOps Transformation

    The Road Ahead for Security, DevOps Transformation

    Qualys hosted its Qualys Security Conference 19 this week in Las Vegas. Hundreds of attendees from around the world have gathered at the Bellagio hotel to learn more about the current state of cybersecurity and what the future has in store. As you might expect, given the technology landscape today, many of the sessions and discussions have revolved around DevOps and how cybersecurity can adapt to DevOps culture.

    Scott Crawford Qualys Security Conference
    Scott Crawford, Research Vice President at 451 Research presents “The Road Ahead for Security, IT, and DevOps” at the Qualys Security Conference

    The Shifting Technology Ecosystem

    Scott Crawford, research vice president at 451 Research, opened day two of the Qualys Security Conference with his keynote, “The Road Ahead for Security, IT, and DevOps.” Crawford talked about the dramatic changes over the last decade or so—from monolithic to microservices, from standalone applications to integrated software, from Waterfall to Agile, enterprise networks to IoT / OT, from standard networks to 5G wireless, and from traditional IT to DevOps. He discussed the challenges organizations face and the dilemma of doubling down on past success and missing out on innovation.

    With all of the changes from this shifting technology ecosystem, there are consequences. Organizations no longer have a single point of control and IT teams are faced with managing and protecting an increasingly complex web of interconnected platforms, applications and services.

    Security and DevOps

    Crawford also talked about the rise of zero trust. He described it as a sort of mashup of the concept of least privileged access, combined with behavioral analytics and an on-demand, just-in-time approach to managing access. The zero trust paradigm is based on the premise of never trust, always verify—and that means determining who is requesting access, under what conditions they’re requesting access and what actions they intend to perform with that access on a case0-by-case basis.

    He shared the Xebia Labs Periodic Table of DevOps tools to illustrate the overwhelming number of options available and stressed the importance of automation. CI/CD (continuous integration/continuous deployment), RPA (robotic process automation), and SOAR (security orchestration, automation and response) solutions have been developed to help address and manage some of the complexity of both DevOps deployments and cybersecurity.

    Xebia Labs Periodic Table of DevOps Tools
    Xebia Labs Periodic Table of DevOps Tools

    DevOps and Digital Transformation

    Crawford’s keynote was followed by a presentation titled, “The DevOps Transformation of the Qualys Platform: Lessons Learned.” Dilip Bachwani, senior vice president of engineering and cloud operations for Qualys, talked about how the company has addressed the “innovator’s dilemma” and steps it has taken to deal with growing pains as it goes through its own digital transformation.

    Bachwani explained that the engineering team at Qualys has expanded exponentially in a relatively short period. That comes with several benefits in terms of how quickly they can develop and implement new solutions, but the team also faced challenges with balancing that growth and trying to maintain velocity at the same time without sacrificing stability or reliability.

    Just like every other organization going through a DevOps transformation, Qualys has had to break down silos with people, processes and tools. Bachwani explained that they needed to do things differently to automate as many functions as possible. They decided to view infrastructure and operations as software problems and find ways to fully automate deployment and configuration.

    He also emphasized that security must be built in throughout the DevOps life cycle. Qualys adopted a hub-and-spoke DevOps model and developed a robust DevOps toolchain designed to combine and orchestrate an effective set of tools for developing, delivering and maintaining software. Having a standardized toolchain ensures that there is a common platform available to everyone.

    Accelerating Transformation With Citizen Developers

    At the end of Crawford’s keynote, he talked about the lack of people with the right knowledge and skills. Cyber Security Ventures predicts that there will be 3.5 million unfilled cybersecurity jobs by 2021. That’s just cybersecurity. What about developers and other key personnel? Crawford posed the question, “Where will we find the people to do it all?”

    The answer, he said, is citizen developers. What is a citizen developer? It’s a movement to empower employees who are not developers by trade with the tools and support to implement ideas. They are the ones closest to the problem and, arguably, best equipped to understand how to solve it. They don’t need to be professional developers or need experience with coding environments. Low-code and no-code platforms give them the power to turn ideas into solutions.

    A few years ago, George Hulme wrote an article on the growing citizen developer movement. Hulme noted, “The organizations that succeed with citizen development will be those that wholeheartedly embrace the movement and cultivate it, with IT’s help and guidance.”

    The DevOps revolution isn’t going away. Companies that don’t embrace digital transformation will likely fade into oblivion as they are left in the dust by more innovative competitors, and organizations that don’t figure out how to integrate security into the fabric of their culture will struggle against a rapidly expanding and evolving threat landscape.

    At this point, these things are like the ocean tide. It is coming whether you like it or not, and it will destroy those who are not prepared. Crawford wrapped up by asking the audience to consider what their role is going to be in building and maintaining the future of DevOps and cybersecurity.

    — Tony Bradley

  • Privileged Access Management at the Speed of DevOps

    Privileged Access Management at the Speed of DevOps

    Privileged access management (PAM) is clearly a very important element of effective cybersecurity. PAM has been ranked number one on Gartner’s Top 10 Security Projects for two consecutive years, and it is number four on the CIS Top 20 Critical Security Controls. The struggle for many organizations, however, is they have also embraced DevOps culture, and the traditional approach to PAM clashes with the principles of a DevOps environment. Thankfully, it is possible to effectively manage privileged access in a DevOps environment—it just takes a new approach.

    Challenges of Privileged Access Management

    Despite advances in identity and access management and the existence of things like two factor or multi-factor authentication and biometric authentication, most organizations still rely on a simple username and password to authenticate an individual and grant access to network resources, applications and data.

    The concept of least privileged access—ensuring that users only have access to things they really need access to—has been preached since the dawn of cybersecurity and, when done right, can be an effective strategy. The problem is it’s tedious to do right and it’s very easy to lose track of who has privileged access to what.

    That’s where a PAM solution comes in. The whole point of privileged access management is to provide a way to track and manage who has access to what—to grant access when it is needed and revoke access when the need no longer exists. Unfortunately, there is a lot of confusion about PAM and the effort to manage privileged access is challenging for many organizations.

    Enterprise Management Associates (EMA) conducted a survey on the state of privileged access management. The survey included responses from companies representing different company sizes and industries around the world and focused on IT and cybersecurity professionals—most of whom are familiar with PAM and are directly responsible for managing or granting privileged access to users.

    There were some concerning findings from the survey regarding the perception of PAM. Twenty percent of organizations that reported using a dedicated PAM solution believe it somewhat or greatly reduces user productivity. Many respondents also expressed frustration about the amount of time required to manage privileged access. Half of the survey participants cited manually granting temporary privileges as either very (29%) or extremely (21%) time consuming, and half also said manually revoking temporary privileged access as very (33%) or extremely (17%) time consuming.

    PAM and DevOps

    As challenging as traditional PAM solutions might be for businesses around the world, they pose an even greater hurdle for organizations that have embraced DevOps. A recent episode of the Defense in Depth podcast, hosted by David Spark and Allan Alford, focused on some of the challenges of PAM. A listener had written to complain that “the traditional approach to PAM breaks everything that is DevOps. Regardless of what your PAM provider says about their ability to scale with your dev cycles, they’re lying about the real level of effort.”

    That seems like a fair assessment. Pretty much every company is somewhere on the cloud journey—and working within a DevOps framework on some level. Companies often face backlash from the DevOps team—with some going so far as to boycott efforts to introduce security tools that can’t keep up with the pace of DevOps in the cloud.

    DevOps developers express frustration about trying to build an automatic scaling, horizontal infrastructure and being dragged down by demands from the security team to install agents and change authentication modules. They complain it often means rewriting all of the scripts, resulting in significant and unnecessary effort for a solution that ultimately can’t scale properly in the DevOps environment.

    That is, unfortunately, true when it comes to traditional PAM solutions. Next generation PAM solutions, however, are built with the cloud and DevOps in mind. They are lightweight, automated, scalable and capable of integrating seamlessly with common tools and platforms.

    Rethinking Privileged Access Management

    Based on the survey, organizations understand the importance of privileged access management, but they struggle with finding a way to implement it effectively. The question from the podcast illustrates how PAM is also a significant issue for DevOps environments because traditional PAM solutions do not integrate or scale effectively.

    At the same time, we all know that PAM is a crucial element of effective cybersecurity. It’s not acceptable to just not manage privileged access, but it also doesn’t make sense to suffer through the headaches and frustration introduced by traditional solutions. Organizations need to find new privileged access management tools that work in the cloud and can scale automatically to provide PAM at the speed of DevOps.

    — Tony Bradley

  • The Challenge of Securing a Dynamic, Cloud-Based DevOps Environment

    The Challenge of Securing a Dynamic, Cloud-Based DevOps Environment

    The tech landscape has fundamentally changed over the last decade. The steady migration from local data centers to cloud computing combined with the advent of DevOps and the rise of containers have taken what was a more or less contained and relatively stable environment and transformed it into a dynamic, constantly shifting ecosystem. At the same time, the volume of exploits and threats has risen exponentially. The challenge today is how to effectively secure and protect servers, applications and data when your network is a moving target.

    It Starts and Ends With Visibility

    It’s difficult enough to protect something. Imagine that I give you a bag filled with money and tell you to keep it safe. There are risks involved and there will be criminals that want to steal the bag of money, but you have a fair idea of the threats you face. You know about the bag. It is in your possession. You can put it in a closet with only one entrance, make sure the door is locked and deadbolted, and monitor access with cameras. Now, consider how you would protect bags of money if hundreds of them could materialize at any point in time, anywhere in the house.

    If you don’t even know how many bags of money there are or where they’re located, how can you effectively protect them? The answer is simple: you can’t. That is essentially the situation IT teams face with dynamic, cloud-based DevOps environments.

    On a traditional, legacy network, it was relatively simple to keep track of how many servers were running in the data center and the applications running on them. One of the primary benefits of cloud computing, however, introduces one of the primary challenges of security in the cloud: The ability to scale capacity on demand adds elements of chaos and complexity that make it more difficult to know what exactly is on the network in real-time.

    As with the bags of money illustration above, though, comprehensive visibility is crucial for effective security. You can’t protect what you can’t see—or what you aren’t aware exists at all.

    Achieving Visibility in a Dynamic Environment

    Of course, getting comprehensive visibility is easier said than done. Many organizations have a hybrid and/or multi-cloud environment, with assets and data in local data centers and spread across different public and private cloud systems. You can install agents on some resources that will provide accurate information about the current state in real-time, but there are also many devices and services that can’t run an agent—requiring more diverse and creative approaches to gain visibility.

    The reality is that no single telemetry source will suffice. It takes a combination of active scanning, passive scanning, cloud-based accounts, agents running on devices and container-aware security to ensure that all of the various networks—and the servers, applications and services running on them—can be monitored and inventoried in real-time.

    Comprehensive Visibility Equals Consolidated Visibility

    Having broad visibility is not the same as having comprehensive visibility. Putting the tools and technologies in place to achieve and maintain comprehensive visibility is essential, but you also need to have the means to consolidate that information and manage it from a single console or pane of glass.

    You need all of the various sources of visibility data to be integrated into a single, comprehensive view so the entire ecosystem can be analyzed, monitored and maintained from one central view. Effective cybersecurity depends on visibility, and comprehensive, real-time visibility in a dynamic cloud environment requires a security platform with both the agility and scalability to keep pace and provide you with the information necessary to prioritize and address issues as they arise.

    — Tony Bradley

  • Effective Cloud Security Requires a Cloud-Native Mindset

    Effective Cloud Security Requires a Cloud-Native Mindset

    Thousands of developers and cloud security professionals will fill the Moscone Center in San Francisco next week for the sold-out Google Cloud Next ’19 conference. Three days of breakout sessions and keynotes will immerse attendees in deep technical content and opportunities for hands-on learning. It’s all designed to help organizations embrace the cloud. A key element of succeeding in the cloud is cybersecurity. More critically, the cloud demands embracing a cloud-native approach to security challenges.

    Leading the Way

    Since its inception, Google has been pushing the envelope and blazing trails in the cloud. Like Netflix, Google found itself—and often continues to find itself—in uncharted territory, where it was forced to innovate original solutions to address unique challenges.

    To help create standards and tool sets for managing container environments, Google joined the Cloud Native Computing Foundation (CNCF)—a melding of minds between developer communities and platform vendors—as one of the founding members along with CoreOS, Docker, Cisco, IBM and others. Famously, Google also originally developed Kubernetes—an open source container orchestration system for automating application deployment, scaling, and management.

    Google eventually donated Kubernetes to the CNCF. Transitioning it from a Google project to a CNCF project helped it gain broader traction and momentum and emerge as the de facto standard for container orchestration. Kubernetes became the first CNCF project to graduate out of incubation.

    Cloud-Native Mindset

    Kubernetes is a powerful, scalable platform for deploying and managing container environments of all sizes. Still, security needs to be a core focus for organizations, even in a Kubernetes ecosystem. The nature and volatility of container-based applications and cloud environments requires security to be cloud-native as well. Deploying containerized solutions on Kubernetes requires security that is built in to the distributed infrastructure and puts the focus on API security.

    Automation is Key

    The word “dynamic” is a very polite way to describe most cloud environments; volatile or chaotic might be more accurate, in many cases. Cloud infrastructures typically leverage DevOps tools and principles to compress development and deployment time frames and expedite the process of iterating new versions with continuous integration (CI) and continuous deployment (CD).

    The thing is, when development is driven by a CI/CD pipeline, security has to be as well. Manual processes can’t possibly keep up with the volume of assets that need to be monitored and protected, and traditional cybersecurity tools are not equipped for hybrid or multi-cloud environments. What’s more, they lack the scalability necessary for effective cloud security. Implementing and managing security in an environment that is constantly shifting and evolving requires an automated, cloud-native approach.

    Security in this context should be managed via API and also optimized to test API-based applications. Speed is crucial as well, though. Security should not break or impede the CI/CD pipeline due to timeouts or delays.

    Kubernetes clusters need cloud-native security tools to automate application protection. Tools capable of protecting containerized applications, microservices and APIs across public and private cloud environments while minimizing false positives at the same time.

    Conclusion

    There will be a ton of great information shared at Google Cloud Next ’19. While you’re networking, gathering insights on cloud strategies and learning how to solve problems in the cloud, don’t forget the crucial role of security. There are a variety of sessions offered that focus on security—how to manage, deploy, and develop security models for the cloud. Or, take a walk through Google’s dedicated Security Area in Moscone Center’s South Exhibition Hall. It’s a great place to connect with experts and educate yourself on why cloud-native solutions are essential for effective cybersecurity in a cloud ecosystem.

    — Tony Bradley

  • DevOps: Don’t Let Detection Be a Bottleneck for Security

    DevOps: Don’t Let Detection Be a Bottleneck for Security

    AI and automation can help ensure DevOps security doesn’t impact performance

    The world revolves around software and internet-based applications—and speed is crucial. Users have very little patience for delays and will quickly jump to something else if performance lags. Organizations have embraced DevOps and containers in an effort to accelerate development and deployment of software and maintain a competitive edge over rivals. One of the biggest challenges, though, is how to identify vulnerabilities and detect security issues without significantly degrading performance.

    There will always be some impact on performance. You are adding an extra layer of functionality—a layer of security intended to detect and resolve security issues. No matter how fast that detection is, it will still take more time than not having any detection at all. The goal is to implement detection with as little impact on performance as possible. You don’t want detection to be a bottleneck for your cybersecurity efforts, or a drag on performance in general.

    Bridging the Gap Between Speed and Security

    One of the defining characteristics of a cloud-based, containerized, DevOps environment is its dynamic and continuous nature. In an effort to streamline and accelerate business, organizations embrace continuous development, continuous integration and continuous deployment combined with continuous monitoring, continuous testing and continuous improvement—all of which require continuous security.

    Real-time monitoring for suspicious or malicious activity is crucial. The internet doesn’t sleep, and attackers are constantly scanning and probing for vulnerabilities and weak links to exploit in your network and applications.

    Security is important, but not at the expense of productivity. The challenge is how to bridge the gap between speed and security—and ensure you can detect attacks effectively without introducing undue friction. You need balance—security that provides necessary protection without defying the whole point of trying to streamline and accelerate business. In other words, security needs to become a guardrail rather than a roadblock for DevOps.

    Improve Detection with Automation and AI

    Real-time protection is necessary—but not all real-time security solutions are the same. How attacks are detected is as important—or more important—than just detecting them.

    Why? Simple. Attack detection based on signatures or generic patterns such as a core rule set or regular expressions are not customized to recognize threats in the context of the application. For example, with a RASP (runtime application self-protection) solutions, even if the control points are good, the end result will be poor without the right context and detection techniques. This approach is also reactionary and leaves you exposed for some period of time. It is generally ineffective until the signature is developed, and the signature can’t be created until the threat is detected and identified.

    Automation and artificial intelligence (AI) can accelerate the process and provide more effective protection with less friction. An AI-powered platform can learn from stateless traffic and deconstruct application logic to create application-specific rules—and update the rules dynamically without the need for human intervention. Using dynamic, application-specific rules rather than signatures and manual rules can result in efficient detection and an exceptionally low false-positive rate. An automated solution that leverages artificial intelligence also can protect without waiting for signature updates.

    Modern Security for Modern Networks

    The days of periodic scans are long gone. The network architectures and threat landscape today demand constant, real-time protection. Legacy detection techniques are cumbersome and can’t keep pace, but an AI-powered attack detection platform that is automated will be more effective for protecting a dynamic, cloud-based, containerized, DevOps environment.

    — Tony Bradley

  • Speed Rules in Chef’s DevOps Survey

    Speed Rules in Chef’s DevOps Survey

    DevOps is all about streamlining and accelerating. Organizations that embrace DevOps are driven by a focus on maximizing the combination of efficiency and effectiveness—which explains why speed is the central theme of Chef’s “The State of Enterprise Applications” survey.

    Chef surveyed nearly 350 application and operations professionals in an effort to understand trends in DevOps, identify how the industry is shifting and get an idea of what the future of DevOps looks like. What it found is that speed is one of the primary driving factors for organizations that function at the cutting edge of technology. Chef also found that organizations are eager to adopt new platforms that promise to help them move faster.

    The Need for Speed

    There are a variety of ways to measure success for application development and deployment. You can look at the features and capabilities of the app and whether it delivers the expected functionality, or you can determine success based on user feedback and how satisfied users are with the app experience. According to the Chef survey, 72 percent of organizations are focused on speed as the primary measure of a successful app deployment.

    That said, it generally takes weeks—or even months—to get an app developed and deployed. More than 60 percent of survey respondents shared that it takes days or more to complete an application build, and 55 percent indicated that it takes four or more builds before an app is ready to be deployed. Almost 60 percent said it takes days or more to actually deploy the app once the final build is approved.

    Platforms and Tools to Accelerate App Deployment

    In the quest for speed, organizations are moving to platforms and tools that can help accelerate development and decrease the time it takes to make an app available. According to data from “The State of Enterprise Applications” survey:

    • Only 9 percent of organizations are using public cloud for more than 50 percent of app deployments today, but that is expected to increase to 32 percent by 2020.
    • There is a 144 percent increase expected in the next two years in the number of organizations using container technology for more than 50 percent of app deployments—to 22 percent from 9 percent today.
    • The number of organizations using microservices for more than 50 percent of app deployments is expected to double—to 24 percent from 12 percent—in the next two years.
    • More than 80 percent of survey respondents are adopting a multi-cloud strategy.

    Putting App Deployment in High Gear

    Chef is in the business of automating and streamlining app development and deployment, so it should come as no surprise that the survey included questions related to that as well. The report states, “The most successful software-centric organizations use one consistent way of building, deploying, and managing applications.”

    More than 9 out of 10 (93 percent) of survey participants agreed that an application packaging solution that allows deployment to any environment would be valuable. This is especially true when developers have to deal with hybrid or multi-cloud environments.

    If speed is your primary measure of success for app deployment, you need to make sure you have the tools and processes necessary to develop and deploy applications as quickly as possible. Chef’s report shows organizations are well on their way.

    — Tony Bradley

  • Defend Against Phishing Attacks with EV Certificates

    Defend Against Phishing Attacks with EV Certificates

    One of the most important elements of fishing is choosing the right lure or bait. The same is true when it comes to the malicious digital version—phishing. A phishing attack requires good bait to be effective. Organizations can defend against phishing attacks and help protect customers by using EV certificates to verify the authenticity of the website.

    Phishing Attack Targets

    Phishing attacks are designed to fool a victim into believing the phisher is a specific, trusted party for the purpose of stealing credentials, accessing sensitive data or propagating malware. The foundation of phishing depends on the ability to create a false identity that the target audience will believe is the real thing.

    The most common targets for phishing attacks are online businesses—specifically, online businesses where customers generally conduct financial transactions or share sensitive data. Businesses of all sizes from small “mom and pop” shops to large enterprises are viable targets for phishing. Businesses in pretty much every industry are potential targets for phishing attacks, but the most high-profile phishing attacks typically focus on banks, credit unions, investment websites, ecommerce retailers and other similar businesses.

    Creating a Credible Counterfeit

    Due to the way the web is designed and the nature of HTML code, it is trivially easy to counterfeit a website. A simple “screen scrape” is all that’s required most of the time. You can right-click and save most images, or just link to the original images and code from the site being spoofed.

    Voilà! The content inside the browser’s display window for a counterfeit phishing site can—and usually does—look identical to the content on the actual site. It actually helps maintain the façade of authenticity to leave legitimate links on the counterfeit site as well and only changing or redirecting a couple key elements.

    Avoiding Phishing with EV Certificates

    That’s where an EV certificate comes in handy. The attacker can scrape, download, stream or link to most—if not all—of the elements that are within the confines of the HTML window. However, there is no way for the attacker to re-create or spoof the green address bar of a website with an EV certificate. Because the EV certificate indicator is outside of the HTML window in the browser interface itself, it can’t be spoofed or counterfeited.

    Websites that have an EV certificate give users a clear and simple way to determine if the website is legitimate or a counterfeit. It’s a good idea for organizations to give customers the tools they need to recognize and avoid a phishing attack. In the absence of an EV certificate, people don’t have that same opportunity.

    Maximize the Value of the EV Certificate

    Aside from helping customers steer clear of spoofed sites and phishing attacks, a recent survey highlights the fact that people have more confidence and trust in websites that are validated with an EV certificate. To get the most value out of the investment in an EV certificate, though—and ensure that users benefit from it as well—you need to follow a few simple tips:

    • Use green address bars consistently on all customer-facing pages on the site.
    • For companies operating with multiple brand names, use the brand names on certificates that match the brands of those sites.
    • Proactively communicate to customers that your site has green address bars and what to look for (including images of what to expect in popular browsers)
      • Include this message on appropriate portions of the website.
      • Include this message in outbound communications such as newsletters and security bulletins.

    By communicating with customers what to expect when they visit your websites and what to look for to verify that the website is legitimate, and then universally using EV certificates that are consistent with the brand of the website for all public-facing sites, you can help customers recognize and avoid spoofed versions of your website(s).

    — Tony Bradley

  • A Matter of Trust: Survey Examines Impact of EV Certificates

    A Matter of Trust: Survey Examines Impact of EV Certificates

    When it comes to interacting online, everything is a matter of trust. Spam emails and clever phishing attacks make it more challenging to determine what’s legitimate and what isn’t and have put businesses and consumers on edge. Without trust, customers are reluctant to share sensitive information or conduct transactions online. According to a recent survey, EV certificates have a significant impact on customer confidence and trust.

    First, let me explain what an EV certificate is. Most people are familiar with the basic SSL certificate. The EV, or extended validation, certificate requires more comprehensive and strenuous research into the organization requesting the it. As a result, it provides stronger verification and authentication.

    Websites protected with a standard SSL certificate typically are indicated with a locked padlock icon in the web browser address bar. Websites that are secured with an EV certificate also include the padlock, but the address info is displayed in a distinct green color to indicate that it’s safe and the full name of the company that obtained the EV certificate is displayed.

    I’m not as vigilant as I ought to be, perhaps, but I honestly do glance at the browser address bar to double-check that the padlock is locked, and the connection is over HTTPS instead of standard HTTP. If I don’t see those things, I will stop and examine the URL and web page more closely. I certainly wouldn’t enter any financial or sensitive personal information in a site that was not secure. The bright green company name and locked padlock on a site protected with an EV certificate stands out more and makes it immediately obvious that the site is secure.

    If your website does not instill confidence, customers will not trust you. We gathered input from more than 350 individuals around the world and found that the EV certificate has a significant impact on that trust. Eight out of 10 survey respondents indicated that their perception of a brand or company is influenced by the green address bar of a website protected with an EV certificate. More than 50 percent stated that it has a significant influence.

    When presented with two virtually identical images of a banking website—one protected with a standard SSL certificate and the other with an EV certificate—survey participants overwhelmingly favored the EV certificate website. Here is a quick look at how much more the survey respondents agreed with these statements when it comes to the EV certificate website:

    • “I am safe doing business with this site.” 6 times more
    • “This business is trustworthy.” 8.6 times more
    • “This business is secure.” 10.8 times more

    Perception is reality. Whether a website has no certificate, a standard SSL certificate or an EV certificate may not necessarily dictate that the company is more trustworthy. But, our survey determined that it is perceived to be more secure and more trustworthy, and—in the end—that is all that counts. Companies that want to project the image that they are concerned about security and care about the privacy and security of customer data should invest in an EV certificate.

    Check out the full report yourself to learn more about the survey, and what the findings indicate about the value of EV certificates.

    — Tony Bradley