devopsy.kinsta.cloud

Category: Symantec

Self-Service Workload Protection for DevOps Teams
Everyone (or almost everyone) in the DevOps world likes to talk about the importance of security. But too often, these DevOps security conversations end with generic recommendations such as, “Follow the OWASP Top 10.”

Don’t get me wrong—reference frameworks such as OWASP are great resources for helping to guide DevOps security. But it’s usually far from obvious to many DevOps teams how to bridge the gap between the abstract theory of these frameworks and actual practice. That’s especially true given that many DevOps teams spend their days putting out fires in fast-moving CI/CD environments and have little time to step back and operationalize security best practices, even if they know they should.

In this article, I’d like to present one real-world strategy for implementing the DevOps security best practices outlined by organizations such as OWASP. That strategy is what I call self-service workload protection. The term refers to making security not just something that DevOps teams recognize as important in the abstract but an easy-to-use service that anyone on the DevOps team can operationalize just like any other process within the CI/CD pipeline.

In other words, we need a self-service approach for offering workload protection through an accessible library of policies and tooling that DevOps teams can leverage on demand. Let’s take a look at how we can achieve that in practice.

Understanding Self-Service Workloads

To understand how self-service workloads work, we need to know the common parameters that define a secure and properly configured application deployment. With that information, security teams can automate the process and offer a complete set of reusable and adaptable tools for DevOps service teams to run.

The common parameters usually boil down to the following factors:
- Making sure that all required compliance and security scans run at least once for every deployment. Those scans need to use preventive actions and block insecure deployments.
- Making sure that for any new vulnerabilities found, we add them to the list of checks. (For example, we should be able to see updated reports for new issues as they’re discovered.)
- Performing audit reports and continuous security monitors over the development and production sites to capture security issues.
- Establishing sane and pragmatic secure default policies and authorization profiles.
The above parameters should be captured and packaged as a self-service solution and used during the normal flow of operations—for example, CI/CD pipelines, validation and compliance checks, creating and uploading a new image to a container registry, etc. This means the security team will have to spend some time to make sure the application of workload protection policies is a team effort.

For more tips on automating security, check out Symantec’s recent webinar on security and compliance for DevOps.

How to Make Security Better Via Self-Service Workload Protection

From the perspective of the security team, the main goal is to make security accessible to everyone in the organization. Not only that, but the tooling and resources they offer need to be documented and easy to use. The DevOps team should be able to plug in security controls without knowing their ins and outs, though they need to have the means to let the security team know if something goes wrong. Let’s explore how we can make this process better.

Shift-Left Security Through CI/CD Pipelines

Shift-left security is the main focus point of the security team, and it’s also the most tricky to get right. By adding more security checks and audits earlier in the development process, there’s a risk of stepping into other people’s ponds (which may degrade their workflow experience).

A better approach is to give more responsibility to the DevOps team and let them determine the best possible integration point. Mistakes will be made, but important lessons will be learned. Gather feedback from the process and, if required, iterate over the agreeables. That way, everyone will benefit. If the appropriate steps are taken, the security team will have a way to apply its security checks during the development process, and the DevOps team will have its infrastructure protected (at least from known risks).

Test automation and continuous integration points are the most obvious solutions, as they are the most automated parts of the system. The security team can go the extra mile and offer reusable policies and deployment steps that can be added on each deployment type. For example, they could offer a container image that is bundled with security checks and frameworks that test common security issues. The DevOps team can simply enable the checks via the CI/CD dashboard and during the build stage the check would act as a gateway if a security check fails.

In addition, the security team can share infrastructure policies and secure default configuration via infrastructure-as-code tools such as Terraform using remote state. This could be enabled during infrastructure provisioning by the DevOps team, without configuring anything. Sharing state this way often improves collaboration between departments.

Pre-Baked Secure Images

Developers use VMs and containers to package their apps for the DevOps team to deploy them to production. Usually, those images host crucial configuration and services that are specific to that application. What’s more ideal than to have the security team prepare a list of safe-to-use images that are preconfigured with secure defaults and scanned against vulnerabilities? Developers just have to specify the required image by ID so that the DevOps team can use it for all deployments.

Tip: Symantec’s CWP product is integrates with Jenkins to enable simple, automated vulnerability scanning during the CI/CD process.

For example, tools such as Packer are used to create identical images for AWS compute instances, and features such as seccomp profiles are enforced to Docker images. With Packer, you can deploy consistent images to the cloud and integrate vulnerability scanning into the process to ensure the deployed images meet GSO guidelines. There is a small caveat here, though: If developers decide to add an external library that needs more capabilities and they don’t inform the security team, then the application might misbehave in production and the DevOps team would be caught unaware. So, it’s important to have a good communication channel and do a security assessment for each new dependency or change introduced to the system. This keeps the self-service agreement working without interruptions or misunderstandings.

Conclusion

Letting the DevOps team manage its own self-service affairs when it comes to security controls and compliance requirements is the next major step toward a more productive business model. There are additional costs, but the end results have long-term advantages.

By having a preset repository of tooling, configuration policies and pre-baked images accessed from secure portals, teams can integrate security from the start while maintaining the benefits of accelerated development. And by doing that, security and DevOps teams can improve their collaboration.

That’s great news. What’s even better is that we can use a tool that is suited for all the above tasks—Workload Security Protection from Symantec. If you want to learn more about the platform, see how it can help secure your cloud with a free trial.

This sponsored article was written on behalf of Symantec.

— Theo Despoudis
June 27, 2019
Building Continuous Compliance into DevOps

“Continuous” is one of the operative words of DevOps. A major goal of DevOps is to make all processes continuous, which means having them proceed smoothly and constantly to avoid delays or pauses within the software delivery process.

You’ve probably already heard of the importance of continuous integration and continuous delivery. But the importance of continuousness doesn’t end there. It extends to every component of the software delivery process, including compliance.

To illustrate the point, let’s take a look in this article at what continuous compliance means and how to achieve it.

Defining Regulations and Compliance

Regulations and compliance are two sides of the same coin. Regulatory bodies put in place regulatory laws and policies that are aimed at the benefit of the broader economy and end consumers. Organizations under the purview of these regulatory bodies must put a compliance framework in place to meet regulatory requirements.

Here are three of the most widely applicable regulatory requirements that organizations commonly need to adhere to today:

HIPAA

HIPAA, or Health Insurance Portability and Accountability Act, is applicable to healthcare organizations. It concerns the handling and protection of PHI data (Protected Health Information). The costs for mishandling healthcare data are steep for users. According to research done by Accenture, 26% of healthcare consumers were subject to data breaches, and it cost each victim an average of $2,500. Stats such as this make a strong case for HIPAA compliance.

PCI DSS

The PCI DSS (Payment Card Industry Data Security Standard) is a regulation for the financial services sector. It governs the use and handling of users’ financial data, such as credit card information and bank account information.

GDPR

The GDPR (General Data Protection Regulation Act) went live in the European Union in mid-2018. It defines policies related to how organizations handle data of users in the European Union. This includes giving customers the right to erase all their data from a company to ensure the organization doesn’t have indefinite possession of the data and to ensure confidentiality of users’ private information.

Why Continuous Compliance?

Cloud-native computing brings new complexities to how applications are delivered and how they handle user data. For starters, the scale of data flowing through the system at any given time is now much higher. How organizations and their applications manage this data is critical to compliance.

Audits can be outdated the very next day when dealing with such dynamic systems. For example, when new releases are deployed continuously, it’s easy for one release to expose an endpoint to a third-party application and leave sensitive data accessible to outsiders.

The regulatory requirements themselves change every few months. It’s important to keep track of these changes and adapt your systems to still be compliant. In light of this, it’s necessary to adopt continuous compliance as part of any DevOps workflow.

Achieving Continuous Compliance

Two Goals: Security and Speed

It’s easy to think of compliance as being about simply meeting regulatory requirements. However, this is far from true. When done properly, compliance also empowers your organization to operate at a pace that encourages innovation. Every organization that adopts DevOps wants to be secure and move fast at the same time. Continuous compliance is the way to achieve both these goals.

Compliance from Day One

Usually, compliance is an afterthought. However, continuous compliance requires that DevOps teams start their design and development with compliance in mind. This includes having clarity on the exact requirements, down to the fine details. With this in mind, the team can move forward to build applications that meet these requirements. To have this kind of clarity, the various teams, including business leaders, need to speak a common language and have common terms to describe the different parts of compliance.

Continuous Testing

Testing is essential to compliance. In the DevOps world, testing has undergone numerous changes. The good thing is that these changes all support continuous compliance. First, testing has shifted to the left of the development pipeline. With testing happening earlier, it’s easier to catch errors and vulnerabilities before they reach production. Second, tests are increasingly automated. This makes them predictable, measurable, repeatable and compliance-friendly.

Automated Compliance

Your compliance verification and enforcement process should be as automated as possible. Toward this end, integrating compliance checks into the CI/CD pipeline is a best practice. For example, make vulnerability scanning part of the CI/CD process by integrating it with your CI server so that checks are performed at build time automatically.

The Right Data Hierarchy

All data isn’t equally important. Some data is more sensitive. This is why you need to organize and categorize all the data in your systems. Once categorized, you can define policies to govern different types of data. This includes encrypting data at the appropriate level—and not just in transit, but also when data is at rest.

Track Access Control

In the effort to achieve control over compliance, identity and access management (IAM) plays a critical role. It helps define who is allowed to access data and what changes they’re allowed to make. When assigning access, it’s important to assign it according to teams or roles and not according to individuals. This makes IAM policies scalable and easier to control. Putting in place streamlined IAM policies negates the need to share passwords and other sensitive information. Every user can access only the data they need, and not more. This is the principle of least privilege in action.

Track Change History

Beyond IAM policies, it’s essential to maintain a change history for all users and parts of the system. The best way to implement this is to use log data as the source of truth. It delivers deeper visibility than mere monitoring events and help to troubleshoot incidents. Logs have always been a cornerstone of good compliance, and in today’s cloud era, they continue to play a key role.

Conclusion

Achieving compliance is challenging in any environment, but when you embrace DevOps, compliance presents special difficulties due to the speed at which workflows move and the importance of making processes continuous. Implementing continuous compliance takes effort, but the rewards justify it. Not only will your organization stay on top of regulatory requirements, but it will be better positioned to move quickly and innovate.

To put continuous compliance into practice, you need the right tool for the job. Symantec Cloud Workload Assurance (CWA) can help. Learn more about CWA features in this data sheet, and sign up for a free trial to see how CWA can help secure your cloud.

This sponsored article was written on behalf of Symantec.

— Twain Taylor

June 25, 2019
Building a Security Feedback Process for DevOps
The last few years have seen some major slip-ups in the security space among all major cloud providers, resulting in uncertainty and speculation. That’s understanding; cloud security is an extremely complicated subject as enterprises build and deploy applications faster than ever before to keep up with business requirements. Most of the security issues that occur in the cloud today are around compromised accounts, identity theft, malware apps and, of course, data breaches, which are business-critical and showstoppers, in many cases.

Given the dynamic environment of DevOps and the nature of the cloud, it’s a complex problem to address and fix. The most effective way is to embed security, or what is usually talked about as the shift-left of security, in the IT pipeline. If DevOps is the culture of collaboration to reduce risk by the size of change, DevSecOps is the automated security control built into each point to build a sort of self-defense mechanism.

DevOps is not about tools; it’s about philosophy and process. One of the most important processes to include to succeed at DevOps is a feedback loop that reinforces constant collaboration.

This is certainly true when it comes to security-related information. In a healthy DevOps organization, security problems that are detected at any point in the delivery pipeline are communicated quickly to all stakeholders, who can, in turn, respond accordingly.

In this post, we will look at the steps involved in building a security process that will ensure the right information reaches the right people quickly and that teams collaborate without duplicating efforts.

Automate Your Way to Better Feedback

Automation is the first step, and a no-brainer when it comes to DevOps. Without automated security tools for code analysis, configuration management, access control, vulnerability management and secrets management, it is very difficult to scale security in a dynamic DevOps environment. Manual efforts in the cloud are doomed to fail in many cases, as environments change rapidly. Hence, automate. The recommendation is to automate every security control and the entire feedback process as much as possible.

Manage Roles Right and Control Their Accesses

Identity and access management has become the linchpin in cloud security. Since it’s very easy to give people the wrong access, it becomes important to figure out who can access what resources. Access to information and resources must be secure, yet easy to obtain. All access should be given to a group rather than an individual. Mapping security access to the organization’s hierarchy is an effective way of establishing a communication loop. The right information reaches the right group of people. It is important to be able to answer questions such as the following to ensure the communication loop is efficient:
- Who can delete this VM?
- What are the resources a certain user has access to?
- Who has service accounts access?
Tools that show a relationship between users, groups, roles, permissions and resources help answer these questions.

Encrypt Secrets, Manage Their Keys

Another important step to building an effective communication cycle is controlling access to application-level secrets. Security can be improved by tightening information flow between relevant groups, which can be accomplished through creating and controlling access to secrets using principles of least privilege. Access keys to those secrets can be kept in a centralized secrets management tool or a key management tool. The rotation of these keys can be automated as often as required.

Designing for Failure and Proactively Managing Vulnerabilities

Though security personnel may cringe at the mention of the word “failure,” designing for failure means thinking ahead and having a plan B. The cloud is dynamic by design and things happen at an incredible pace, often resulting in issues of elasticity, configuration and cloud power.

Context becomes an important parameter for managing vulnerabilities because there are multiple vulnerabilities at any given time. Automated vulnerability management and configuration management solutions are available to take the complexity out of protecting cloud environments. Automation capabilities and continuous monitoring provide deep insight, intelligent recommendations and continuous protection of the cloud, thus ensuring effective management of information in the feedback cycle.

Log Everything — Everything

Just embedding security to shift left is not enough to ensure security. It is important for all relevant collaborating groups to know the status when some code is deployed. The primary source of visibility and feedback comes from logs. Effective logging strategy is the paramount attribute of security design. Logging should be enabled everywhere possible: data access logs, identity logs, admin activity logs, logs within the cloud environment, OS, network platforms, etc. Logs, though cumbersome and volume-heavy, are non-intrusive and a critical visibility tool. You need to know what’s going on before deciding to do something with the event itself, which brings us to the next step: monitoring.

Monitor Those Events

Testing departments often seem paralyzed with too many flags, which prevent them from prioritizing critical issues. Having log and event data is an important first step, but the absolutely necessary next step is to relay them into an automation strategy that will separate the unimportant, voluminous issues from business-critical priorities. Automated monitoring for events triggered makes the feedback cycle more effective. Otherwise, logs can become noise—a copious amount of noise.

Alerts and Notifications

We embed security in the code. We manage access and roles. We turn on the logs and monitor them. An event occurs. Now, who do we alert? An effective alert notification policy will ensure that notifications are sent to the right group of individuals, depending on the notification filters—the level of criticality and relevance of the issue type. Notification policies specify the conditions that trigger a notification that will be sent to the recipient. Notifications can be sent by email, SMS, voice, push messages, etc. A recipient can then acknowledge the alert, which indicates to other users that someone is working on the issue, thus avoiding duplication of efforts.

Conclusion

To conclude, automating security controls and feedback cycles enables a productive DevOps ecosystem by exposing vulnerabilities early in the product life cycle. Automation, streamlined communication and appropriate response to priorities ensure availability, network connectivity and resilience. At the same time, they reduce the possibility of a data breach and duplication of efforts. At the heart of everything is the ability to deliver code in a secure and reliable way to meet ever-evolving business needs with agility.

To see how Symantec can help maximize security in a DevOps environment, check out a free trial of Symantec Cloud Workload Assurance.

This sponsored article was written on behalf of Symantec.

— Twain Taylor
June 20, 2019
4 Things Developers Should Know About Security in the Age of DevSecOps

If you’re a developer, most of your experience when it comes to security probably centers on designing and writing secure code. You know how to prevent buffer overflows, architect your microservices in a way that helps mitigate the impact of a breach and otherwise churn out secure application code.

But the fact is that today, knowing how to keep the application itself secure is not enough—even if you are a developer. We’re living in the age of DevSecOps, and developers everywhere are being asked to play broader roles in security at all stages of the application delivery pipeline, from code implementation through to production release and management.

With that reality in mind, here’s a look at four things developers should know about security today.

What is DevSecOps, and What Does It Mean for Developers?

Before diving into four critical things for developers to know in the age of DevSecOps, let’s take a look at what DevSecOps means.

You’ve probably heard of DevOps, an approach to software delivery that emphasizes constant collaboration between developers and IT teams.

DevSecOps extends that concept by adding security to the equation. For organizations that have embraced DevSecOps, the entire software delivery team becomes responsible for helping to secure the application. Security is no longer the exclusive domain of security engineers.

In practice, DevSecOps includes work such as integrating vulnerability scanning into the build process using tools such as Packer and ensuring that images used for deployments meet GSO guidelines. Applying OWASP’s “Security by Design” principles is also a good best practice.

What that means for developers (to put it simply) is that being a security-minded developer means more than just writing secure code. Developers must now understand security challenges and best practices at all stages of the software delivery pipeline, starting with the design and implementation of code—developers’ traditional domain—and continuing through with testing, staging, deployment and post-release management—all of which traditionally were not areas in which developers played much of a role.

This isn’t to say that developers now have to bear primary responsibility for all of the things that happen after code is written. They don’t. Their main job is still to write code. But developers should have a solid understanding of the security implications of everything that happens once they hand off code to other members of the software delivery team, to ensure they are doing their best to write code that will stay secure as it travels down the pipeline.

DevSecOps Security Lessons for Developers

If you’re a developer, the DevSecOps trend means you should now have some expertise in the following:

Microservices Security is Difficult (and Developers Can Make it a Little Easier)

Microservices architectures, which have become very common because of the agility they provide to applications, create extra security challenges that were not present in monolithic architectures. The main reason why is that microservices add many more moving pieces to an application. As a result, there are more potential security vulnerabilities within the application, and detecting those vulnerabilities can be more difficult because there is more activity to monitor.

Developers can help to address this challenge, and one way is to think about security monitoring complexity when they are deciding how many microservices to create. If developers can reduce the total number of microservices in an application without sacrificing agility, they can simplify security monitoring and enable a more secure application overall.

Developers also can make sure the microservices they write log security-related information sufficiently and clearly. You don’t want to make it more difficult for your colleagues who are monitoring an application to keep track of security events because the application doesn’t log authentication information in sufficient detail, for example.

You Can No Longer Count on Firewalls

In the days when most software ran on-premises, firewalls were a handy way of isolating applications from most security threats.

Today, organizations face a string of cloud security challenges that didn’t exist when firewalls were designed. Firewalls can still be helpful in some circumstances, but in many cases, you can no longer neatly segment applications or services off from the public internet, because you need the internet for services that are spread across a hybrid infrastructure to communicate with each other.

For developers, the lesson here is that it’s especially critical to design and write code that can resist threats that originate from the internet. Even if you don’t expect a particular part of the application to be exposed to the public internet, assume it might be, either because deployment patterns change in the future or the component is exposed without anyone realizing it.

To put this another way: Developers can’t and shouldn’t expect the IT team to be able to erect firewalls that will keep applications secure. More of the burden has shifted to developers to write applications that can resist network-based security threats because the IT team can no longer deploy firewalls like it used to.

Shift Security Testing Left

DevSecOps goes hand in hand with the mantra of shift-left testing. The latter term refers to the practice of performing tests earlier in the software delivery pipeline, rather than waiting until just before deployment to do the tests.

Shift-left testing can apply to any type of software testing, including security tests. For developers, taking advantage of shift-left security testing is a useful way of identifying security flaws within newly written code early, when they can be fixed with less effort because they have not yet been integrated into the broader application code base.

Security testing at later stages of the delivery pipeline is important, too, especially because you won’t be able to detect all security flaws until you can monitor all of your microservices as they interact with each other. But the time developers have to spend rewriting code to address security issues will be reduced greatly if their organization takes advantage of shift-left security testing.

Don’t Be Afraid to Ask for Compliance Help

A final point worth mentioning relates to compliance. Compliance is becoming ever-more challenging. And so is creating applications that meet the security requirements of compliance frameworks.

In the past, developers were often left on their own to figure out how to address compliance needs. Given the spirit of collaboration that DevOps and DevSecOps champion, however, developers should no longer feel like they have to go at it alone when it comes to interpreting and addressing compliance requirements. And indeed, they shouldn’t. If you are a coding expert, you’re probably not an expert in figuring out what complex compliance frameworks require.

The point here is that developers should not be afraid to ask for help—from legal experts, management or the IT team (which is more likely to have some experience with the compliance issues that arise once the software is in production) to make sure that the applications they design and write meet compliance requirements.

Conclusion

The developers’ main job is still writing code. But by having a greater awareness of the types of security risks that can arise within the code as it is pushed down the delivery chain, developers can do much to improve the security of the applications they write. They might even save themselves some time and headaches by reducing the number of complicated security issues they end up having to address by rewriting code.

This sponsored article was written on behalf of Symantec.

— Chris Tozzi

June 18, 2019
The DevOps Security Stack
The whole idea behind DevOps is automation. DevOps automates the development process by eliminating or minimizing human error. If an error occurs, the applications fail quickly so the errors can be resolved promptly on a smaller scale. DevOps and cloud-native applications complement each other perfectly.

Even though DevOps offers a more efficient and faster way to develop and deploy applications, security remains an issue. On paper, DevOps and cloud-native applications might be more secure than their traditional counterparts, but the reality is not that simple. With the newer, more complex, highly distributed infrastructures common to DevOps come new challenges that need to be identified and addressed.

This article walks through those challenges to highlight what it takes to secure a DevOps workflow. I won’t focus on specific tools because DevOps is not about specific tools; rather, I’ll focus on the components of DevOps workflows that present special security challenges and explain how to address them.

The Vulnerabilities You Just Can’t Ignore
1. Careless use of recycled code
One way DevOps improves developer productivity is by letting developers recycle code from previous projects or open source repositories such as GitHub. But without proper screening and sanitization, these pieces of code can pose threats to an application.
1. Multiple platforms make the attack surface larger
When deploying code in the cloud, you can’t use traditional security services. You need to rethink your security strategy. DevOps teams leverage various platforms, from serverless computing to microservices to multi-cloud in their applications. There’s no single solution to secure cloud-native applications. These applications are highly distributed and have various components, so organizations need a multifaceted approach to better secure these applications.
1. The dynamic nature of cloud-native applications doesn’t help
Cloud-native applications are continuously integrated and deployed, which makes it difficult for security teams to identify and mitigate risks. Traditional security tools can’t match the sheer velocity, scale and dynamics of cloud-native applications, leaving them useless.
1. Secrets need to be secured
When following the DevOps approach, security professionals need to create privileged accounts and login details and share them over business networks automatically. With serverless applications and the cloud, security teams don’t have a traditional location such as the operating system to execute security policies. A host of useful data, such as keys, storage account credentials, secrets, database passwords and embedded passwords, are stored in repositories. It’s crucial this data is kept extremely secure, as attackers can use this information to cause some serious damage.
1. Containers can leave your applications more vulnerable
Since the microservice approach involves a distributed infrastructure, it exposes your system to the network, which makes it easy for attackers to sneak into the system. Containers can be spread across different systems, which makes the threat landscape even larger. Containers are highly replicable, so if there is a vulnerability in one microservice, it can get replicated every time the source code is used.

Using open source software in containers can make way for an increase in vulnerabilities. DevOps teams should make sure unauthorized containers are not used in production. These containers can be used by attackers to launch an attack on the entire application.
1. Hosts aren’t automatically safe
Even if containers are properly secured, the hosts they run on are vulnerable to new threats and day-zero attacks. Container runtime should be up-to-date to avoid risks that can lead to container escape. This can help attackers to take control not only of a container but also the host operating system. So, it is important that hosts are given appropriate protection.
1. Kubernetes clusters need additional security
Kubernetes is a widely accepted container orchestration platform. However, it’s difficult for security to be enabled at multiple layers. Kubernetes uses APIs to manage containers, and recently, it was discovered that K8’s API server is quite susceptible to attacks—attackers can make use of the API server to perform malicious activities or install malware in the application.

Running multiple workloads on one cluster is not a good idea. Sensitive workloads should be run on a dedicated set of machines to avoid attacks through less secure neighboring applications. There’s also a need to secure sensitive metadata, which can be stolen and used to change privileges in a cluster, thereby paving the way for unauthorized changes in an application.

DevSecOps: The Future of DevOps Security

In traditional applications, security holds less priority, and security policies are always employed after development is completed. But with DevOps, security can’t be an afterthought. Companies depending on the DevOps approach need to make security their top priority. One of the ways to make sure security is in the foundation of a DevOps implementation is a DevOps security stack. To employ the DevOps security stack, IT teams no longer should be walled off from the DevOps team.

Security experts’ involvement can help them gain insights into what the application is and how it’s supposed to function so they can identify risks and take steps to mitigate them. This DevSecOps approach has become popular. DevSecOps is a collaboration between the development, security and operations teams who work together to ensure security is at the root of an application, not just on the surface.

Symantec Cloud Workload Protection: A Modern Solution for Modern Problems

Most organizations use hybrid cloud storage comprised of workloads distributed among public clouds, private clouds and on-premises, which can lead to an increased attack surface and vulnerabilities.

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 CWP.

— Twain Taylor
June 13, 2019
Shift Left Without Fear: The Role of Security in Enabling DevOps
It’s the age of DevOps, and we all want to shift left, which refers to the idea of performing processes earlier in the CI/CD cycle. That includes security checks and audits. By starting security operations earlier in the delivery pipeline, it becomes easier to find problems, and teams have more time to address them before pushing code into production.

The challenge, of course, is building a shift-left security operation that allows you to perform security operations early without slowing down delivery speed. Let’s take a look at how to square that circle.

Defining Shift-Left Security

A popular term in DevOps culture is “shift left.” But what does shift left mean? Shifting left refers to the effort by a DevOps team to implement measures to ensure application quality at an early point in the software development life cycle. In the case of application security, this means implementing measures to ensure security concerns are taken into consideration while the application is being developed, rather than at the end of the process.

The overall goal of shift-left security is to identify and resolve potential vulnerabilities earlier in the development life cycle, when these issues are less expensive to fix. Doing so will help to mitigate the risk potential security concerns pose to both the delivery schedule and your end -users.

DevSecOps: Integrating Security Into the Development Process

Let’s be honest: Faster and more frequent development cycles aren’t going away. Slowing delivery speed to analyze and bulletproof the application at the end of the development process is no longer a viable format for implementing security. DevOps and CI/CD need to be embraced and enabled by the security staff.

For security teams to enable the DevOps process, collaboration is key. Through this collaboration, the process of DevOps transforms into something known as DevSecOps. In DevSecOps, security personnel work closely with the rest of the DevOps organization to help those who create and deliver the application to gain a better understanding of what is needed to address security concerns as early in the development life cycle as possible.

The following tips serve as a jumping-off point for implementing this collaboration:
- Make security the responsibility of the entire DevOps team: Impress upon the development and operations staff that security is now the responsibility of the entire organization. Simply addressing potential vulnerabilities post-development will eat up too much time and increase the risk that something will be missed. Buying into this process is an essential part of implementing successful collaboration between the security team and the rest of the organization. An example of this would be impressing upon developers to code with security in mind.
- Facilitate regular discussions about application security throughout the development process: It is the responsibility of the security folks to keep security considerations at the forefront of a developer’s mind while they develop new features. Use the agile process to your advantage. Backlog meetings can involve security folks to ensure the creation of user stories includes consideration for security concerns. Your daily standup meetings are another place to include security personnel. This will provide security staff with an opportunity to speak up when the work described by the developer requires—or might require—considerations related to security that have yet to be addressed. Doing so will help to ensure the ball is not dropped, allowing for potential issues to be rectified before they even exist.
- Use test automation and continuous integration to your advantage: When it comes to addressing security concerns throughout the development process, continuous testing is your best friend. And, in cases where it makes sense, the DevOps team should integrate automated test scripts for the detection of security and into their continuous integration process. Such tests can include developer-written scripts to test for vulnerabilities in the code base and tools for static code analysis. Another part of your continuous testing strategy could involve the use of tools for infrastructure monitoring.
The data produced by these strategies can then be analyzed by security folks. And from this analysis, recommendations can be made to the DevOps team regarding the path forward to close potential gaps in security before they ever reach production and can be exploited.

Understanding the Role of Security Personnel in the Development Process

Security folks are often not coders, and development personnel are often not security experts. And while it may be frustrating at times, the solution to managing this disconnect is in the collaboration described above. Situations will arise where developers need to develop with various technologies to build a quality product. It’s possible that these technologies will lend themselves to security concerns that require security expertise. The job of security personnel shouldn’t always be to fight back against the use of these technologies. The security team should act as facilitators—take what development and operations staff intend to do and foresee the potential impacts that innovation will have on security—then take these potential impacts and provide insight into what needs to be done to reduce the risks.

Conclusion

In the past, security often was considered as an afterthought in the development of an application and its infrastructure. The movement toward faster development cycles and more frequent application releases has forced development organizations to think about security differently. Nowadays, so much can change in an application in a short time. This has forced DevOps organizations to integrate security into the development pipeline to make security a continuous consideration in the development life cycle. With this integration, the responsibilities of security personnel have shifted. Security teams now need to be enablers of the DevOps culture, empowering DevOps processes with security in mind.

To see how Symantec CWA can help you shift left without fear, sign up for a free trial to see how it can help secure your cloud.

— Scott Fitzpatrick
June 11, 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