devopsy.kinsta.cloud

Tag: security

DevOps Deeper Dive: VMware Transformed
At the VMworld 2019 conference this week, VMware in no uncertain teams made it clear it wants to become a major DevOps force.

Following the acquisition of sister company Pivotal Software last week, VMware is moving to build out an application development framework for building and deploying cloud-native applications based on Kubernetes. That effort coincides with ongoing investments in its vRealize Suite of management tools, through which VMware is committed to automating IT operations across both on-premises IT environments and public cloud computing environments.

To advance those twin goals, VMware this week launched a series of Tanzu management tools for managing any distribution of Kubernetes while at the same time launching VMware hybrid cloud platform, which combines everything—from vRealize automation tools to the monitoring tools from Wavefront by VMware—to create a central console through which all of IT can be managed.

[su_box title=”The VMware DevOps Timeline”]
- October 2015 – Dell Acquires VMware along with EMC
- April 2017 – VMware acquires Wavefront monitoring service
- August 2017 – VMware shifts public cloud strategy via Amazon Web Services (AWS) alliance; VMware and sister company Pivotal Software unveil Kubernetes distribution
- November 2017 – VMware Launches VRealize Management Suite
- February 2018 – VMware acquires CloudCoreo to gain cloud configuration tools
- August 2018 – VMware acquires CloudHealth Technologies to gain governance tools; VMware launches AppDefense to provide a zero-trust framework
- November 2018 – VMware acquires Heptio for Kubernetes expertise
- December 2018 – Dell acquires all VMware outstanding shares
- May 2019 – VMware Acquires Bitnami for application packaging tools
- July 2019 – VMware Acquires Avi Networks to gain Web Application Firewall (WAF); VMware Acquires Bitfusion for machine learning algorithms and GPU virtualization software
- August 2019 – VMware Acquires Pivotal Software; VMware Acquires Carbon Black; VMware Launches Tanzu Platform to manage Kubernetes; VMware Unveils Hybrid Cloud Platform
[/su_box]

After deciding to launch a series of services through which it manages instances of its software on public clouds such as Amazon Web Services (AWS) and local servers from sister company Dell EMC, VMware has been slowly expanding its reach into the realm of applications. The most significant element of that thrust to date has been its acquisition of Pivotal, a provider of the widely used Spring framework based on Java and a platform-as-a-service (PaaS) environment based on open source software from the Cloud Foundry Foundation (CFF).

The CFF is in the process of migrating the application development environment created for Cloud Foundry to Kubernetes, a cloud-native container orchestration engine being developed under the auspices of the Cloud Native Computing Foundation (CNCF). Both the CFF and the CNCF are arms of the Linux Foundation. The rise of Kubernetes has resulted in many organizations shifting their application development strategies to a platform capable of supporting multiple application development environments.

Prior to announcing the deal to be acquired by VMware, Pivotal cut its revenue forecast for fiscal 2020 by $40 to $50 million.

VMware CEO Pat Gelsinger

Pivotal Software spun out of VMware in 2013, so to a certain degree VMware’s move to acquire Pivotal represents something of a homecoming that last week was valued at $2.7 billion. Pivotal currently has about 350 customers, many of which are hosting a distribution of the Cloud Foundry PaaS on VMware platforms. VMware also tapped Pivotal to jointly develop a curated instance of Kubernetes, dubbed Pivotal Container Service (PKS), that is optimized for VMware platform. As part of that effort, VMware is also developing an instance of VMware vSphere that will run Kubernetes natively.

At the VMworld 2019 conference, VMware CEO Pat Gelsinger made it clear VMware plans to leverage Kubernetes to bridge the historical divide between developers and IT operations teams. In fact, he told attendees Kubernetes was the most important technology to emerge since the virtual machine was created. As part of that effort, Gelsinger noted that the acquisition of Pivotal coupled with the recent acquisition of Bitnami, a provider of tools for packaging applications, means there are now more 5 million developers participating in the VMware ecosystem.

VMware is clearly hoping the developer ecosystem will expand as VMware makes it easier to launch virtual machines on every major public cloud as well as on-premises IT environments. VMware has faced a major challenge over the last several years as DevOps teams have bypassed internal IT teams to deploy applications on cloud services based on alternative virtual machines by AWS or Microsoft. Thanks to the inherent portability of Kubernetes, VMware is hoping organizations will now deploy cloud-native applications on VMware platforms. It remains to be seen, however, to what degree DevOps teams will embrace VMware on public clouds versus continuing to employ those virtual machines.

When it comes to cloud-native computing, VMware is clearly playing catchup. VMware has 250 PKS customers today, while rivals such as Red Hat (now an arm of IBM) have already redeployed their application development and deployment platforms on Kubernetes as an alternative to the Cloud Foundry PaaS. On the plus side, VMware now claims to be the third-largest contributor to Kubernetes, thanks in part to its acquisition of Heptio, a provider of Kubernetes tools.

In the meantime, there’s no question VMware is at the forefront of developing tools for automating the management and securing of IT infrastructure running its virtual machine software. Less clear is to what degree VMware will be able to translate that success to also unify application development and IT operations across multiple platforms a truly meaningful DevOps way, rather than merely bundling a suite of disparate tools together at a discount.

— Mike Vizard
August 26, 2019
Why Modernizing Security is Like Visiting a Fast-Food Restaurant
Fast casual restaurants are taking over the food industry. Today’s consumers want quality and speed, and the brick-and-mortar model offering immediate service paired with quality ingredients perfectly fits the bill. It’s the new, modernized dining experience. You can also argue that the same modernization taking the food industry by storm is happening in the security sector.

Simply put, fast-food restaurants know what their customers want: food that’s served hot, fresh and quickly–all while being made to order. And while the needs of a fast-food customer may seem far from the security needs of an organization, it isn’t too far off. Just like a fast-food customer, DevOps teams are hungry for a streamlined process. However, in their case, this doesn’t come in the form of a fried chicken sandwich; rather, an app infrastructure that is low-latency, secure and brings visibility.

According to the 2018 Verizon Data Breach Investigations Report, web application attacks are the leading source of data breaches. This suggests security procedures are not keeping up with modern systems and vice versa, which means they’re not keeping up with the modern customer, who has increased security needs due to demands for fast, interactive, web-based experiences with vendors. From food service to security, many industries are learning that, to succeed today, you’ve got to combine the old with the new.

As technology evolves, systems must as well. When it comes to security, it does not make sense to continue using a legacy WAF built for a decades-old line of defense. Today’s technology and applications require next-gen WAF systems that can keep up with the changing infrastructures and the evolving threat landscape. The risk is too great to sit back and do nothing.

Security teams today often find themselves either supporting new infrastructure initiatives or inheriting legacy applications and systems. Determining where an application is running can be a challenge. Rather than simply pointing to a rack of servers to locate an app, security professionals now must look to the cloud. However, this presents another obstacle: container orchestration. Kubernetes or otherwise, the options are not always clear-cut.

A modern infrastructure mix is made up of many parts (much like a layered chicken sandwich): cloud, containers, hardware, platforms—and sometimes serverless. Flexibility and deployment options are essential to defending applications and APIs across multiple components and delivery stacks. Typically, security teams end up in a balancing act of supporting new infrastructure plans while taking over existing legacy systems and applications.

To be adequately protected, security teams must evaluate defensive tools, open source or commercial, for use in:
- Major cloud providers (e.g. AWS, Azure, IBM, GCE)
- Container platforms (e.g. Kubernetes, Docker)
- Hardware and web servers (e.g. load balancers, NGINX+)
- Serverless options (e.g. API gateways)
- Platform services (e.g. Heroku, language plugins)
- Cloud-based deployment models (e.g. hosted cloud WAF)
The modern world is ever-evolving and the definition of “modern” changes as new technology is introduced. Fast-food chains have evolved over the years and, in turn, moved the food industry forward with the introduction of fast, casual and reliable options. The companies continue to evolve to meet the customers’ demands by introducing delivery services, unique rewards programs and leading mobile apps.

The security world can learn a thing or two from the fast-food chains’ commitment to continued business evolution. Much like the way fast-food customers are quick to jump ship if they don’t see the selection they want, legacy WAF customers are learning they can make a change to other security solutions if features and infrastructure aren’t evolving.

The simple truth is legacy WAF solutions can’t accommodate today’s technology and applications, exactly how traditional fast-food can’t keep up with customers’ growing demand for tasty yet quick meal options. This leaves proprietary data exposed and vulnerable to attacks. It’s time for security leaders to take action and upgrade their systems while getting their teams up to speed without sacrificing security of their vital assets.

— Jonathan DiVincenzo
August 12, 2019
Helping Developers Win in the Shift-Left Revolution

The shift-left revolution is upon us. Just because it’s a cliche, doesn’t mean it’s not true. As software development organizations continue to implement DevOps culture, processes, and tools, developers are adopting the practice of testing and ensuring the security of their applications as early as possible in the DevOps pipeline.

This is quite a change from the traditional waterfall method. There, developers dealt with the design and creation of a product or application and security professionals came in after they were finished, to review and test security, flagging any possible issues and sending them back to the software teams to figure it out.

This fundamental change in the way companies are addressing application security affects many of the moving parts in a software outfit. It requires a new set of processes, practices and tools all to be implemented, all while keeping up with today’s fast-paced release cycles.

To gain an understanding and insight on how developers are handling this hefty challenge, we polled more than 600 developers in software organizations and asked them about how security figures into their day-to-day tasks and processes, and the tools that help them to address their evolving roles.

Developers: Owning Their Shift Left

The first thing that we wanted to learn is whether developers are on board with the shift-left approach that most organizations have adopted for security testing. Our findings showed that, for the most part, developers are taking ownership of the day-to-day operational responsibility for AppSec in their organizations, playing a more significant role on this front to secure their products.

When asked who owns the day-to-day operational responsibility for AppSec in their organizations, 23% answered that developers own those responsibilities, 21% said DevOps, 28% said software development team leaders owned it and only 29% said security teams in their organizations are the owners.

The fact that a whopping 71% of developers put the ownership of AppSec squarely on the shoulders of software development and DevOps folks means that developers are very much on board with the shift-left movement and have taken on the new security tasks that come along with that.

Breaking it down, we also found that in smaller organizations, more developers and DevOps professionals feel that they own their AppSec responsibilities, while those percentages go down with larger organizations. This can be explained by the fact that often smaller companies have less specialization, requiring developers to branch out of their professional comfort zone. Smaller organizations also tend to allow developers more freedom and flexibility to define their own processes.

Do these responses mean that in addition to their focus on innovation, functionality and quality, developers have also added security into their considerations when they are in the process of creating and building projects?

The answer would appear to be yes, according to 58% of developers in our survey, with an additional 39% saying that security figures into their consideration when issues arise (14%) or that they validate security before deployment (25%). Only 3% of developers said that security is none of their concern since it slows them down.

Are you taking security into consideration when developing software?

While their responses show that there is still a ways to go before security is completely baked into development processes, it’s clear that most developers are already in the right direction, making security a priority within their tight schedules.

The AppSec Process: Who’s On First?

How does making security a top priority or at least a consideration figure into the different phases in the DevOps pipeline? Practically, where is it being applied? We asked developers at which phase in the software development life cycle (SDLC) they started testing their AppSec.

Their answers showed once again that developers are taking on security where it traditionally was not a part of their workflow. In fact, many replied that they are integrating security testing tools as early as the pre-build stage, with 36% of the respondents saying that they are testing in their IDE and repositories.

Survey results also showed that along with the DevOps processes, they are also adopting tools that help them to shift security further left. 68% of developers report using at least one AppSec technology such as SAST, DAST, SCA, IAST or RASP. All of these automated solutions help security teams and developers detect potential security issues in their products, providing software teams with visibility and control over their AppSec.

A Question of Remediation

Until now, survey results show that developers have taken their place on the front lines of AppSec and the shift-left revolution, arming themselves with an impressive collection of automated detection tools. However, these solutions are creating a new set of issues that should worry stakeholders.

It appears that the much-needed security testing tools are threatening to bury development teams under a mountain of alerts, which they are now required to research and remediate while keeping up with their deadlines. It’s impossible for developers to keep up with all of the security alerts in their inbox, especially considering that many AppSec tools were developed for security teams and focused on widespread coverage (detecting all potential issues), rather than accuracy and prioritization.

This poses quite a challenge for developers, who say that they are spending a substantial chunk of their very valuable time dealing with remediation-related tasks. A full 42% of the respondents reported that they spend between two and 12 hours each month on these tasks, while another 33% said that they spend 12 to 36 monthly hours on them.

In light of these time-heavy statistics, it is clear that developers need new technologies and practices that will allow them to prioritize security without slowing down the development life cycle and costing them so many valuable work hours.

Helping Developers Win the Race to Remediation

The survey results showed that developers today are required to take the lead when it comes to application security, but need more backup to do so. Detection tools can take developers part of the way, but to empower them through to remediation, organizations must provide them with developer-focused solutions that can help them to close the loop from detection to remediation.

Once developers are alerted to a newly detected security vulnerability in their project, they need to validate it, assess its impact, research remediation options and perform the remediation path chosen. Currently, these are all time-consuming manual processes that require a level of skill and proficiency.

With developers poised to face security head-on, organizations expecting them to fully address AppSec need to provide them with the tools that will easily integrate into their native environments and help them take vulnerability management one step further, enabling them to prioritize security alerts so that they can get to the most burning issues first and even automate their remediation process.

— Ayala Goldstein

August 7, 2019
GitLab Survey Surfaces Major DevSecOps Challenges Ahead

A report based on a survey of 4,071 software professionals published this week by GitLab, a provider of a continuous integration and continuous deployment (CI/CD) platform, found that while appreciation of the potential value of DevSecOps best practices is high, the ability to implement those practices is uneven at best.

According to the survey, half of the respondents reported that security vulnerabilities are discovered mostly by the security team rather than developers after code is merged and in a test environment. And, when cybersecurity professionals participate in a DevSecOps process, the survey found those organizations are three times more likely to discover bugs before code is merged. In addition, a full 90% of those organizations are more likely to have tested between 91% and 100% of their code early in the development process.

Obviously, that’s better than discovering them after they’ve been deployed in a production environment. On the downside, however, nearly half of security professionals participating in the GitLab survey (49%) said they struggle to get developers to make remediation of vulnerabilities a priority. That challenge may reflect the overall maturity of the DevSecOps practices in place. For example, only 25% of developers participating in the survey rated their security practices as being good. That compares to only 20% of security professionals who rated their processes as good. Only 14% of respondents said they are relying on application security tools to test more than 91% of their code. A full 44% are using these types of tools to test less than a third of their code.

Priyanka Sharma, director of technology evangelism for GitLab, said the survey makes it clear that DevSecOps is now officially a thing in the enterprise. However, only 44% of the survey respondents said that security vulnerabilities are a performance metric for developers in their organizations. As such, it’s clear there is still a long way to go before anything approaching DevSecOps nirvana is likely to be achieved. In fact, Sharma noted building and deploying more secure applications may require organizations to slow down the rate at which applications are being built, at least initially.

The GitLab survey makes it clear most organizations are still struggling with mastering DevOps. Only 28% of developers said they feel good about their organization’s level of DevOps sophistication, while less than half (45%) said they have been able to implement continuous code deployment at least somewhere in their organization. That level of adoption suggests there still is plenty of opportunity to refine DevOps processes that are not fully ingrained. In fact, it appears most organizations are still trying to master agile development methodologies—more than half of the respondents said they employ Scrum (54%) as their application development methodology, followed by Kanban at 37% and DevOps at 36%.

Ultimately, most organizations will have no choice when it comes to embracing DevSecOps. There simply are not enough cybersecurity professionals available to secure every application on their own. That means developers will need to assume more responsibility for cybersecurity, regardless of whether they like it. DevSecOps processes will be required to validate whether developers have implemented all the security patches and controls required. Anything less than that going forward will be deemed as nothing short of reckless—which, as any lawyer will gladly share, means much higher penalties for everyone involved.

— Mike Vizard

July 17, 2019
DevSecOps Survey Finds Failure to Communicate

While it’s generally agreed that shifting more cybersecurity responsibility onto the shoulders of developers is a good idea, a failure to communicate across application development and cybersecurity teams has contributed to little progress in achieving DevSecOps.

A survey of 1,310 IT decision-makers conducted by the market research firm Vanson Bourne on behalf of Trend Micro finds that while nearly three-quarters of respondents (74%) said integrating developer, IT operations and cybersecurity processes has become more important over the past year, more than one-third (34%) said these silos are making it more difficult to create a DevOps culture in the organization. A full 89% said software development and IT security teams needed to be in closer contact, while 77% said the same for developers, security and operations.

Greg Young, vice president of cybersecurity for Trend Micro, said the two biggest challenges in achieving DevSecOps historically are the lack of trust between developers and cybersecurity professionals and a lack of tooling to foster collaboration and communication across teams.

The rift between developers and cybersecurity is well-known: Application developers have been known to give short shrift to cybersecurity guidelines to make a deadline, only to have that application breached in a production environment. However, developers can counter that cybersecurity professionals can slow things down too much, in the name of being overly cautious.

Young said organizations need to find tools that make it easier for those two teams to establish trust within the context of an integrated DevSecOps process. Rather than just relegating cybersecurity teams to defining policies, cybersecurity professionals need to find a way to provide input during all stages of the application development process without compromising the overall agility of the development team, he said.

In fact, survey respondents identified fostering greater integration between teams (61%), setting common goals (58%) and sharing learning experiences across teams (50%) as the best ways to achieve DevSecOps. The trouble is, 78% of respondents said their organization needs to improve in all these areas.

Unfortunately, nearly half of respondents (46%) said they have only partially developed their DevOps strategy, with only a third of respondents (33%) saying DevOps today is a shared responsibility between software development and IT operations.

Regardless of how organizations achieve DevSecOps, the one certain thing is most organizations have no alternative. The rate at which applications are being developed today generally exceeds the ability of short-handed cybersecurity teams to keep pace. The only way to make sure applications are more secure than they have been historically is to make implementing security controls part of the application quality assurance process. That said, cybersecurity teams most likely will take a “trust, but verify” attitude toward developers to ensure the right controls have been put in place.

Of course, none of this is going to happen of its own accord. Senior leaders need to make DevSecOps best practices a requirement. Otherwise, DevSecOps will always remain one of those many aspirational IT goals that go unfulfilled.

— Mike Vizard

July 9, 2019
5 Ways DevSecOps Can Manage Software Supply Chains

The unbridled use of open source components within the software supply chain is on a major uptick, according to new research. Even as this surge in open source dependencies fuels faster innovation, the study shows that it comes with high cybersecurity costs, as the number of breaches related to these components is similarly on the rise.

However, the numbers also indicate there are some clear practices used by the best DevSecOps teams to minimize the risk while maximizing the speed and agility that third-party components offer.

Sonatype and research partners from IT Revolution and Galois made a thorough analysis of download patterns, software component makeup and DevSecOps behaviors around open source components and third-party libraries for the “2019 State of the Software Supply Chain Report.” Their analysis found that the rate of open source component releases has picked up by 75% in the last two years and that download requests from teams using these components have risen 68% year over year.

Most tellingly, the study showed that among modern applications today, 85% of the average code base is comprised of open source componentry. Not only are the majority of applications using open source components and libraries, but also they depend on them heavily.

“The practice of assembling open source component releases into the form of an application screams of efficiency. Developers no longer need to code every line from scratch,” according to the report. “Developers can download component releases in seconds that deliver new capabilities, built by experts outside of their organizations who make their code freely available to others.”

Perhaps not coincidentally, the study noted a parallel rise in breaches associated with open source component use. Last year 1 in 4 organizations suspected or verified they experienced a breach related to open source components in the last 12 months. That’s a slight improvement over last year’s stats, which had it pinned at 1 in 3 organizations. But since 2014, that rate of breaches has risen by 71%.

The trouble is, many of the components developers download and integrate into their code are full of dangerous vulnerabilities. For example, just over half of all JavaScript package downloads contain known vulnerabilities, with 1 in 3 rated as high vulnerabilities. One in 10 of those flaws were rated as critical.

The point the report hammered home is that not all components are created equally. There exists a certain class of well-run open source projects that release updates more frequently, update problematic vulnerabilities faster and remediate flaws more quickly. It is up to DevSecOps teams to systematically manage components, so they leverage more of these high-quality open source projects and try to avoid the riskier open source dependencies.

“Management of software supply chains is not simply ensuring quality at velocity. Our supply chains are being attacked by adversaries in new and creative ways,” according to the report. It found that organizations that actively manage their supply chains are able to reduce the proportion of vulnerable components by 55% compared to those who do not.

The report found several software supply chain practices contributed to this reduction of risk, with the following five standing out as the most impactful:

Develop a governance program: Foundational to this is having some sort of open source governance or standards policies in place, according to the report, which noted that among the best DevSecOps organizations at managing risky components, nearly 3 in 4 have such policies in place.

Have a process for evaluating and adding new components: As a part of that open source policy, the best teams have standardized processes for how developers add new open source components. This includes how these components are evaluated, approved, standardized and so on. The exemplary organizations are 11 times more likely to use this kind of process for new dependencies.

Proactively remove problematic components: New vulnerabilities are discovered every day, so simply evaluating a dependency upon its first inclusion in an application can only take an organization so far. The best organizations also take the initiative to look for potential sources of open source vulnerabilities in existing code. That includes proactively seeking out and removing known vulnerable dependencies, as well as reducing the attack surface of the code by eliminating open source dependencies that aren’t being used. The best organizations are 9.3 times more likely to do so.

Aim to always use the latest versions of components: It should go without saying that the latest version of any given component has the least vulnerabilities. The report showed that component releases that are 3 years or older have a 65% higher defect rate compared to newer components. Exemplary organizations strive to use the newest updates of all of their open source components and are 6.2 times more likely to do so than other organizations. That doesn’t happen accidentally—these teams are 10 times more likely to schedule update dependencies as part of the daily work of DevSecOps teams.

Use Enforcement Automation: Just having a policy in place is not enough—organizations need to enforce the open source standards to reduce risk meaningfully. The study showed that DevOps practices combined with automated enforcement of policies increase developer adherence to standards by 150%. The exemplary teams with the lowest open source defect rates are 12 times more likely to have automated tools to track, manage and/or ensure policy compliance of open source dependencies.

All of these best practices add up to less risk from components, as well as less pain for DevSecOps teams, who are three times less likely to consider the process of updating components as painful.

— Ericka Chickowski

July 1, 2019
Why Workload Security Is Not Just for IT Anymore
Once upon a time, workload security (which means making sure an application and its environment are configured and deployed securely) was something that developers didn’t have to think much about. Developers’ only real security responsibility was to write secure code. After they passed the code off for building, testing and deploying, it was someone else’s job (specifically, the IT department) to secure the workload of which the code was a part.

That’s no longer the case. Today, workload protection is the responsibility of the entire DevOps team, not just IT engineers.

Let’s explore why, and what this change means for developers.

How Security Problems Flow Down the CI/CD Pipeline

To understand why workload protection has become everyone’s responsibility, you have to understand how DevOps and CI/CD have given rise to new types of security challenges.

In an organization that has embraced DevOps, code is intended to flow continuously, in a so-called CI/CD pipeline, from development to testing, to building and, finally, to deployment. To keep the CI/CD pipeline flowing smoothly, DevOps teams typically strive to standardize and automate as many processes as possible.

From the perspective of efficiency and reliability, standardization and automation are great. They are key to enabling continuous software releases.

When it comes to security, however, standardization and automation have a downside, which is that a configuration problem introduced at one stage of the pipeline can flow down the pipe and reach production environments easily without anyone noticing.

This is true for two main reasons. First, standardization and automation minimize the amount of human intervention and oversight that go into the CI/CD process. Again, that’s exactly the point, and it’s a benefit in most respects. But when it comes to security, less human intervention means a greater chance that a security problem will go undetected (particularly if you don’t have automated security tests or audits in place to catch the issue).

The second major risk associated with standardization and automation within a CI/CD pipeline is that sometimes, developers might set a configuration that they don’t intend to be used in production, but is pushed into production nonetheless by the automated pipeline.

For example, developers might place code inside a container to help with testing or staging, without intending for that same container to be used in production (instead, they assume the code will be repackaged before being deployed). Because they don’t intend for the container to be used in production, they don’t use a secure configuration for it. Maybe they let it run as root, for example. Then, if communication breaks down and a release automation tool pushes that container into production without changing the configuration, a container with a security flaw will end up being deployed.

To learn more about security and compliance for DevOps, check out our recent webinar.

Extending Workload Protection Beyond IT

In a perfect world, the IT team would be able to catch these flaws. But the reality is that in a fast-moving CI/CD environment, it’s not realistic (or fair) to expect IT alone to make sure that workloads are configured securely before they are deployed.

Instead, the entire DevOps team needs to take responsibility for workload security.

What that means specifically will vary from organization to organization, but in general, extending workload protection beyond IT means the following:
- Making sure that developers (and not just IT engineers) understand workload security best practices and why they are important to follow at every stage of the CI/CD process.
- Establishing and enforcing (via automated audits) policies for how workloads can be configured at any stage of the CI/CD pipeline. For example, the DevOps team as a whole might agree not to run containers as root, even if it’s only in pre-deployment.
- Enabling runtime protection by scanning for vulnerabilities that appear within applications and environments once they are live.
- Securing data at all stages of the CI/CD pipeline and scanning data for signs of intrusion or malicious code.
- Performing continuous security monitoring and vulnerability detection (both pre-deployment and post-deployment) to catch issues as quickly as possible, even if they have slipped through the cracks of earlier security tests.
Conclusion

It would be nice for developers if workload security was not their responsibility. But in the age of CI/CD and DevOps, they no longer can hand off that burden to the IT team. The IT team still has an important role to play in making sure workloads are deployed securely, but effective workload security for DevOps starts early in the CI/CD pipeline—with developers. Code moves too quickly down the pipeline for developers to assume that they can safely do one thing with a workload and have the IT team change it before the workload is deployed.

Symantec Cloud Workload Protection (CWP) helps organizations monitor and protect their workloads, no matter where they reside. With CWP, organizations don’t have to look for multiple products to meet their many security needs. CWP offers a single console to monitor and manage security across various platforms. It offers automatic discovery of workloads across AWS, Azure and Google Cloud, and visibility into security postures and software, which enables automatic workload monitoring and protection. With continuous delivery workflows and malware prevention, CWP is essential for modern software development.

Sign up for a free trial of Symantec CWP.

— Chris Riley
June 6, 2019
What is Cloud-Native Workload Protection?
We’re living in a cloud-native age. That means that many of the paradigms that worked in the days of on-premises hosting no longer suffice.

Chief among them is security. To thrive in today’s cloud-native world, organizations need to rethink their approach to workload protection and bring it up to speed with cloud-native environments.

In this article, I walk through what that means by explaining how cloud-native computing changes the calculus of workload protection and security.

The Rise of Cloud-Native Computing

More and more organizations are shifting from on-premises hosting to cloud-based environments built using shared infrastructure. As a result, applications and infrastructure these days exist in more dynamic and complex environments that contain a lot of moving parts and are dependent on a slew of external resources (which, in turn, may rely on other compute and infrastructure resources). Thus, we have to think in terms of an entire workload (instead of just our application code) for our applications to run effectively on the cloud.

This new paradigm is enabling the concept of “cloud-native workload” to gain traction. We can think of this as a distinct capability that we can run on a cloud instance—in other words, all of the resources required to make an application functional, which could be anything from a web server to a database, to network resources, to the data that needs to be fed in (and of course the application code itself). A lot of these workloads likely would run on containers.

These discrete sets of workloads running on cloud platforms necessitate a new way of mitigating risks and protecting our application and its dependencies. Cloud-native workload protection is a security category that is fast becoming very relevant among security-minded folks and distinguishes itself from application security. Applications are only part of a broader context of workloads (which may include things such as deployment and monitoring), and we must think of security in terms of a workload. Any means of protecting these workloads and mitigating risks and attacks against them is what cloud-native workload protection refers to.

Although cloud environments can be more secure than self-hosting on-premises, security is a shared responsibility, and our cloud workload protection strategy does not fully fall into the hands of our cloud service provider. Surveys have discovered that many companies have at least one critical security flaw in their AWS configurations. We must take precautions and be proactive when it comes to protecting our cloud-native workloads, which could mean extending security policies and tools we have for our cloud-based systems.

Security may be the greatest challenge for cloud-based workloads due to the myriad components that require a security analysis, along with the different attack plane combinations that these components produce together. We will dive deeper into what protecting our cloud workloads means in this new environment.

Security Threats in Cloud-Native Environments

We need to be aware of system vulnerabilities, data breaches, account hijackings and insecure APIs. We also need to identify any flaws in our identity and access management protocols and make sure two-factor authentication is enforced. Other considerations include running due diligence on third-party systems and understanding the implications of sharing cloud resources with other users on the same platform—we also may be compromised if they are.

Finally, we need to understand containers and their implications in terms of security. Containers are particularly vulnerable because their ephemeral nature makes enforcing standard security difficult, and the variations in container images introduce more points of entry. This makes intrusion detection in cloud environments a tricky business.

Discover

Perform regular assessments that oversee and can uncover weaknesses in this dynamic environment. Make sure to routinely test code for any weaknesses, monitor new deployments for vulnerabilities and breaches, then keep a watchful eye on security logs and fire off appropriate alerts. Manage and monitor network security and ensure the visibility of all traffic.

Visualize

We can’t understand what we need to control if we don’t maintain an effective visibility strategy. This entails being able to visualize the workloads that we are running and being able to act swiftly if there are problems related to the workload. Ideally, some type of central interface can allow us to synthesize different workloads and events to help us manage our security solutions and tools.

Protect

Cloud platform providers are responsible for securing the physical hardware infrastructure and virtual machine instances, but we are responsible for securing access to and between our workloads that are running on this infrastructure. So we must maintain the operating systems that we have chosen to run on these virtual machines, and be diligent in applying security updates and patches and installing antivirus software.

Implement some real-time policies and best practices that prevent the propagation of exploits, and restrict access to servers as much as possible and ensure the correct configuration of your firewall. Have a system for managing configurations, patching, logs and administration privileges. Regularly audit your system and procedures. Are you running any arbitrary code?

Invest in a Cloud-Native Workload Protection Platform

To optimize your cloud-native workload protection strategy, it may be beneficial to look into outsourcing the work to security platforms by trusted leaders in cybersecurity (e.g., Symantec Cloud Workload Protection Suite). These platforms can employ advanced and comprehensive protection for all types of cloud workloads against exploits that traditional methods cannot sustain. It can scale easily and automatically, be controlled from a single cloud-based dashboard and provide automatic discovery, visibility and protection of cloud-native workloads.

Remediation

Despite your best efforts, some security issues will arise. That’s why it’s important to have a remediation plan in place. Your remediation plan should include guidelines that define who will respond to security incidents, how information about incidents will be shared within your organization and how response actions will be recorded. For more serious incidents, it is also wise to have a plan in place for handling any legal- or PR-related concerns.

Compliance

Meeting compliance requirements is not the only reason to secure your cloud workloads. But it is one important reason. Non-compliance could mean fines, as well as a loss of reputation. Compliance needs vary from case to case, so you’ll need to determine which compliance frameworks apply to your business and workloads, then take steps to ensure that you are in compliance. You’ll also want a plan in place for revisiting your compliance policies periodically, to make sure that you remain compliant even as the rules and your workloads evolve.

Data

Data protection is a big topic, and even more so with the advent of the PII and GDPR data compliance regulations. As mentioned previously, the shared responsibility model between the cloud platform provider we choose and us means that we remain responsible for the protection and security of sensitive customer data. To avoid failing a data security compliance audit or suffering the consequences of a data breach, we must implement some protective policies and build governance and controls surrounding data stores into the business:
- Enforce the appropriate levels of authentication according to the sensitivity and availability needs of the data. Use security groups to give authorized access and make sure that services and service accounts are securely implemented.
- Refine your data retention policies. A breach of data is often unavoidable, so have a plan in place to periodically erase data that you no longer need to minimize the loss incurred during a breach.
- Encrypt all data at rest and data in transit when dealing with your cloud-native workloads. Cloud platform providers cannot be relied upon to guarantee end-to-end encryption for data in transit.
- Use additional external tools to safeguard data. Consider safeguarding to be the highest priority and leave nothing to chance.
Learning More

It is crucial for businesses adopting cloud platforms to have a cloud-native workload protection strategy, understand the threats that exist for this new landscape and ensure the security of their cloud implementation within the infrastructure from their cloud provider.

This new complexity can be managed with a more sophisticated protection strategy. Symantec is a leader in cybersecurity, and its offerings are designed to meet the unique challenges that businesses confront in this cloud-native landscape. Find out how to use their tools to protect cloud-native workloads.

Be sure also to check out Cloud Security Alliance, a non-profit organization that has performed comprehensive studies on best practices and new requirements for cloud computing.

To see how Symantec’s CWP product can help you secure cloud-native workloads, sign up for a free trial.

— Daisy Tsang
June 4, 2019
Open Innovation Labs: How Lockheed Brought Better Security to Fighter Jets

How Red Hat’s Open Innovation Labs have helped accelerate Lockheed’s software development for the F-22 Raptor

As the key government contractor charged with helping the U.S. Air Force keep its F-22 Raptor jets in fighting trim, Lockheed Martin Aeronautics increasingly values software delivery speed as much as engine speed. So much of the continued evolution of these fighter jets depends upon continual upgrades of the software code powering all of the physical systems built into them, from tip to tail.

Until a year ago, these jets, which first rolled out of the manufacturing plant in the 1990s, were supported by the waterfall development methods of that same era. Lockheed executives and Air Force brass recognized that the F-22 needed a DevSecOps transformation, and fast.

“When you have a world-renowned platform like the F-22 Raptor, adversaries are constantly looking for ways to counter it,” said Michael Cawood, vice president of F-16/F-22 product development at Lockheed Martin. “This means we must constantly add capabilities and improve the F-22. And we must do it faster than ever before. We needed to transform our own organization and how we did things.”

To accelerate that process, Lockheed last year sent a small contingent of engineers through a residency program at the Red Hat Open Innovation Labs to fast-track the process of implementing an open source architecture onboard the F-22 while adopting agile development methodologies and DevSecOps practices. Since bringing back their learning to the organization, these engineers helped to catalyze a faster development process that has helped Lockheed introduce software features for the F-22 years ahead of schedule.

How Open Innovation Labs Works

Now in their third year of operations, the Open Innovation Labs were developed by Red Hat as immersive training grounds to help its enterprise customers figure out how to deliver better software, faster. A standard engagement has companies such as Lockheed pay for residency for anywhere between three to six developers and operations staff to get paired one to one with Red Hat employees—engineers, consultants and others—with deep knowledge in DevOps and agile development. They work with them in a time-boxed four- to 12-week engagement to build out application prototypes using DevSecOps practices along the way. The residents are also teamed with a designer and an engagement lead who doubles as an agile coach, typically working with the customer’s product owner for the prototype.

Obviously, Red Hat has a vested interest in training these people in technology such as its OpenShift Container Platform, getting them up to speed on how to orchestrate and manage containers and microservices. But the labs approach is in a different league than the standard vendor training program. It more closely follows the DevOps dojo model that enterprises like Target and Capital One are running internally to scale up cultural and process transformations across their IT organizations. Like those dojos, the working model is to build real software through a guided learning process that helps participants get hands-on experience in how to change the way they deliver software.

Red Hat runs the labs either out of a handful of dedicated spaces it runs around the world or within pop-up labs of the customer’s choosing. Besides Lockheed, other notable alumni include the likes of Volkswagen, UNICEF and Heritage Bank. According to a recent analysis by Forrester Consulting, participants in the Open Innovation Labs program are accelerating application development by more than 60%.

Lockheed’s Accelerated DevSecOps Transformation

In Lockheed’s engagement with the Open Innovation Labs, the organization sent out a cross-functional team of five developers, two operators and a product owner. They were tasked with building out a new application for the F-22 on OpenShift, using that process as a model for future development workflows. As a part of the process, Lockheed also worked with the labs to help it build out an internal dojo that could facilitate the scale-out of the knowledge gained by its small team across the entire F-22 development team. Six months after the initial residency, Lockheed managed to scale its OpenShift deployment and DevSecOps transformation across its entire 100-person team.

“By working with the Red Hat Open Innovation Labs team, we changed everything—our toolchain, our process and, most importantly, our culture,” explained Cawood.

As a result, the F-22 development organization has been able improve its ability to forecast for future sprints by 40%. More importantly, it has cut what was once an onerous five- to seven-year process of rolling out new software capabilities for the aircraft. Lockheed is on track to deliver new communications capabilities for the F-22 this summer a full three years ahead of schedule.

— Ericka Chickowski

May 21, 2019
4 Steps to Introduce DevSecOps to Database Development

Although DevOps was implemented within application development, there is a growing awareness that including the database within DevOps processes is vital to success. We live in a data-driven world and many front-end applications use a database at the back end to collect, process and store customer and user data.

The faster development of applications that DevOps encourages also results in more frequent updates to databases. By excluding database development from DevOps, the database becomes a counterweight to the speed of releases that otherwise can be gained.

This is already being recognized, as demonstrated in the 2019 Database DevOps Survey from Redgate, which found that 77 percent of application developers are now responsible for database development and 75 perent build database deployment scripts.

All of which is welcome news, provided DevSecOps for the database is also taken into account.

While DevSecOps is relatively new (the term was coined in 2012 by Gartner analyst Neil MacDonald), the need for it is a widely accepted facet of DevOps because DevOps radically changes how companies tackle security in application development. Whereas security used to be reviewed and certified at the end of long development cycles with a scheduled window, that window has now disappeared. Hence the rise of DevSecOps, which bakes security into the development process, with tools such as static code analyzers and open source code vulnerability scanners testing code as soon as changes are made.

In the same way that the database must be included within DevOps if the process is to be seamless, companies also need to ensure that DevSecOps is applied to the database. In fact, given the importance of protecting personal data in today’s world, ensuring privacy and security is imperative for both compliance and public reassurance.

In 2017, MacDonald continued his work on defining what DevSecOps is when he set out 10 steps that companies need to follow to protect applications during development. All of these are equally relevant to DevSecOps for the database, with the exception of the second step: Quit trying to eliminate all vulnerabilities during development. Many databases contain personal data, much of which is sensitive, so every vulnerability during database development has to be addressed and resolved.

Looking in detail at Gartner’s list, I’d say there are four key steps that particularly apply to DevSecOps for the database:

Identify the Vulnerabilities

At the center of DevSecOps for the database is the data, which has to be protected from both internal threats such as negligence or accidental exposure, and external threats such as hacking. The biggest problem with data, however, is its size and sprawl. Data is growing at an annual rate of 58 percent, according to IDC, and is now stored in a multitude of different places.

To identify what the vulnerabilities are, the data first needs to be located and classified and its risk identified. Data mapping exercises such as this can be done by hand or with a third-party tool, but it’s important to create a record of every database, including copies used in development or testing, to gain a real understanding of where data is stored and who has access to it. Classifying the data then can be undertaken to identify which data is sensitive and at risk, such as credit card details, and therefore needs to be protected.

Remove the Vulnerabilities

As we’ve seen, the recommendation to not try to eliminate every vulnerability in application development doesn’t apply to the database. Where data has been identified as sensitive and at risk, access must be limited and it cannot be widely shared.

Developers, however, often need a copy of the production database in their development, test, or QA environments to ensure changes will work once deployed. However, those same production databases invariably contain sensitive data that needs to be protected.

One solution is to create a version of the production database with a limited dataset of anonymous data. However, this means it is neither realistic, nor of a size where the impact on performance can be assessed. A second solution is to take a copy of the production database and mask the data manually, but this will age quickly as ongoing changes are deployed to the production database.

Therefore, data masking measures such as pseudonymization, encryption, anonymization and aggregation should be adopted, and companies can use third-party tools to help mask database copies, yet also provide development teams with test data that looks—and behaves—in the same way as real data.

Introduce Secure Coding

While application development typically uses an imperative programming language such as C# or Java, database development relies on a declarative language, such as T-SQL for SQL Server, which is less strict and where the coding standards vary widely.

This has resulted in developers who code in T-SQL having their own styles and preferences. With multiple developers writing updates, this often ends up with code that is confusing, difficult to understand and with errors that can cause deployments to fail.

To overcome this, code should be written in the same style, with a secure approach that follows set standards, put in place by the database administrator. Introducing this secure coding mindset at the point code is written will prevent problems later down the line.

Automate Where Possible

The ninth point in Gartner’s list is to implement strong version control on all code and components, with developers checking their changes into a common repository during the development process, preferably at the end of each working day. As a result, everyone has access to the latest version of the application, and it is always clear what was changed, when it was changed and who changed it.

This is just as true for the database code, which also can be version-controlled, preferably by integrating with and plugging into the same version control system used for applications.

Importantly, once version control is in place, processes further along the development pipeline can be automated. Continuous integration can be introduced, for example, to automatically test changes as soon as they are committed and ensure they are not breaking changes.

Data has been described as the 21st century equivalent of oil, with its use central to success in every organization. Given its sensitive nature, protecting it is equally vital. That’s why all businesses and teams need to ensure they are not only including the database within DevOps, but within DevSecOps as well.

— Matt Hilbert

March 25, 2019