devopsy.kinsta.cloud

Tag: security

  • Why Secrets Management is Critical to DevOps Pipeline Security

    Why Secrets Management is Critical to DevOps Pipeline Security

    While valuable, secrets management also can be difficult for DevOps teams to employ. Here’s what you need to know

    Business is all about speed. Companies want to innovate and deliver functionality faster to remain competitive. This explains the increasing popularity of DevOps as a go-to model for rapid application delivery. A recent Gartner report indicated that DevOps adoption is a growing alternative to traditional waterfall and agile development methodologies, but also pointed to key challenges with security and compliance.

    For example, the report noted that DevOps practices encourage automation to achieve scale, but that security is traditionally manual, gate-driven and heavy on processes. In addition, the majority of developers have zero knowledge of secure coding, even many who are well-versed in agile and DevOps.

    But there is another critical component of data security for DevOps teams: secrets management. In DevOps, “secrets” are typically authentication credentials used in applications and services. This may include usernames and passwords, either system-to-system or database; API tokens; SSH keys; encryption keys; and so on. Secrets are the keys to your data and, when handled casually, can open the doors to a serious data breach or intellectual property theft.

    Secrets Management Presents Challenges

    Developers often inadvertently leave behind sensitive pieces of code embedded in applications, files and code repositories. One real-world example is the way in which some developers use GitHub, a hugely popular source-code management system and the largest source-code repository in the world. Most developers seem to use GitHub casually, leading to increased risk of insider threats and hacking incidents. In one such incident in 2016, hackers penetrated Uber’s source code repository via GitHub, accessing intellectual property, AWS credentials and the personal data of more than 7 million Uber drivers and 50 million customers.

    There are three main reasons why secrets management is challenging for DevOps teams:

    1. Secret sprawl. Increased adoption of the cloud-native development model and the emergence of multi-cloud infrastructures has led to a proliferation and decentralization of secrets. If left to their own devices, these secrets can sprawl over time, leading to data breaches and privacy concerns.

    2. A disparate set of tools. Many DevOps teams use different sets of tools for different phases of the development process and often struggle to have a centralized system that can integrate with all these tools and systems. Cloud-native secrets management tools are limited to the specific cloud provider and may not be effective in a multi-cloud scenario. An effective secrets management strategy should be able to integrate and work with every tool in the DevOps workflow and across cloud providers.

    3. DevOps blind spots. Most enterprises are unaware of where their secrets are located, who has access to them or whether the secrets have been changed. This lack of understanding of the functioning of the DevOps pipeline often increases the risk of an internal data breach.

    Today, most enterprises use containers to package and deploy applications. Gartner estimates that by 2022 nearly 75% of organizations will be running containerized applications in production. Oftentimes, in a container-driven environment, the groups responsible for developing applications are distinct from the groups in charge of deploying applications. Furthermore, database administrators by and large have (or should have) access to the keys, tokens and secrets.

    In this setting, a major challenge is how to enable application development and deployment in the presence of this segregation without compromising secrets. If a developer has a piece of code inside a container that requires access to a secret key, then this secret value can be hard-coded into the code itself or included as part of the container image. But both of these options have detrimental security implications because they expose secret values to all those who can view the source code or deployment parameters, thereby violating the principle of least privilege.

    Instead, secrets can be securely passed to the containerized code during actual runtime. Using a utility based on a container-orchestration system such as Kubernetes allows the secure transmission of secrets at runtime, meaning the secrets don’t need to be exposed while building or deploying the application. Rather, the utility can monitor the environment in real-time and inject secrets at runtime only when they are required.

    3 Things to Look for

    Regardless of the tools used in a development pipeline, protecting credentials and API keys from compromise is critical. Simply put, secrets must exist outside of the source code. When considering a secrets management solution, there are three things to look for:

    • A flexible deployment model, whether on-premises, natively in the cloud or any hybrid/multi-cloud combination.
    • A solution secured in a way that goes beyond a simple key-value store.
    • The ability to connect to other applications and services through open standards such as OAuth, OpenID (SAML), LDAP, Trustworthy JWT and PKI.

    A secrets management strategy that takes these factors into account maximizes an organization’s opportunities for success. And with the DevOps model as prevalent as it now is, it’s absolutely vital for teams to do so to significantly reduce the likelihood of breaches and ultimately improve business agility.

  • Securely Streamline Code Signing for DevOps and DevSecOps

    Securely Streamline Code Signing for DevOps and DevSecOps

    Introducing code-signing provides security within the application, but teams should take care to understand and implement the process effectively

    Digital certificate management, with hundreds or thousands of certificates required to support IT infrastructure, can easily lead to degradation of application integrity and unnecessary risk to the business. The cumbersome nature of siloed teams manually managing digital certificates often results in the bypassing of PKI standards mandated by their organization.

    Based on the complexity of their pipeline, DevOps and DevSecOps teams may issue certificates signed by an untrusted source and stored insecurely to speed up the build and deployment stages of CI/CD workflows to avoid a lengthy certificate request process, which could take weeks or even months. Using this manual, insecure cryptographic practice to sign and deploy code exposes organizations to a high level of avoidable risk.

    Code signing, and the certificates used in that process, should be centralized and automated using cryptographic hardware. Here we will walk through the process of hardened code signing and how to streamline its management in DevOps and DevSecOps pipelines.

    Hardened Code Signing in 4 Steps

    1. Unsigned code ready for distribution. Time to generate public-private key pair

    We start with an unsigned executable that is ready for distribution. To securely sign the code, the code publisher needs to generate a public-private key pair. This is required by most runtime architectures, including Windows, Java and others. The most secure way to generate code-signing keys is by using a FIPS 140-2 Level 3 validated hardware security module (HSM).

    1. Submit public key and Certificate Signing Request (CSR) to an issuing certificate authority (CA)

    With the key pair generated in step No. 1, the CSR is generated and submitted to an issuing CA. The CSR contains information that identifies the publisher and signature algorithm, as well as the digital signature. This information is used by the issuing CA to issue the code signing certificate.

    In some situations, such as with internet of things (IoT) device manufacturing, the organization may decide to act as its own Issuing CA.

    1. Identification of publisher and authentication of CSR

    The Issuing CA verifies the code publisher’s identity then authenticates the CSR, ensuring the publisher has digitally signed it. If both identification and authentication are successful, the Issuing CA packages the publisher’s identity with the public key then signs the package, creating the code-signing certificate.

    1. Ready to sign. Determine the level of security

    Now that the code-signing certificate is ready for use, any executable can be signed and deployed unless further code testing or QA needs to occur. Enterprises, particularly fast-moving ones, often find themselves storing their code-signing keys on the code publisher’s local machine or server, an insecure method that can result in significant problems. Storing the keys on a local machine or server presents major security risks. The local machine could become compromised/stolen along with the code-signing keys, or a disgruntled employee could maliciously sign and deploy unauthorized code, which could go unnoticed for a while.

    It is best to import and store the code-signing certificate in a key management server (KMS), which stores the certificate behind a FIPS 140-2 Level tamper-resistant physical boundary. In addition to hardened storage, a KMS with proper cryptographic features and functionality can be utilized to help automate the entire code-signing and certificate management life cycle. A KMS allows DevOps and DevSecOps teams to seamlessly meet best practices while removing the manual workflow bottlenecks and natively integrating with CI/CD systems. Less time generating and managing digital certificates results in faster code deployments and an increase in team output.

    Streamline Continuous Integration

    There is tremendous value in using an HSM for secure key generation and certificate storage. Additionally, DevOps and DevSecOps teams can drastically reduce the manual labor required with continuous integration code builds. For builds requiring a defined and trackable workflow for signing, code signing with CI/CD integration can offer significant benefits.

    This workflow typically consists of a CI/CD system that is managing the build and signing request process, a centralized and secure key management server to manage all code-signing keys and perform the signing process, and an approval entity to govern the process by which code is signed in an authorized manner.

    When deploying a system like this, backed by a FIPS 140-2 Level 3-validated HSM, organizations can also introduce automation into the process. This means that instead of code signing being a manually driven step that introduces room for human error, it is natively incorporated in the code development and release workflow.

    Integration With Code-Signing Technologies

    KMS and HSM cryptographic devices that provide hardened key storage commonly integrate with popular code-signing technologies that conduct various tasks such as validating publisher identity and ensuring code integrity. For instance, organizations using SignTool.exe with Microsoft Authenticode can directly integrate with a KMS with full certificate management functionality. Other integrations and use cases include Java Jar Signer, RPM (Red Hat), Docker, and various IoT implementations. Beyond that, innovative organizations are looking at systems that can deploy more advanced code-signing workflows outside of the standard OS and runtime SDKs, to integrate more tightly with CI/CD systems.

    Integrating HSMs into DevOps and DevSecOps pipelines simultaneously improves workflow efficiency and supports other cryptographic operations across the organization.

  • KubeCon Coverage: Incentivizing the DevSecOps Culture

    KubeCon Coverage: Incentivizing the DevSecOps Culture

    Just as DevOps set to de-silo development and operations teams, the DevSecOps movement is bringing security to the same table. A shift-left security mindset is permeating much discussion of late.

    Cyberattacks are on the rise in the era of COVID-19 and cybersecurity has become paramount to arm business-critical applications. Furthermore, new regulations have emerged to protect personally identifiable information (PII). A new cybersecurity awareness feels quite apparent throughout the tech spectrum. As a result, security policies are poised to integrate more directly within the process of engineering and deploying applications.

    Nonetheless, while DevSecOps feels necessary to implement at this critical hour, it does present challenges. Primarily of which is a significant cultural shift. Uniting security and development isn’t as easy as it sounds, especially when faced with rigid enterprise bureaucracy. Plus, how can an organization incentivize DevSecOps if developers fear security tools will slow down their workflows?

    The DevSecOps panel at the recent KubeCon + CloudNativeCon North America 2020 brought together leaders in the DevSecOps arena to advise introducing a security-first mindset to DevOps. Dan Papandrea, field chief technologist at Sysdig, led this super-informative panel. It featured:

    • Emily Fox, DevOps Security Lead, NSA
    • Peter Bosch, Cisco
    • Sunil James, HPE
    • Christian Weichel, Gitpod
    • Nicolas Chaillan, U.S. Air Force

    Below, I’ll cover some of the key insights garnered from the event. To summarize, the panel identified how policy-first tools and open source initiatives are placing security controls within IDEs and CI/CD pipelines. And what will it take to get everyone onboard? It appears that transparent tooling automation, making security adherence natural and a new wave of security-aware employees will be critical components in the future era of DevSecOps.

    What is DevSecOps?

    First off, to get a better picture, what exactly is DevSecOps? And why has it come about?

    In a previous article, we defined DevSecOps with six traits: security automation, security culture, de-siloing IT, shifting security left and security as an enabler (not a stalling force).

    The KubeCon panelists seemed to echo all of these points. Fox described DevSecOps as “a term used by organizations to ensure their DevOps approaches have a security-first mentality.” To her, this means placing security automation within workload environments.

    DevSecOps is something new. For most organizations, security isn’t baked into the standard development processes—it historically hasn’t been the first priority, Chaillan said. DevSecOps is changing that, adding continuous monitoring, zero trust enforcement and reducing the overall attack surface.

    The move toward continuous release is also an impetus for DevSecOps. “Our cadence of delivery has been quickened,” said James. All organizations now feel pressure to deliver value to customers rapidly. An interesting byproduct of building security-first, he said, is “the ability to create the consistency and speed with which you can actually offer these capabilities.”

    Another cause for DevSecOps is the sheer imbalance in the workforce. On average, the number of developers far outweigh the number of security folks, noted Bosch. So, DevSecOps could scale security across an organization more effectively than human power could.

    Bosch also is hopeful DevSecOps could put an end to time-consuming bureaucracies stalling an agile security process. “Developers used to write code and wait for free months to open a firewall.” This may have been standard operating procedure decades ago, but in the age of continuous everything, enterprises must evolve how they handle IT security policies. “By uniting security with developers, we bring speed, robustness, avoid OWASP issues, and build applications that better contribute to the bottom line,” he said.

    Finally, embracing DevSecOps is a significant commitment. The combination of culture and technology is essential, noted Weichel. As we infuse security testing into CI/CD pipelines and make everything security-first, he said, we indeed undergo a cultural shift—it’s something that permeates everything.

    Challenges in Implementation

    Companies attempting to introduce DevSecOps may run into a few challenges, including instilling the culture, implementing regulatory compliance and finding the right blend of open source and propriety tools to get the job done.

    Bosh is no stranger to sluggish enterprises and the systemic change required to introduce DevSecOps. In these environments, changing companywide antiquated processes may require executive sponsorship. “By and large, it’s mostly culture,” he said, yet acknowledged a vast divide between the two groups: “How do you convince security do get out of their comfort zone? And how do you convince developers to get out of theirs?”

    There is also developer experience to consider: Developers often view security tools as limiting their ability to deliver code quickly. Perhaps the biggest challenge to overcome is improving the experience of working alongside new security policies. If new practices are causing more pain, instead of automating pain points away, DevSecOps could suffer.

    Outside of team dynamics, there are also technical hurdles involved when introducing and enforcing legal regulatory requirements. “Getting any sort of compliance baked into CI/CD pipelines is a challenge,” said Fox. Part of the problem is that the tooling to enforce such requirements isn’t there yet. “Cloud-native is continually evolving and security is constantly playing catch up,” she noted. “It’s an ongoing challenge.”

    Incentivizing the DevSecOps Culture

    Employees need incentives to change established habits. With the above challenges in mind, how can organizations create incentives to adopt DevSecOps? Well, outside of monetary incentives or straight up demanding it, incentivizing that security culture could happen in a few different ways, the panelists noted.

    To Fox, it’s about “making security transparent to the developers.” You want developers to quickly build and deploy secure applications without the need for intensive cybersecurity training. Thus, the tools and processes must be as transparent and usable as possible. DevSecOps is possible “if you make it second nature,” she said.

    Another way to consider DevSecOps culture is the end performance. If customers are happy, this is a positive gauge. James said he has witnessed CIOs at a few organizations using customer satisfaction scores as a guiding light for not only the business but for security effectiveness well.

    Bosch similarly stressed an indirect incentive about overall company performance. “Companies that really embrace DevSecOps leads to better code,” said Bosch. This leads to more robustness, higher speed, and better-operating enterprises. Co-building a thriving success could be ample incentive alone for those who have the whole team in mind.

  • Gravitational Becomes Teleport to Streamline Access Management

    Gravitational Becomes Teleport to Streamline Access Management

    Gravitational today announced it has changed its name to Teleport and launched the Teleport Unified Access Plane, an open source security gateway that comes in the form of a single binary that acts as a proxy for remotely accessing Linux servers and Kubernetes clusters.

    Teleport Unified Access Plane (UAP) for managing those gateways can be either deployed by an IT team or accessed via a cloud service managed by Teleport.

    Offerings included in Teleport UAP are Teleport Server Access, Teleport Kubernetes Access and Teleport Application Access, which combined enable IT organizations to lock down access to an IT environment.

    Company CEO Ev Kontsevoy said Teleport UAP gives engineers via a single login access to just the IT resources they have permission to access. That approach reduces the myriad credentials that IT organizations currently need to manage across multiple networks.

    Teleport automatically discovers all the resources in an IT environment along with the protocols needed to access them. It provides a unified audit log in a JSON format that enables IT teams to track what resources are being accessed when and by whom.

    Access control is becoming a bigger issue because the overall IT environment is becoming more complex as the infrastructure stack required to run applications grows. Teleport provides a way to streamline access management across servers, clusters and databases.

    That issue is also becoming a bigger challenge with IT personnel now working from home to help combat the spread of the COVID-19 pandemic, added Kontsevoy.

    That fine-grained approach to access will ultimately eliminate the need to rely on virtual private networks (VPNs) at a time when the network perimeter continues to dissolve. In effect, Teleport enables IT teams to move toward a more identity-centric approach to unifying the management of access, he said.

    In general, he noted, Teleport enables organizations to manage security as code rather than having to rely on separate overlays. As such, they can shift responsibility further left toward DevOps teams.

    It may take some time for IT teams to aggregate all the access control protocols they currently employ under a single proxy. However, Kontevoy said, the massive amount of time and effort spent managing access control today will drive organizations that have embraced best DevOps practices to look for ways to automate what today is a very manual process.

    The challenge, of course, is finding the time to achieve that goal. Teleport is betting a single binary in combination with a control plane accessed primarily as a managed service will make it too simple for DevOps teams to ignore. Regardless of approach, however, it’s clear there needs to be a better way to manage access within the sea of servers, databases and applications that now make up the typical IT environment.

  • Two-Part Training Required for Developers to Slay the Security Beast

    Two-Part Training Required for Developers to Slay the Security Beast

    Developers’ defensive qualities are only as good as the training they receive

    The playing field between the heroes and villains in cybersecurity is notoriously unfair. Sensitive data is the new gold, and attackers adapt quickly to circumvent defenses, exploiting security bugs large and small for potential paydirt.

    The volume of code being produced is too great for security experts—who are becoming increasingly scarce—to contend with, and the rising cost of data breaches is proof that something has got to give. Fortunately, for the sake of our digital safety and the sanity of CISOs everywhere, the DevSecOps movement is helping to bring developers on the security journey from the beginning of the software development process. They are being recognized as the first line of defense against cyberattackers, with the power to eliminate common vulnerabilities at their fingertips.

    However, their defensive capabilities are only as good as the training they receive, and that is yet another gauntlet for security teams to run. For many developers receiving on-the-job training in secure coding, their key challenge is staying awake during mind-numbing, hands-off activities that are neither effective nor inspiring them to keep security front of mind. Soulless video courses aren’t getting us there, token annual ‘tick-the-box’ events are a waste of time, and nobody is winning against the potential malicious threat actor waiting to jump on a small window of opportunity.

    At this stage in our industry, we have worked out that contextual, hands-on education that is delivered in relevant programming languages and frameworks, with challenges that mimic those a developer might come across in the real world, is a far more engaging approach.

    This is phase one of a developer’s quest to help AppSec gurus slay common vulnerabilities, but phase two is where scenarios must get real for a supercharged, security-aware defensive force.

    Scaffolded Learning Is Critical in Adult Education

    When it comes to extracurricular courses or on-the-job training, it is often overlooked that adults bring with them a certain level of experience and existing knowledge. Good training adds to this foundation and is structured in a way that allows for deeper understanding and faster autonomy in the learning process.

    Scaffolded education is a potent, positive method of learning that seeks to activate and enhance prior experience while continuing to build new skills—in manageable chunks—that allow the learner to tackle increasingly difficult tasks with more confidence. Typically, it is a methodology best served with healthy portions of demonstration, visual aids and student-led exploration.

    If we tie this approach back to developer security training, it comes as no surprise that the dynamic, learn-by-doing method has long been preferred over the drudgery that is theory-based static learning. They are free to be the masters of their domain and should see that their time is being well-spent.

    In that sense, learning to code securely in a hyper-relevant, contextual environment is key, but the ‘level up’ from this step is to see an exploit of vulnerable code in action. With the context of front-end and back-end views side-by-side, there is a tangible link between actions taken during the coding process and what an attacker can potentially do with cut corners, misconfigurations or accidents that are not caught and remedied.

    Move From Recall to Application for a Truly Preventative Security Approach

    Experiencing the impact of security vulnerabilities firsthand is a vital piece of the education puzzle, and it’s a fairly rare beast, even with the most modern security training options for developers. The foundational work spent on honing skills in spotting and remediating vulnerabilities and recalling that experience to eliminate the same bugs in code as it is being written is extremely important, but it’s not the whole picture. Seeing how vulnerable code is exploited by a malicious actor adds a powerful layer of context, one that really drives home the importance of securing code and applying hard-earned security knowledge to close every window of opportunity.

    It is generally accepted that developers don’t love security, and they have even less affection for security training. Their experiences with AppSec specialists can be very frosty, and the rework caused by the security team bouncing vulnerable code back to developers for remediation is the bane of their existence. To an engineering team that is already spread thin, security is someone else’s problem, not their priority, and a hindrance to their natural creativity and primary objective of building features. However, there is simply too much code, too many breaches and too much risk to the world’s data for this mindset to continue.

    A functional DevSecOps process has developers working in harmony with security teams right at the beginning of the software delivery life cycle (SDLC). Likewise, the opportunity for applied learning, where they can interact with a simulated exploit and see the impact of poorly secured code, goes a long way in getting developers on the same page as those pesky AppSec people (who aren’t so bad after all).

    Interactive Learning Prepares Developers for the Boss Fight

    At the time of writing, there were two major breaches reported in a seven-day period: Razer announced that more than 100,000 sensitive data records had been exposed, while office supplies retailer Staples also reported a similar data leak. More than a billion sensitive records have been exposed so far in 2020, and this worrying trend shows no signs of slowing down. Simply put, malicious actors have the upper hand and security-aware developers are sorely needed to serve as the front line of defense.

    Interactive challenges that focus on simulating such breaches move developers from passive recall, to applying skills that have an impact on the real boss fight: stopping attackers in their tracks.

  • 20/20 Network Visibility: Making Cloud Migration a Success

    20/20 Network Visibility: Making Cloud Migration a Success

    Organizations need to take a considered and gradual approach to cloud migration to ensure security and compliance

    For businesses to succeed in 2021 and beyond, agility and responsiveness are critical. Data is the new currency, and businesses need to be able to access theirs instantly and securely to make the rapid-fire business decisions that will make or break their long-term strategies. One way IT can improve responsiveness and business agility is by moving business applications to the cloud.

    When migrating applications to the cloud, the need for network security is often overlooked. When this happens, applications are deployed in the cloud without adequate security and compliance measures in place—or, conversely, the security team steps in and halts the migration process.

    This puts the company at risk: Inadequate security makes it easier for hackers to access the network and mount an attack against the company, exposing the company to financial losses and legal repercussions. Moreover, if the business is unable to respond to market demands in a timely fashion, there are clear financial implications.

    The Challenge of Security

    Cloud migration comes with several benefits, but it also exposes a number of security risks. With every advantage comes a cost, and it is up to businesses to do whatever they can to mitigate that risk to leverage the cloud to its fullest potential.

    An AlgoSec survey found that organizations reported a range of problems when migrating to public clouds, with 44% having difficulty managing security policies post-migration and nearly a third struggling to map application traffic flows at the start. Respondents also had concerns about applications in the cloud, with the greatest worry being cyberattacks (58%) and unauthorized access (53%) followed by application outages and misconfigured cloud security controls.

    But this shouldn’t stop progress from happening. To demonstrate this, let’s take four of the biggest advantages of cloud migration and outline the security challenges that come with them.

    1. Security and Data Protection

    When adopting the public cloud, data itself is much more accessible no matter where it is located, but this does not come without a cost. Data in the cloud is highly regulated and therefore subject to greater regulatory compliance—for example, under GDPR in the EU. Once the data is no longer kept on-premises, security must be tightened and additional security controls must be employed to demonstrate greater control over data storage and usage, in accordance with set guidelines. There are best practices to uphold, as well as financial penalties if organizations do not comply with them.

    1. Agility

    Spinning up a server in the cloud takes mere minutes. Cloud computing requires no hardware and no locally installed software; all you need is a credit card and you can be up and running with your very own cloud-based infrastructure almost instantly. Some businesses are powered purely through SaaS and IaaS services, and it makes them incredibly nimble in rapidly changing times. But this agility also comes with risks. For security to be tight, businesses need complete visibility, and that is not always possible when working exclusively in the cloud. Therefore, stronger pre-fail measures and cloud firewalls are needed, as well as established baselines for allowed connectivity for each cloud server used.

    1. Cost-saving

    The cloud offers zero maintenance and capital cost along with reduced IT support costs. You also have the added benefit of only paying for what you use, which means you don’t have to purchase expensive hardware that you would only need during peak times. However, there may be hidden costs depending on which provider you use, so you will want to monitor usage and cloud assets more generally, ensuring they’re optimized and working as efficiently as possible.

    1. Time to market

    When the cloud is coupled with DevOps practices and tools, organizations can gain a flexible framework in which to build with zero capital investment. PaaS has revolutionized time-to-market for these organizations, but this too comes with risk. With so many teams collaborating on development and so many moving parts in the process, security is often sidelined and even forgotten, meaning it gets tacked on at the end of the process, leaving gaps that can be exploited.

    What these organizations need is a security policy automation that supports the DevOps methodology, and more importantly the DevSecOps approach to building a security foundation. This solution needs to be able to automatically copy the firewall rules—and then make the necessary modifications to map rules to the new objects when the rules are applied to each new environment in the DevOps life cycle. With the right automation solution, security can be baked into the entire process.

    Cloud migration is absolutely essential for businesses that want to stay market-fit and competitive. But too often security seems to fall down the list of priorities, causing damaging problems in the long run. So how should organizations approach their cloud migration projects to ensure that security and compliance are not compromised during or after the migration?

    Visibility Is Key in Cloud Migration

    Obtaining an inventory of applications is a key requirement when migrating to the cloud. Most businesses have two types of applications—enterprise and departmental—and it should be relatively easy to obtain the necessary connectivity information needed to migrate them to the cloud. The key here is to know that these applications exist.

    Once the list of applications is in place, you can move onto the next stage in the process of closing the security gap as you migrate to the cloud: identifying and sealing any vulnerabilities in the server that could be exploited by a hacker and understanding network connectivity requirements and application attributes such as the number of servers and associated business processes. These elements help determine the complexity involved in migrating applications.

    Several attributes can affect the complexity of migrating an application to the cloud, including its specific connectivity requirements and the firewall rules that allow/deny that connectivity. Mapping this connectivity provides a deeper understanding of network traffic, which then provides insight into the flows you will need to migrate and maintain with the application in the cloud. The more applications that utilize a server, the more difficult it is to migrate an application that depends on that server. It may be necessary to migrate the server itself or migrate multiple applications at the same time.

    Mapping the firewall rules provides insight into the security measures you will need to put in place once the application has been migrated to the cloud. As a rule of thumb, the more firewall rules are required, the greater the complexity. This mapping allows you to identify and decommission firewall rules that are no longer necessary post-migration.

    So how do you generate documentation of application connectivity? The obvious choice is to employ a solution that automatically maps the various network traffic flows, servers and firewall rules for each application. If you do not have access to such an automation solution, manually documenting—however tedious—will provide the necessary information.

    Adopting a Migration Strategy

    For most businesses, digital transformation is a gradual evolution that requires forethought and strategy to get it right. An organization might choose to only move a few of its applications onto the cloud to begin with and may even choose to use one or more cloud vendors for their needs. Either way, organizations still have a responsibility to manage and maintain security and compliance in the cloud, just as they did on-premises. This will need a deeper understanding of cloud security controls and how they connect to on-premises security devices, made possible by enhanced visibility and automated network management.

    No matter which approach they take to cloud migration, organizations need to take a considered and gradual approach, understanding that the responsibility to manage the security and compliance of their services still lies firmly at their door.

  • OpenSSF Makes Free Security Training Available

    OpenSSF Makes Free Security Training Available

    The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is providing free security training for developers building and employing open source software starting later this week as part of an overall effort to advance best DevSecOps practices.

    Linux Foundation CTO Chris Aniszczyk said the Secure Software Development Fundamentals professional certificate program along with additional programs and technical initiatives soon will be required for every maintainer working on open source projects overseen by the Linux Foundation. As the number of applications that incorporate open source software has increased, the potential harm that can be inflicted by vulnerabilities introduced via code continues to increase, he noted.

    A larger percentage of those common vulnerabilities could be eliminated simply by providing developers with free access to training, Aniszczyk noted. Far too many developers and software engineers have not had access to security training beyond a few rudimentary courses in college, while many other developers are self-taught, he said.

    Accessed online via the edX learning platform, the courses are designed to teach developers and software engineers how to develop secure software while reducing the potential for damage and increasing the speed of the response when a vulnerability is found.

    The OpenSSF has also revealed existing projects from the Core Infrastructure Initiative (CII). The CII Census, quantitative analysis to identify critical open source projects, and CII FOSS Contributor Survey, a quantitative survey of developers, have become part of the OpenSSF Securing Critical Projects working group. These two efforts will continue to be implemented by the Laboratory for Innovation Science at Harvard (LISH). The CII Best Practices badge project is being transitioned into the OpenSSF.

    OpenSSF also announced new contributors, including Arduino, AuriStor, Canonical, Debricked, Facebook, Huawei Technologies, iExec Blockchain Tech, Laboratory for Innovation Science at Harvard (LISH), Open Source Technology Improvement Fund, Polyverse Corp., Renesas, Samsung, Spectral, SUSE, Tencent, Uber and WhiteSource.

    It has also elected an advisory council and governing board members with Kay Williams from Microsoft becoming Governing Board Chair. Other newly elected board members include Jeffrey Eric Altman from AuriStor Inc., Lech Sandecki from Canonical, Anand Pashupathy from Intel and Dan Lorenc from Google as the Technical Advisory Committee (TAC) representative.

    Ryan Haning from Microsoft has been elected Chair of the Technical Advisory Council (TAC) and an election for a Security Community Individual Representative to the Governing Board is currently underway. An OpenSSF Town Hall will be held online Nov. 9.

    Open source software obviously plays a critical role in boosting productivity because it means developers don’t have to constantly duplicate the same functions across multiple projects. However, if a vulnerability is discovered in one open source library the implications across multiple projects that have reused that same library can be profound. As part of an effort to ensure continued reliance on open source code, it’s incumbent on the open source community to make sure that code being shared is secure. In effect, responsibility for open source security needs to shift left at a massive level of scale. The challenge now is making sure that now open source developers have access to training the best DevSecOps practices that training enables are actually implemented.

  • How Service Mesh Enables a Zero-Trust Network

    How Service Mesh Enables a Zero-Trust Network

    How can we achieve high-grade security within a microservices ecosystem? Service mesh may be the answer

    Enterprise applications often assign an identity to humans to determine security clearances. Using standards such as OpenID Connect and SAML, we can delegate authorization scopes across a suite of applications to determine precisely what a user is permitted to do. But what about the applications themselves? Some believe that microservices should follow this identity-first approach, too.

    For large-scale application ecosystems, microservices is arguably more secure than a monolith. As Marco Palladino, CTO of Kong, described, “A monolithic application is a security incident waiting to happen.” Yet, microservices shouldn’t necessarily trust one another. So, how can we achieve high-grade security within a microservices ecosystem?

    The answer may lie in service mesh. I recently met with Palladino to discover how a service mesh can achieve bank-grade security for established and emerging microservices patterns. Similar to how enterprises assign an identity to end users, a zero-trust security network gives an identity to microservices themselves.

    A Zero Trust Network Trusts Nothing

    With more personal data used in cloud operations, more and more personally identifiable information (PII) is vulnerable to attack, and the costs are high. In Q1 2019, the cost of breaches in the financial sector was $6.2 billion. In 2018, 97% of breaches exposed PII, a top target for cybercriminals.

    Organizations are thus feeling pressure to secure their assets. The most precious data is held within financial services and health care, where GDPR and HIPPA enforce strict accordance with data privacy. This pressure is leading U.S. banks to clamp down third-party application access. Simultaneously, European banks face similar security dilemmas while appeasing PSD2 regulation for open banking.

    To safeguard user data, organizations are adopting a zero-trust security model. “Zero trust security means that we’re not trusting anybody,” said Palladino. “We don’t trust our own services. We don’t trust our own team members.”

    Placing too much trust in users, services and teams could cause a catastrophic failure. And, “there is no bigger risk than thinking you are secure, while in reality, you are not,” he said.

    Monolith ⮕ Microservices

    In practice, architecting a zero-trust application network runs parallel with the trend toward microservices designs. Though it may seem counterintuitive, a microservices system is arguably more secure than a monolithic architecture.

    In a monolithic application, every resource—whether invoices, billing orders or transaction history—is always just one line of code away. Since everything is connected, you could expose a resource with a single access.

    A microservices architecture decouples applications into separate services, each responsible for specific resources that make up the smaller applications, which can be secured and provisioned over a network.

    Segmenting the service landscape avoids one cascading defect affecting all applications. It also enables more control. “By decoupling from monolith to microservices, we can apply fine-grained security permissions and rules to determine what’s possible in the context of the application,” Palladino said.

    Microservices ⮕ Service Mesh

    Implementing these permissions is where a service mesh comes in. The application teams often build security, yet it’s generally bad practice to build your own cybersecurity. Security for microservices requires high expertise, and standardizing connectivity between various microservices can easily result in fragmented security implementations.

    Instead of building your own security infrastructure, Palladino recommended utilizing service mesh. By using service mesh as a control plane for microservices, platform architects can specify specific rules and attributes to generate an identity on a per-service basis.

    Service mesh also removes the burden of networking from developers, enabling them to focus more on their core logic. “Application teams become consumers of connectivity, as opposed to the makers to this connectivity,” Palladino noted.

    Identity for Services

    In the same way enterprises create identity profiles for humans, Palladino said we must extend the same model to services, pairing each service with authorization scopes. “Services must provide their own identity,” he noted. “Based on that, they can do certain operations in their infrastructure.”

    When we think of identity for services, attributes such as geographic location and certificates come to mind. These and other traits could make up a microservice’s authorization scopes. Utilizing a service mesh, architects could assign such attributes to each workload and service to determine what operations are allowed or what requests can be made to what other services.

    For example, services from one region could be designed not to consume services from another region. Such attribute-based control for microservices is a novel, well-needed strategy, Palladino said. “It was crazy this was not in place before; not having zero trust is like having all your money in an open vault.”

    Best Practices for Service Identity

    Knowing that we want to implement identity-based security for microservices, where are some best practices? Palladino recommended:

    • Automate some attributes: A service mesh could automatically assign identity attributes upon creation, such as cloud zone or geographic boundaries.
    • Provide a way to manage attributes: A dashboard would be necessary for DevOps engineers to create, edit or delete service-level attributes.
    • Governance: Architects must manage the control plane and create identities for the right parties to access this capability.
    • Secure encryption and Mutual TLS: Teams will require a system for rotating and expiring certificates for hundreds of thousands of workloads running across an organization, noted Palladino.
    • Standardize: Secure Production Identity Framework For Everyone (SPIFFE), a CNCF incubating project, is a good framework for service identity, making it operable with other cloud-native projects.
    • Play nice with CI/CD: Attribute creation could be hooked into an underlying CI/CD process to occur when deploying products automatically.

    Once microservices have identities, the services they interact with can determine what actions they are authorized to perform. This limits machine-to-machine communication to allowed operations.

    Zero-Trust Security With One Click

    Many teams have transitioned to a microservices architecture to deploy more often, be more distributed, decoupled or improve overall reliability. While these innovations are largely positive, Palladino cautioned against innovation without the proper security forethought: “It’s silly to transition to a microservices strategy without thinking about how these services are secured,” he said.

    Teams will also be running microservices on various environments—VMs, cloud or physical data centers. Thus, considering microservice-to-microservice communication, how do we route traffic between such environments? How do we observe metrics and logs? Palladino believes an agnostic service mesh that supports multi-region, multi-zone, multi-cloud and hybrid modes is the answer to these dilemmas.

    If used correctly, service mesh can plug security gaps for internal service-to-service communication, thus obfuscating high-value resources, such as financial services data, from nefarious players. The key to solving the service identity challenge is a usable dashboard. As Palladino described, “Zero trust security with one click.”

  • Using PAM to Support the ‘Sec’ in DevSecOps

    Using PAM to Support the ‘Sec’ in DevSecOps

    Despite its reputation as slow and complex, PAM can be included in the DevOps pipeline effectively

    The introduction of DevOps practices has led to a revolution in software development. However, as companies adopt these new technologies, tools and methodologies, incorporating privileged access management (PAM) becomes increasingly complex. Nonetheless, corporate policies, industry standards and government regulations mandate that security and operations teams must manage and audit permissions and credentials for a growing number of user and service accounts. As a best practice, a least privilege access control model is a must.

    Compounding the issue is that traditional methods of securing developer environments involve manual interventions and restrictive controls that significantly hamper the agility of development and operations teams. Because of that, DevOps has eschewed PAM as too slow and complex to deploy and manage.

    Adding to the complexity, applications, virtual machines, services and workloads running in the cloud all have identities. In fact, non-human identities nowadays represent most “users” in many organizations. This proliferation of non-human identities exacerbates the difficulty of achieving least privilege.

    Like human identities, access for these identities must be strictly monitored and controlled so that unauthorized, unverified access is automatically denied. PAM solutions that support modern application-to-application password management (AAPM) approaches can achieve this. DevOps owners can take control of privileged access without impacting agility, leaving them to focus on what they do best while finally putting the “Sec” into DevSecOps.

    AAPM eliminates the need to store credentials in clear text in the application. Instead, developers introduce API calls in their code to access a vault programmatically and to check out the password. The password is stored in application memory and not written to disk. Once the application terminates, the memory is deallocated and the password is gone, leaving nothing for a threat actor to find. Using this approach, the vault secures the credentials and controls access to them. The vault can also automatically rotate passwords, making them more challenging to crack. Since dependent applications now make API calls to fetch them, DevOps teams are no longer concerned with updating their code whenever the passwords change.

    PAM and DevOps: AAPM in Action

    This is a fundamental approach to AAPM. Other options exist, however, distinguished by increasing levels of cyber-risk mitigation and operational efficiencies:

    Level 1: AAPM to Retrieve a Vaulted ID and Password

    As described, this is the traditional approach to PAM. While vaulting the passwords provides an extra layer of security by removing them from code, passwords remain the weakest form of authentication. Even with automatic password rotation, they persist until the next scheduled rotation (often days or weeks), giving an attacker ample time to attempt to crack. To check them out of the vault, each workload needs a service account. This can quickly amount to hundreds, if not thousands, of additional accounts, increasing administrative overhead and increasing the attack surface.

    Level 2: AAPM to Retrieve a Vaulted ID and SSH Key

    Human administrators and workloads present an added risk to organizations through the widespread use of shared privileged accounts for authentication. Secure Shell (SSH) keys are frequently implemented as a safer alternative, allowing the workload to check out a vaulted SSH key instead of checking out a vaulted password.

    The use of SSH keys includes similar risks and benefits to vaulted passwords. They’re also static, relying on a scheduled rotation. They, too, can be shared among developers and between workloads. Developers and IT admins are often given enough rights to create SSH keys at will without any oversight or central management. This makes them difficult to track and know how they’re being used, by whom and for what. If they’re lost or if a developer leaves, system and service availability can be impacted.

    On the positive side, however, the SSH protocol employs public-key cryptography. The SSH keys (public and private) are longer and more complex than any password. Unlike passwords, they’re not sent over the wire. All this makes them more difficult to compromise and, thus, more secure.

    That said, each workload still needs a service account to authenticate to the vault and check out an SSH key, each of which is a potential vector of attack.

    Level 3: AAPM to Retrieve Ephemeral Tokens

    Ephemeral tokens (e.g., OAuth2) can be created automatically by the vault on-demand and offer a modern form of secure access that is temporary, time-based and expires automatically. This releases DevOps from dealing with installation, configuration and rotation issues while contributing to a best-practice “just-in-time” access control approach. As with the earlier methods, however, each workload still needs a service account to authenticate to the vault to obtain a token.

    Although such tokens can persist, they’re generally short-lived for the duration of a session or transaction, greatly reducing the window of opportunity for a threat actor. 

    Level 4: AAPM Using Delegated Machine Credentials and an Ephemeral Token

    The prior methods are all characterized by a per-workload service account requirement. With a Delegated Machine Credential approach, a service account is only required per-machine.

    When the machine is enrolled in the PAM service, it establishes a mutual trust relationship. The PAM service creates a unique Delegated Machine Credential, machine identity and service account for that machine. Local workloads can then piggy-back off that machine identity, leveraging the delegated machine credential to authenticate to the vault, exchanging it for an OAUth2 bearer token it can use for subsequent API calls (e.g., to check out a password or obtain a token.) Since not all workloads are equal, OAuth scoping can limit which APIs each workload is allowed to access. Thus, by using a Delegated Machine Credential, the number of service accounts is reduced to practically zero, closing thousands of potential vulnerabilities.

    This approach also addresses the lack of desire to introduce PAM into DevOps, as I highlighted right at the start. This method can be fully automated and inserted naturally into the CI/CD pipeline.

    All these approaches give organizations more choice, based on their existing PAM maturity, risk tolerance, and compliance pressures. They ultimately allow DevOps teams to automate, simplify and centralize PAM security management while improving the organization’s security posture, without sacrificing agility.

  • Datadog Allies with BigPanda on AIOps

    Datadog Allies with BigPanda on AIOps

    BigPanda Inc. and Datadog today announced they will integrate their respective platforms to make it easier to form artificial intelligence for automating IT operations (AIOps) to consume data generated by the Datadog IT monitoring service. The two companies are pledging to invest in a go-to-market partnership to create a comprehensive platform for monitoring, analytics and incident management.

    As part of that effort, Datadog is committing to making available an “integration tile” through which BigPanda will also be able to feed root cause analytics based on machine learning algorithms into the Datadog console. That capability will be enabled by a service-to-service topology map created by Datadog that will be used to drive event enrichment, correlation, impact analysis and prioritization.

    Mohan Kompella, vice president of product marketing for BigPanda, said Datadog affords his company a unique opportunity to better train AI models using a massive amount of IT and security metrics that Datadog aggregates daily. That data can then be combined with data ingested from other IT service management systems, which will enable IT operations to automate processes using better-trained AI models, added Kompella. Thanks to modern application programming interfaces (APIs), Kompella noted it’s become a lot easier for platforms such as BigPanda to consume a wide range of data.

    The more data an AI model is exposed to the faster it learns about the IT environment an organization is seeking to automate. Each IT environment is unique, so it usually takes some time for AI models to be optimally tuned. The more data that’s made available, the faster the AI platform is able to make accurate recommendations. It’s then up to each IT team to decide to what degree they want the AIOps platform to automate a task based on those recommendations versus implementing themselves. The more accurate the recommendations become over time, the more confidence IT teams gain in the AIOps platform.

    Of course, IT environments tend to change rapidly and evolve in the DevOps era. The alliance with Datadog will provide BigPanda with a primary source of data from tools that are already widely employed by DevOps teams.

    Ultimately, the goal is to reduce the mean time to resolution for IT incidents, in addition to eliminating as much as possible the need to invite developers and IT operations teams to a “war room” meeting to discover the root cause of an issue. Many IT teams these days find themselves spending weeks trying to ascertain the root cause of an issue that, once discovered, only takes a few minutes to fix. AIOps platforms afford IT teams the opportunity to eliminate a lot of friction that currently exists in those complex IT environments that have scaled beyond the ability of humans to manage without some AI assistance.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, interest in AIOps is clearly on the rise. IT environments continue to grow in size as the enterprise IT becomes more extended. It won’t be long before most IT teams expect to be able to leverage AI to manage highly distributed computing environments. It may, of course, be a while before IT teams fully trust those platforms; however, it’s also clear IT as a whole is reaching a point where there is no alternative.