devopsy.kinsta.cloud

Author: Tony Bradley

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
July 9, 2018
Can EV Certificates Improve Brand Value and Increase Trust?

Most people know the difference between a website that is completely insecure and unencrypted and one that offers an encrypted session for security. You simply look for whether the URL starts with HTTP and the address bar displays an open padlock, or the URL starts with HTTPS and shows a locked padlock. Within the realm of secure websites, though, not all certificates are created equally. An extended validation certificate — EV certificate, for short — provides a more in-depth validation process than other certificates and may foster more trust from customers as well.

The difference between an EV certificate and other certificates lies in the verification required to obtain one. Traditional certificates can be acquired by providing organizational information or verifying admin rights of the target domain. On many occasions, though, attackers have found ways to circumvent or subvert the verification process and obtain fraudulent certificates using those methods. The verification process for an EV certificate requires proof that the requesting entity is, in fact, the legal identity that owns and manages the target domain.

According to Wikipedia, the vetting process for an EV certificate involves a number of additional validation steps: “These include manual checks of all the domain names requested by the applicant, checks against official government sources, checks against independent information sources, and phone calls to the company to confirm the position of the applicant. If the certificate is accepted, the government-registered serial number of the business as well as the physical address are stored in the EV certificate.”

As attackers have grown more savvy and adapted to the expectation that a website run over HTTPS and have the padlock indicating that it’s secure, they’ve found ways to game the system and create fraudulent or phishing websites that appear to be secure.

Websites with EV certificates show up differently in browsers with EV support, which includes Microsoft Edge, Microsoft Internet Explorer, Mozilla Firefox, Google Chrome and Apple Safari. In most implementations, websites with EV certificates include more advanced details about the website and the entity behind it, such as the name of the company that owns the certificate and a bar or text that is distinct—usually green—for easy visual verification of a valid EV certificate.

We’d like to know more about how important secure websites are to you, and whether you know—or would notice—the difference between a website using a traditional certificate and a website using the more secure EV certificate. Please invest five minutes of your time to take a quick survey and help us learn more about the value of EV certificates when it comes to your level of trust online.

Click here to begin the survey.

— Tony Bradley

June 6, 2018
451 Research Report Highlights Value of DevSecOps for the CI/CD Pipeline

One of the compelling benefits of DevOps for many organizations is speed. Between breaking down silos, streamlining processes and automating routine tasks, the process of developing and deploying software can be significantly faster. A new report from 451 Research and Synopsys, however, points out the value of incorporating DevSecOps in the equation, especially with continuous integration/continuous delivery (CI/CD), and the pitfalls of prioritizing speed without also considering security.

For the “DevSecOps Realities and Opportunities” report, 451 Research surveyed 350 enterprise IT decision-makers across the United States and Europe, focusing on organizations that have implemented CI/CD. The goal was to learn more about how organizations are implementing CI/CD and the role security plays in that equation.

For most organizations, embracing DevOps and adopting CI/CD is about speed, not security, the survey found. Shocker! As per usual, security is typically an afterthought—something that might be nice to do if time and resources permit.

Survey respondents indicated speed as a leading driver for and expectation from CI/CD. “The most organizations (36 percent) sought a 4x factor of improvement in time to deploy from their CI/CD workflows. A significant number (15 percent) sought a 5x factor of improvement. Another 7 percent sought more than a 5x factor of improvement, and 5 percent were seeking a 10x or greater factor,” according to the report.

The irony is that organizations seem to prioritize speed over quality and/or security at their own peril. Maximizing for speed in the CI/CD pipeline without consideration for security typically leads to more bugs in the code, more downtime and increased time and effort to maintain and remediate applications.

451 Research points out that as DevOps implementations mature, the focus will shift to what’s truly important. “We believe that as organizations evolve these processes, the focus will naturally move from ‘how fast can development teams iterate’ to ‘how reliably can we deploy high-quality, appropriately secure code each and every time,’” the researchers wrote. “That critical change in focus—that more mature view of risk management—will realign everyone’s expectations on what ‘4x’ really means.”

Of those organizations that participated in the survey, only about half actually include some sort of application security testing as a function of the CI/CD workflow. Identifying open source software components with known vulnerabilities—also known as software composition analysis (SCA)—is ranked as the most crucial security component for CI/CD by survey respondents, yet nearly 40 percent of the participants admitted that they don’t do any SCA or insist they simply aren’t using any open source code. That seems highly unlikely, though, given that a recent report from Black Duck Software, “Open Source Security and Risk Analysis,” found that 95 percent of applications contain open source elements.

“While some DevOps teams are starting to incorporate application security into their CI/CD workflows, driven by factors such as improved software quality, compliance and risk avoidance, there is ample room for improvement,” said Jay Lyman, principal analyst at 451 Research. “In many cases, security testing is not being integrated often or early enough in the process for organizations to fully benefit from reduced risk and rework headaches.”

With security, it always seems a bit like the Bill Murray movie, “Groundhog’s Day”: No matter how many years security professionals have pushed, and fought, and screamed from the mountaintops that security needs to be woven into the foundation of software and integrated into the development life cycle rather than being tacked on with duct tape and chewing gum after the fact, organizations continue to insist on doing the things the harder—and more expensive—way. Hopefully, reports such as this will open the eyes of some organizations and they will break the cycle and start prioritizing security, recognizing that it is actually the best way to develop reliable code as quickly as possible.

— Tony Bradley

April 27, 2018
Simplify DevSecOps with a Zero Trust Approach

There are major cyberattacks and data breaches weekly, if not daily. Each incident is unique in some way, but one element common to almost all successful attacks is trust. Whether it’s a disgruntled employee conducting an insider attack, an attacker infiltrating the network using stolen credentials or an exploit that leverages a third-party vendor or supplier, what makes the attack possible and allows attackers to fly under the radar is the fact that the credentials and activity appear to be legitimate. A zero trust security approach could solve that.

In DevOps environments, where new application architectures such as microservices and containers make things much more dynamic and rapidly changing, security can be especially difficult. Automation, virtualization and new tools combine to increase the potential attack surface exponentially. And, granting and removing access for containers or virtual machines that appear and disappear by the hundreds can be a Herculean task—traditional permissions management and access control solutions just can’t keep up.

“DevOps creates a challenge for many organizations because they need to maintain agility while also recognizing that security is an increasing concern in broadly distributed networks,” said Bill Mann, chief product officer at Centrify. “Prioritizing functional requirements over security while building applications leaves organizations exposed to significant risk.”

Centrify, however, is up for the challenge of bringing zero trust security to DevOps environments. The company claims to simplify integration of security into DevOps applications development pipelines without restricting development velocity.

Centrify starts with the premise that users, applications and endpoints are not trustworthy by default. Everything must be verified at every point of access to ensure that security of the development pipeline is not compromised in any way.

Its DevOps-focused portfolio includes products that help developer, security and operations teams manage access to complex development environments, enhance application security and provide auditable logs of privileged activity. Centrify provides centralized management of user access rights and privileges to Linux and Docker hosts, including hosts running CoreOS Container Linux. I am especially intrigued by its ability to implement multi-factor authentication (MFA) and temporary privilege elevation to gain access to individual containers independent of the container hosts.

Centrify also announced that it can now be used to authenticate to HashiCorp Vault, one of the most popular tools for securely strong and accessing secrets. Centrify provides centralized access management for the Vault, as well as protects against malware attacks by eliminating the need for locally stored access credentials.

On the application security side, Centrify focuses on securing privileged service and system accounts and enabling secure communication between applications, containers and microservices. Centrify leverages Kerberos, SAML or OAuth to enable services authenticate to each other.

The basic premise of Centrify is that “trust but verify” sounds good in theory, but in reality “never trust, always verify” is a much better strategy for security. Rather than hoping you can find the needle in the haystack and identify the one bad actor, it makes more sense to assume the bad guys already exist both inside and outside your network and simply remove trust from the equation.

The approach certainly seems to have some merit. It’s sort of like applying a whitelist instead of a blacklist to filter email or applications. Rather than assuming everything is good and trying to find the bad ones, just assume everything is bad and only let through the ones you choose. In this case, however, you don’t even have the whitelist. You’re literally verifying the user and device and applying policy to determine the level of access and privilege each time.

— Tony Bradley

April 19, 2018
Why Your Software Supply Chain Might Be Your Achilles Heel

Historically, cybercriminals are as lazy as they are innovative. They can come up with clever exploits and attack vectors, but they still generally focus on the low-hanging fruit in the most target-rich environments. Recently, attackers seem to have shifted focus away from directly targeting companies with strong security or a wealth of resources, instead going after weak links in the software supply chain.

No matter how many resources or how much effort you dedicate to securing your networks and protecting your data, it can all be for nothing if you trust a third-party supplier or vendor that is vulnerable. It is also true of your software supply chain, because the process of developing and deploying software offers opportunities that attackers can exploit.

The Case of Xcode Ghost

iOS devices are considered to be exceptionally secure. iOS is not impervious to attack or exploit, but it is more secure than the competing Android platform. Apps for iOS are also considered to be more secure, because Apple’s App Store is a “walled garden” with a stringent review process for an app to be approved.

A few years ago, however, it was discovered that more than 4,000 apps in the Apple App Store contained malicious code. Attackers had figured out how to leverage a weakness in the software supply chain to get past the gatekeepers of the walled garden.

How did they do it? iOS apps have to be written in Xcode. The Xcode software is provided for free, but the Apple servers are often slow—especially when trying to download from China, so developers often just search the web to get Xcode from a third-party site. Cybercriminals developed a malicious version of Xcode, then gamed the systems to ensure their version of the software would show up at the top of online searches.

Apps developed with the malicious Xcode software contained extra code that would phone home and provide the attacker a backdoor—and an opportunity to inject malicious code or execute commands within the compromised apps.

Low-Hanging Fruit

The Xcode Ghost incident is an excellent example of a software supply chain attack, and a perfect illustration of attackers going after the low-hanging fruit. iOS is relatively secure. The Apple App Store is protected and apps are reviewed to ensure they meet strict criteria. So, instead of trying to go after Apple or iOS, attackers figured out how to strike the platform used to develop the apps and sneak in through the back door.

I spoke with Ryan Olson, Intelligence Director for Palo Alto Networks, about the rising threat of attacks on the software supply chain. He explained that attackers know that when they are going after a hard target that would be difficult to defeat directly, there is a better and easier way: Just figure out who they trust and go after the low-hanging fruit.

This becomes a potentially larger issue in the context of DevOps and automation. The recent NotPetya ransomware was propagated through a malicious update. If your systems or software are configured to update and/or deploy automatically, a software supply chain attack can be in the wild and compromising your applications or data before you know it.

There are tools available to scan images, applications or containers before deploying them, but they typically test for known vulnerabilities or overt crashes or conflicts. They are not designed to look for latent backdoors that might be buried in the code.

Olson recommends that you start taking a closer look at the software vendors you rely on. It is important to understand how they are securing and protecting their code—because their weaknesses expose you to threats by virtue of the trust you give them and their apps.

— Tony Bradley

April 2, 2018
DevOps Careers: Report Examines What It Takes To Be an SRE

Do you want to be a site reliability engineer, or SRE? Sixteen years ago, the role didn’t actually exist, but now you can find more than 1,000 opportunities for a career as an SRE on LinkedIn. Before you decide if you want to explore such a career, though, you should check out the new survey from Catchpoint, which examines the role and what exactly SREs do.

Catchpoint launched its survey in January with the goal of determining what exactly it means to be an SRE. The survey takes a closer look at the types of organizations, skill sets and organizational cultures in place where SREs work. Catchpoint wanted to build a profile of the SRE role and determine whether there is a core set of principals or skills common to the SRE role.

The report includes responses from 416 participants representing a range of roles, industries and company sizes. Nearly 4 out of 10 respondents actually identify as SREs. More than half work for companies in technology-related industries, and more than 40 percent indicated that they work for a software-as-a-service (SaaS), infrastructure-as-a-service (IaaS) or other as-a-service (XaaS) provider. More than 50 percent represent companies with at least 1,000 employees, while just under 40 percent are from larger organizations of 5,000 or more employees.

What is an SRE?

The SRE role originated at Google in 2003. The SRE straddles the line between the “Dev” and “Ops” sides of DevOps. SREs foster collaboration, productivity and software performance and—ultimately—gives developers greater responsibility for the performance of the applications they produce.

SREs typically both write code and support existing systems. Nearly two-thirds of SREs report they are deploying code daily—with almost half indicating that they deploy code multiple times per day. According to the report, most SREs report to software engineering despite the fact that a large percentage of SREs actually come from an IT operations background.

Coding skills and a solid knowledge of IT operations are both valuable resources for an SRE, but there are also a variety of “soft skills” that seem to be crucial to success. Problem-solving, teamwork, composure under pressure and strong written and verbal communications regarding incident resolution are all necessary to be effective as an SRE.

Novices Need Not Apply

The Catchpoint survey contains some bad news for fresh college graduates looking for their first gig, and excellent news for experienced IT professionals: The SRE role is not an entry-level job. Eight out of 10 SREs have a college degree and have worked in IT for six or more years. A college degree in computer science or information technology isn’t necessarily a requirement, but 73 percent of SREs did, in fact, get degrees in a technical field of study.

Although a majority of SREs surveyed report to the software engineering department, most come from an operations or infrastructure background. Just under 65 percent of survey participants reported that they held a role as a sys admin, while only 53 percent previously held a role as a developer or software engineer.

To learn more about the site reliability engineer role, check out the full 2018 SRE Report from Catchpoint.

— Tony Bradley

March 30, 2018
Automation Levels the Playing Field for Continuous Compliance

At this point, I doubt there is any company doing business anywhere that doesn’t fall under at least one compliance framework. One universal truth of compliance—in intent, if not in practice—is that it is a process, not an event. Checking boxes and passing an audit is a requirement of most compliance mandates, but the real value of compliance lies in maintaining that level of visibility and security all the time—which is why continuous compliance is important.

The Need for Continuous Compliance

Hopefully I don’t need to continue to make the case that compliance is an ongoing requirement. Because it is something that needs to be consistently monitored and maintained, it also makes sense to automate the process as much as possible.

In a report titled, “How to Avoid Compliance and Audit Concerns When Using DevOps,” published in November, Gartner stated, “Auditors favor the consistency and traceability of automated systems that have strong logging capabilities and transparent auditable controls.”

A recent survey of more than 1,500 users conducted by Chef found that 74 percent of cross-functional application, infrastructure and security teams do exactly that, though: They assess software for compliance manually prior to production. Once violations and vulnerabilities are discovered, half remediate manually instead of automating the process. Manual processes result in teams’ detecting and remediating security issues in days (31 percent) or weeks (19 percent), instead of hours (18 percent).

“At scale, manual reviews or out-of-band security tools bolted onto the DevOps pipelines won’t be able to keep pace with new velocity of change,” said Derek Weeks, VP and DevOps Advocate at Sonatype. “We saw this first with paper-based open source governance policies in the application security realm and it’s exciting to see similar approaches applied to infrastructure.”

Andrew Storms, VP of Product at New Context, agreed. “Infrastructure automation and configuration management are key requirements for securely storing and transmitting data. … In DevSecOps, bringing security into the development process early and often helps ensure more cost-effective data security.

“Think about this: By 2020 there will be some 20 billion IoT devices connected to the internet,” he continued. “Most organizations can’t even handle automating security and compliance of their existing infrastructure. The growth demand is far outpacing human abilities. Organizations simply cannot afford to rely on the methods of treating our infrastructure as cute and cuddly pets—and spending weeks producing evidence for security audits is not going to happen.”

“Rather than force cumbersome security processes on top of the DevOps pipeline, security and compliance professionals need to adopt a new mindset of integrating controls as code,” Weeks added. Codifying controls initially improves the performance of the checks, but, over time, serves to expand the breadth of security and compliance practices as more controls are coded.”

Speaking a Common Compliance Language

Effective communication is a critical part of the process. “If you were ever in doubt on the importance of testing, then you should ask NASA about how they lost the Mars climate orbiter,” Storms said. “Years of development and likely some millions later, the space probe burned up because two software components weren’t using same units to communicate.”

Chef just released InSpec 2.0, which advances the capabilities of compliance automation. Mike Vizard wrote, “InSpec provides a mechanism to automate compliance management using a set of declarative tools that don’t require anyone on the IT team to possess programming skills.”

The leveling of the playing field by removing the need for programming skills is crucial for DevOps organizations, noted Julia Dunn, Director of Marketing for Chef. “One of the main challenges to DevSecOps (getting developers, security and operations to work together) is communication: not only seeing each other’s point-of-view but having a common language to collaborate on requirements,” she said. “InSpec is a framework that allows for those requirements to be expressed unambiguously in something all three groups can understand. This is in contrast to the previous state, where security throws lengthy scan reports over the wall at operations, or developers toss insecure code at security folks for manual inspection.”

Jon Williams, CTO of niu Solutions and a Chef InSpec user, has seen the benefits of such a technology. “InSpec has helped us unify our compliance, security and DevOps teams and streamlined audits, reducing the thousands of staff hours usually required by as much as 95 percent and eliminating duplication of effort and data throughout the process,” he said. “It has given these teams more control over compliance policies and enabled business units to be more active in maintaining their own environments. Most critically, it allows us to continually monitor for audit compliance, ensuring desired state and eliminating change drift between nodes.”

Regardless of what technology you choose, it is important you have a process or framework in place that enables the various parties involved to speak the same compliance language. It is also crucial to automate as much as possible to provide continuous compliance rather than just passing a compliance audit and assuming everything will stay that way.

— Tony Bradley

February 26, 2018
Manage Cloud Clutter with Better DevOps Hygiene

One of the core principles of DevOps is automation. Continuous development, deployment, monitoring, security and every other element of a continuous DevOps life cycle depends on as much of the underlying tasks and actions being automated as possible. Although the provisioning, scaling and decommissioning of most DevOps resources in the cloud are handled by automated processes, inevitably there will be rogue artifacts and other cloud waste left behind.

When we talk about DevOps, we tend to focus on developers, but the reality is that DevOps straddles development, IT operations and general business processes. It is the cross-section of these three areas and how they mesh that enables DevOps to deliver increased agility, scalability and streamlined app development and deployment when implemented effectively.

Managing cloud costs and ensuring efficient use of resources should also be a function of DevOps. DevOps teams tend to hyper-focus on app development, integration, speed of delivery and app performance—all of which obviously are very important. It’s also important, though, to reduce or minimize infrastructure costs and ensure that cloud resources are not being wasted or left behind as remnants that are no longer being used.

Tearing down walls between teams and breaking down silos are hallmarks of DevOps. That same approach should be applied when it comes to managing cost and cloud waste. A white paper from ParkMyCloud notes, “Consider the problem of running resources when they’re not in use and how this contributes to cloud waste. If access is limited and only one person has the ability to turn instances on and off, then one individual is solely responsible for ensuring that cloud resources are used optimally.”

To efficiently manage cloud resources and reduce unnecessary clutter and costs, you need to pay attention to the right data. DevOps relies on monitoring and feedback to ensure apps are running as expected and performance is optimized. That monitoring and feedback also needs to look at things such as whether cloud instances are properly sized, if they’re continuing to run when they’re no longer being actively used, and whether there are rogue or orphaned resources out there that are unnecessary but still being paid for.

Just as automation drives DevOps itself, automation can also be an effective tool for managing and minimizing cloud costs and clutter. According to the ParkMyCloud white paper, 44 percent of cloud workloads are non-production—test, development and QA environments, for example—and don’t need to run 24/7.

“One way to save really significant dollars in dev and test is to switch your resources off when you go home,” suggested Werner Vogels, CTO of Amazon Web Services. An organization can theoretically reduce costs associated with development and test environments by up to 75 percent by simply turning those things off when they’re not needed.

If you think about it, managing cloud costs and clutter in DevOps is essentially the same as managing security within DevOps, which is essentially the same as effectively managing DevOps. You have to consider cloud infrastructure costs as a part of the holistic environment or project; remove silos to empower everyone involved to be part of the solution; monitor key metrics to get useful feedback; and automate the process as much as possible. As with DevSecOps, the main key is to make cloud hygiene and the reduction of cloud clutter an integral part of the DevOps life cycle—not something that is tacked on after the fact.

— Tony Bradley

February 15, 2018
Cloud Generation Firewalls are the New ‘Next Generation’

There’s a new kid on the block—or a new firewall, at least. Traditional network and security technologies generally don’t translate well to a cloud environment. Next-generation firewalls might have been “next generation” when they were introduced, but now they’re “previous generation”—legacy technology that isn’t capable of doing the job effectively in the cloud. The new “next generation” is the cloud generation firewall.

I’ve never been a fan of using the term “next generation” as a label. Where do you go from there? I mean, I love “Star Trek: The Next Generation, but what is supposed to come after that—”Star Trek: The Next Generation After That One”? It’s going to seem silly in 10 years when we’re talking about the archaic, outdated “next generation” technologies.

Thankfully, we might soon be able to retire one of the “next generation” labels. ZScaler sort of started down this path when it introduced the “world’s first cloud-based next-generation firewall” in 2015. Barracuda recently took it a step farther, dropping the “next-generation” and announcing cloud generation firewalls.

Cloud Generation Firewalls

Aside from a catchy new name that’s good for marketing, though, what does that actually mean? Traditional firewalls, including next generation firewalls (NGFW), were engineered to protect a centralized data center or network, or a distributed network spread out over multiple locations. The public cloud is a very different environment.

At face value, a distributed infrastructure with multiple locations connected across the internet seems similar to a cloud environment. A public cloud environment is much more dynamic, though, and has a more loosely coupled architecture than a dispersed private network. Companies move to the cloud to take advantage of DevOps, automated deployments, elastic scaling and other elements that enable them to develop and deploy applications and services more efficiently, but legacy security tools including NGFWs can’t protect effectively in the cloud.

As with other network and security solutions, companies need firewalls that understand the cloud. To be effective, a cloud generation firewall should be cloud-native and integrate with cloud management and monitoring tools. It also should be able to automate deployment and scaling, and offer APIs that enable it to work with DevOps development tools. Finally, its licensing and pricing should reflect the dynamic nature of the cloud environment.

Challenges of NGFW in the Cloud

I spoke with Tim Jefferson, VP of public cloud for Barracuda, about cloud generation firewalls. He agreed that companies are facing challenges as they embrace the public cloud and try to use tools that were optimized for data center architectures in cloud environments.

The design principles of an NGFW are “anti-pattern” in the public cloud, he said. The public cloud environment is based on keeping things loosely coupled and easily scalable, while NGFW solutions are designed for tight coupling with ties back to centralized policy enforcement.

What’s more, he noted the licensing model for a traditional NGFW poses a problem in the cloud. Traditional licensing forces customers to deploy only in production environments, when security best practices suggest automating security architectures in all stages. Customers want to—and should—deploy security in all stages of development to better support DevOps principles, and cloud-generation licensing enables this.

Cloud-native solutions need cloud-native licensing that takes into account the rapid scalability and dynamic nature of the environment. Barracuda went with an approach that meters based on bandwidth rather than time, so customers are billed only when the cloud generation firewall is used, not when it’s just sitting idle.

Naming conventions aside, cloud generation firewalls just make sense. Many organizations fall into the trap of moving to the cloud and thinking they can just use the network and security tools they already have—just in the cloud. The reality is that you need cloud-native tools to effectively take advantage of the reasons you’re moving to the cloud in the first place.

And, if cloud generation firewalls catch on, perhaps we can move beyond “next generation” and stop using that dumb term.

— Tony Bradley

January 3, 2018
In DevOps, Figure Out Why Before Considering How

It has been fairly well-established that DevOps is primarily a function of the underlying culture—about breaking down barriers and shifting roles so that teams and individuals are empowered to come up with innovative ideas and execute them without the burden of traditional corporate bureaucracy. It is also understood that there are a variety of tools and platforms that enable and automate processes. However, before an organization can even get to the “How”—the culture and tools of DevOps—it should be able to answer the question, “Why?”

I reached out to organizations that have embraced DevOps and leaders in the field to see what they had to say about the “why.” What benefits can businesses expect, and what goals can adopting DevOps help them achieve—or achieve faster, or achieve cheaper?

“Delay in delivering innovation comes with an increasingly high price tag, perhaps the loss of an entire market to competitors,” says Forrester Analyst Charles Betz. “DevOps accelerates and improves the quality of software delivery, but that is not an end in itself. The increased speed provided by DevOps is essential to achieving the fast product feedback needed for digitally transforming enterprises to stay relevant and competitive.”

As Betz points out, companies should implement DevOps for the competitive advantage. Dave Lindquist, IBM Fellow and VP of Private Cloud for IBM, puts it another way: “DevOps is at the heart of the digital transformation. It’s how the next wave of disruptions are being developed and delivered.”

DevOps bridges the gap between development and operations teams. Inspired by agile development and continuous integration, and incorporating their principles, it addresses the challenges of today’s condensed timeline for application development.

In that way, the line between the “Why” and the “How” blurs into a bit of a gray area. Companies should adopt DevOps with specific goals in mind—a vision for what they expect it to do for them—because simply eliminating barriers or implementing tools and platforms without a strategy in place for what that is expected to accomplishment is likely to be a waste of time, money and effort. On the other hand, it is very difficult to execute or achieve those goals without also successfully navigating the “How.”

“Enterprises are navigating major technology shifts and demand is therefore higher than ever for simple and consistent automation and management across hybrid infrastructure and application portfolios,” says Marc Holmes, VP of Product and Revenue Marketing at Chef. “Organizations should adopt DevOps practices for both the culture and tooling to create a consistent and collaborative workflow so enterprises can build, manage and deploy software quickly and safely in any environment.”

“DevOps can have a direct effect on your bottom line. According to a recent study from Enterprise Management Associates (EMA), ‘Companies that excel at DevOps interactions are 11 times more likely to see double-digit annual revenue growth. It doesn’t stop at revenue growth either. According to EMA, 49 percent of organizations also agree that accelerated delivery frequency leads to higher customer satisfaction, and 35 percent find that it enables them to be more agile and competitive,’” notes Chris Lippi, VP of product at NGINX.

With its focus on automation, DevOps also helps to ensure predictability, efficiency, accuracy and the standardization of operational, development and testing processes. This, in turn, saves time and money by shortening the release cycle, reducing errors and lessening the need for time-consuming fixes. It also frees up resources to focus on more creative endeavors and on tackling larger problems as they arise.

Lippi sums it up this way: “Once implemented, DevOps tends to prove its business value in terms of time and cost savings. Making the business value of DevOps clear—to the newly unified team and beyond—helps DevOps culture take root.”

There are lots of tools and practices out there to choose from, and plenty of guidance and advice on how to implement a DevOps culture. Before you go down that path, though, step back and figure out what you hope to accomplish by adopting the culture, tools and practices.

— Tony Bradley

June 23, 2017