devopsy.kinsta.cloud

Category: Sponsored Content

  • Why Workload Security Is Not Just for IT Anymore

    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

  • What is Cloud-Native Workload Protection?

    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