devopsy.kinsta.cloud

Tag: devsecops

What SASE Means for DevOps Teams
You have probably heard the acronym secure access service edge (SASE), and it’s hard to ignore its impact on the technology industry. SASE is a cool new way to implement networking in hybrid environments, and the most important thing about it is that it bakes security into the network fabric. In plain English—when you plug in, you are secure by default.

SASE will have a special impact on two fields near and dear to the hearts of DevOps teams:
1. Cloud security—SASE has the potential to transform how we practice security in the multi-cloud, and unify it with security in the central data center.
2. DevSecOps adoption—SASE can make DevSecOps easier to adopt and might become essential infrastructure for globally distributed DevSecOps teams.
Let’s understand the anatomy of the SASE beast, and understand how it will affect DevOps in the years to come.

What Is SASE?

SASE is a cloud service that extends networking and security capabilities to support hybrid organizations’ dynamic, secure access needs.

SASE combines WAN capabilities with network and security functions, such as firewall-as-a-service (FWaaS), zero-trust network access (ZTNA), secure web gateway (SWG) and more.

A SASE platform bundles multiple security capabilities, including SD-WAN and services like SWG, CASB, ZTNA, FaaS and SaaS. This multi-region, multitenant architecture supports a distributed and remote workforce. SASE uses inspection engines located at points of presence (PoPs) near the endpoints rather than in the data center. SASE clients send traffic to the nearest PoP.

The core characteristics of a SASE architecture are:
- Global SD-WAN—A private SD-WAN backbone helps reduce latency by avoiding the public internet.
- Distributed architecture—SASE inspects traffic and enforces policies at the edge using multiple inspection engines.
- Cloud infrastructure—SASE delivers services via the cloud, so tenants don’t have to maintain hardware and other infrastructure resources. This approach is scalable and cost-effective.
- Identity-based access—Access controls use identity markers like the user’s location and device.
SASE Adoption Drivers: Why Do Organizations Want It?

Cost Reduction

Using physical and virtual appliances from multiple vendors is highly cumbersome and costly. SASE enables organizations to replace this disparate model with a single, cloud-native solution. Organizations can use SASE to deliver more technologies and services via one provider instead of several. As a result, it eliminates the cost of miscellaneous network appliances and optimizes cloud costs, by reducing the resources and bandwidth needed to operate a cloud environment.

Edge-to-Edge Security

SD-WAN is an integral component of SASE, providing features such as an active-active failover and WAN optimization that improve performance and increase network resilience. SASE solutions are based on the concept of security automation, with a fully managed network security stack that typically includes SWGs, next-generation firewalls (NGFW), next-generation network architecture and intrusion prevention systems (IPS). This model helps protect all edges, achieving better network visibility.

Data Protection

SASE provides a holistic data protection experience that automates multiple DLP processes, including data discovery and data classification of storage locations, data usage and data in transit. It employs various security measures, such as user and device authentication, to enable control over access to data and resources at all times. Additionally, SASE DLP seamlessly rolls out protection policies across the entire network.

Impact: How SASE Will Transform the Cloud Security Stack

The emergence of services like PaaS, SaaS and IaaS has encouraged organizations to allow remote work. The cloud supports distributed workforces and streamlines business processes, but it also exposes companies to network-based threats. Many organizations store sensitive data with third parties accessed online.

The cloud security stack can easily become siloed, with team members unsure of their responsibilities and overlooking critical processes. A siloed stack is more labor-intensive and harder to track because the security team uses multiple security systems. It can also create alert fatigue, making it hard to identify threats.

While employees mostly work in the cloud, security efforts often focus on the data center. SASE shifts the focus to the cloud while ensuring seamless integration between security services.

With SASE, a single provider delivers the entire security stack, ensuring it functions as a unit. For instance, an SWG uses threat intelligence data to block suspicious traffic, sending unidentified files to a sandbox for testing. The security team can manage the entire stack from one intuitive interface.

Most activities occur at the edge—SASE secures the edge using an identity-driven approach. It is also cloud-native, ensuring a seamless experience.

Impact: How SASE Will Promote DevSecOps Adoption

SASE provides the following advantages for adopting DevSecOps.

Facilitating Collaboration

SASE helps reduce the challenges involved in cross-team collaboration. Essentially, SASE combines network security with WAN optimization. Modern DevOps teams are physically separate but must work together, requiring reliable and secure connections between team members.

The DevOps approach emphasizes time-to-market, so DevOps teams look for ways to accelerate the CI/CD cycle and push releases faster. An important part of the process is reducing the DevOps team’s reliance on the network and security teams. SASE solutions help optimize performance and enhance security, so the DevOps team doesn’t have to wait for the infrastructure team to configure resources. SASE gives DevOps teams the necessary control and operational cadence without compromising security or performance.

Enhanced Networking

SASE can improve the overall network performance by providing integrated failover and load balancing capabilities. DevOps teams must have reliable connectivity and cannot tolerate disruptions when deploying new software or fixing bugs. Fast, reliable application performance is key to the DevOps workflow.

The SASE architecture improves the networking, ensuring the organization’s edge devices, cloud resources, data center and remote users remain connected. The DevOps team doesn’t have to handle the infrastructure because it is self-healing, fully optimized, and secure. The solution automatically switches to another path if a line fails or a path becomes congested.

Security By Default

SASE protects DevOps projects with built-in security features. When implemented properly, it integrates many security technologies into the network stack. The DevOps team doesn’t have to worry about attackers intercepting sensitive information. Every security service shares the same, unified context to increase visibility and fill gaps that are often present in traditional security architectures. SASE mitigates the vulnerabilities exploited by attackers using NGFW, SWG, IPS, MDR and antivirus services in a single architecture.

SASE can secure internal applications and their interactions, reducing the burden on the DevSecOps team. Applications running on a SASE-based SD-WAN benefit from the added protection of zero-trust network access (ZTNA) and software-defined perimeter (SDP). These technologies help ensure that all interactions between applications and endpoints are secure.

Proprietary apps are often too sensitive to expose to the public Internet. SASE secures these applications by obfuscating traffic, securing all entry points with NGFW, and restricting access with zero-trust network architecture. It constantly inspects all internal application traffic for cybersecurity threats.

Conclusion

In this article, I explained the basics of SASE, which packages multiple networking and security solutions into one managed service.

SASE is giving organizations a new level of flexibility and agility with regard to their core infrastructure and is introducing the concept of security-by-design. Instead of fighting hard to “secure all the things,” we are moving nearer to a world where the “grid” our organization operates on is secure by default. This won’t make DevSecOps any less important. But it will allow us to build our applications and services within a secure, controlled hybrid environment.
July 19, 2022
Security Compass Makes Visualizing AppSec Threats Simpler

Security Compass this week updated its threat modeling platform for developers to make it easier to surface application security issues.

The latest version of SD Elements 2022 adds support for developer-centric threat modeling diagrams, reusable components, more advanced reporting capabilities and 114 more just-in-time training (JITT) modules. In addition, Security Compass has now integrated its platform with the Black Duck software composition analysis (SCA) tool.

Drew Koelemay, director of product management for Security Compass, said the goal is to make it easier for application development and cybersecurity teams to collaborate using a platform that visualizes cybersecurity threats within a DevOps workflow.

That approach to application security is critical because it becomes easier for developers to understand how changes to applications improve the overall cybersecurity posture of complex app environments where there are lots of dependencies, he said.

Once that visualization is achieved it then becomes possible to create reports highlighting the most prevalent threats and weaknesses across that portfolio, Koelemay noted.

In the wake of a series of high-profile application breaches, organizations of all sizes are looking to better secure their software supply chains by implementing DevSecOps best practices. The issue that immediately arises is the cultural divide between application development teams and cybersecurity professionals. The Security Compass platform surfaces developer-centric visualizations of security issues to help bridge the historic divide that exists between those teams, said Koelemay.

For the most part, cybersecurity professionals view development teams’ lack of cybersecurity expertise to be the root cause of many of the issues they encounter. It’s not that a developer deliberately sets out to build and deploy vulnerable applications. By the time the application is reviewed—often just a few days before it’s supposed to be deployed—it’s often too late to do much about most of the vulnerabilities that are discovered. Cybersecurity professionals and application development teams need to meaningfully engage each other much earlier in the application development life cycle.

The simple truth is developers are not likely to reach out first simply because they don’t know what cybersecurity issues to look for in an application environment. Most of the time they are rushing to meet an application delivery deadline, which makes them perceive cybersecurity as a hurdle to overcome rather than an automated process integrated within their workflow. Cybersecurity professionals, therefore, need to find a way to more constructively engage developers. The onus is on cybersecurity teams to insert themselves at the front end of the application development process rather than waiting at the backend for an inevitable issue to arise.

One way or another, application security is going to improve. The only thing yet to be determined is how painful the process will be. Tools that enable DevOps teams to see for themselves what issues are being encountered should go a long way toward reducing both the level of pain being experienced and the amount of time required to resolve the cybersecurity issue at hand.

July 14, 2022
Scribe Security Unveils Pair of Tools to Secure Software Supply Chains

Scribe Security today unveiled a Scribe Integrity tool that scans software artifacts to make sure they comply with IT organizations’ security policies before they are integrated into an application.

The Scribe Integrity tool authenticates open source and proprietary source code before it is uploaded into a build. It assumes that all artifacts are “guilty” until they can prove their innocence, said Rubi Arbel, CEO of Scribe Security. That approach makes it possible to ensure the integrity of the overall software supply chain is maintained in a way that doesn’t adversely impact the productivity of developers, he added.

In addition, the company launched GitGat, an open source policy-as-code tool based on Open Policy Agent (OPA) agent software that enables DevOps teams to periodically run reports that surface insights into the security posture of code residing in GitHub repositories.

Arbel said that, in time, GitGat’s reach will be extended to add support for additional continuous integration/continuous delivery (CI/CD) platforms.

The first release of Scribe Integrity addresses Node.js code and the npm package manager with support for additional types of code planned.

The Scribe Integrity tool also identifies all dependencies to enable DevOps teams to generate an accurate software bill of materials (SBOM) as each software artifact is included in the application, he noted. That’s critical because it enables developers, IT operations and cybersecurity teams to simultaneously see what artifacts, including containers, make up an application, noted Arbel. In the future, the company plans to make available a Scribe Hub that will make it easier to share insights into those software artifacts, he added.

A series of high-profile security breaches clearly demonstrated cybercriminals’ skill at injecting malware into software artifacts and compromise any application that incorporates that artifact into an application. That malware can then be activated at some later date to potentially compromise any number of downstream applications.

Those incidents resulted in a greater appreciation for DevSecOps best practices to maintain the integrity of software supply chains. The issue that DevOps teams are trying to address is how to build more secure applications without slowing down the rate at which those applications are built and deployed. As such, DevOps teams are adding tools to the application development process that make it easier for developers to scan code before it is included in an application and verify the integrity of any software component that becomes part of a DevOps workflow.

It’s unknown how long it may be before the adoption of DevSecOps best practices has a meaningful impact on application security. However, waiting to focus on security until after an application has been deployed is way too late. Cybercriminals today can discover flaws and misconfigurations in applications in a matter of minutes. As more applications are deployed, developers can find themselves spending more of their time fixing vulnerabilities than they do writing new code. A new approach to building applications that are secure from the ground up is clearly required.

July 14, 2022
Rezilion Launches Vulnerability Prioritization Platform

Rezilion today announced general availability of a platform that enables DevOps teams to better prioritize remediation efforts by identifying which vulnerabilities both run in memory and actually impact a class or function that can be executed.

Liran Tancman, Rezilion CEO, said the biggest DevSecOps challenge organizations face today is that the bulk of vulnerabilities that developers are tasked with remediating don’t constitute a significant cybersecurity threat.

Rezilion has created a searchable proprietary next-generation vulnerability database (NGVDB) that identifies which issues impact specific classes and functions. That capability enables DevOps teams to de-prioritize close to 95% of software vulnerabilities, said Tancman.

In addition, the Rezilion platform will surface remediation suggestions that lower the amount of disruption and/or cost, he said. A fully-automated remediation capability, for example, will automatically upgrade and test vulnerable software components and packages within a continuous integration (CI) pipeline that were found to be exploitable. In the longer term, Rezilion is also working toward surfacing remediation suggestions that might be addressed using an alternative to patching, said Tancman.

The Rezlion platform is also integrated with IT service management platforms such as ServiceNow and project management tools such as Jira to make it easier to address vulnerabilities as part of existing workflows, he added.

Most developers today are simply overwhelmed by the number of vulnerabilities that cybersecurity teams routinely ask them to patch, noted Tancman. The goal should be to enable developers to focus their limited time and effort on remediating the vulnerabilities that truly matter to ensure application security, he said.

In addition, developers need to have more confidence in the fact that the patch they are being asked to make won’t break their existing applications, added Tancman.

Vulnerability prioritization is, of course, at the heart of the long-standing divide that exists between DevOps and cybersecurity professionals. Spreadsheets filled with long lists of vulnerabilities are regularly created, but there is usually no context provided in terms of how severe a threat any given vulnerability poses. As a result, developers would allocate a small portion of their time to applying patches that are prioritized based on intuition and level of complexity rather than severity.

Naturally, developers are going to allocate most of their time to creating new applications and features. For any DevSecOps initiative to succeed, it’s critical to ensure optimal use of the time allocated to remediation. Cybersecurity teams will continue to compile lists of vulnerabilities, but that list can now be triaged in a way that causes the least amount of friction.

In the wake of a series of high-profile security breaches, there is now more focus than ever on securing software supply chains. The challenge is to find a way to better secure applications both before and after they are deployed in a production environment. There will always be vulnerabilities that are discovered after an application has been deployed. However, just because a vulnerability exists, that doesn’t mean it’s exploitable. The trouble with application security today is that, all too often, remediation efforts turn out to be a waste of time.

July 12, 2022
This DevSecOps Thing Is Real After All

Whether you made it to San Francisco, California last month for RSA Conference or not, you don’t want to miss Tuesday’s DevOps Connect: DevSecOps Virtual Summit.

On Tuesday, July 12, 2022, we are presenting a virtual broadcast of the sessions from our recent DevOps Connect: DevSecOps event at RSA Conference in June 2022. All of the great sessions will be available as well as some bonus sessions that didn’t make it to RSAC.

For me, this event was extremely gratifying because it served as validation that I wasn’t crazy all those years ago. When I started devopsy.kinsta.cloud in 2014, I did so because I thought it would be great for security—back then it felt as though I was a lone voice crying out in the wilderness! Now, here we are in 2022 and DevSecOps is real. It is accepted, it is sought-after and it is changing the way software is developed, deployed and managed.

When I put on the first DevSecOps event at RSA Conference seven years ago, it was a bit controversial. The idea of bringing together the security community with the DevOps tribe was like what I imagine peace treaty negotiations between two warring parties would be. The security folks said no one else cared about security. The DevOps people, like many other IT pros, claimed the security folks were just people who said no to all their initiatives. The lack of trust ran deep. But we kept at it—and while the situation is far from perfect today, so much progress has been made.

This year’s event featured our best speaker lineup yet. Jim Zemlin, executive director of The Linux Foundation, kicked off the event by talking about open source and security—software supply chain, SBOMs and security, oh my! Continuing the open source and security trend, CNCF executive director Priyanka Sharma presented a great session discussing cloud-native and DevSecOps.

And you won’t want to miss two of my favorite sessions. The first involves my friend John Willis asking, “What would Deming do?” in his session at 11:30 a.m. ET. Given the current state of world affairs and the software and security market, what would Edward Deming, the patron saint of DevOps, say and do? John is a bit of a Deming expert himself, so his insights are spot on, I think. And second, Carolyn Wong (who is a superstar) talks at 12:00 p.m. ET in her session about pentesting at scale, pentesting-as-a-service and DevSecOps.

But wait—there’s more! Chenxi Wang has a powerful session, delivered off the cuff, about the current state of DevSecOps, software supply chain security, investing and more; that’s at 9:55 a.m. ET.

We’ll also feature two amazing panels: One is made up of the authors of a recent book, Reinventing Cybersecurity. The other features folks from Intel, Mitre, NIST and the U.S. Senate talking about security compliance with an emphasis on software supply chain security and SBOMs (see a pattern here yet?).

And that’s just the tip of the iceberg—there is even more from this year’s event that you don’t want to miss. So, head on over and register—it’s free. Many of the speakers will be online, live, during their presentations to answer questions, network and offer their guidance. There are also exhibits and sponsor booths and other fun stuff like a yoga class and a DJ spinning great tunes.

This DevSecOps stuff is real and you will learn a lot from these sessions. We can’t wait to see you there!

While you’re at it, check out our upcoming CloudNativeDay Virtual Summit August 10, 2022, which is shaping up to be a great event, as well!

July 8, 2022
More Than Half of DevOps Pros Have Backdoor Access to IT Infrastructure

A survey of 600 DevOps professionals conducted by strongDM, a platform for managing access to IT infrastructure, found nearly two-thirds (64%) had productivity impacted on a daily or weekly basis because of access issues.

It’s not surprising that, as a result, DevOps teams created a number of workarounds to gain access, even though those methods don’t comply with cybersecurity best practices, according to the survey. More than half of respondents (55%) maintained backdoor access to systems, and 42% have embraced shadow IT to get access to tools and systems they needed for their roles, the survey found.

Worse yet, the survey found that 53% of respondents admitted they are sharing credentials across teams.

Well over half (57%) of respondents said it could take days or weeks for access requests to be approved, with 40% reporting it takes days to add tools to existing access solutions. Nearly three-quarters (73%) of respondents also noted it requires 15 minutes or more to gain access to infrastructure.

More than half of respondents (52%) said they have missed deadlines due to issues with accessing infrastructure, with 53% of those respondents being held accountable for the missed deadline even if it was caused by their lack of access to infrastructure.

Justin McCarthy, CTO for strongDM, said despite all the hype surrounding identity management and zero-trust IT, it’s clear many organizations are still struggling with the basics of access control. That issue has been further exacerbated by the need to enable more DevOps professionals to work from home since the start of the COVID-19 pandemic more than two years ago, he added.

Many of those organizations are still relying on virtual private networks (VPNs) even though it’s been shown that stealing the credentials to access those VPNs is relatively trivial, McCarthy added.

In place of those approaches to access IT infrastructure, strongDM is making a case for a dedicated infrastructure access platform that manages and audits access to databases, servers, clusters and web apps. It is based on local client software, a gateway intermediary and configuration tools that track roles and permissions.

The benefits of that approach span everything from lower IT support costs to faster onboarding of new IT staff, noted McCarthy.

Managing infrastructure access for DevOps teams is, of course, always going to be a challenge. DevOps teams are made up of engineers—among the most challenging types of end users to support. Many of them will use their own expertise to circumvent any process they deem to be inefficient. The trouble is, many of those end-runs would not pass muster with cybersecurity teams responsible for access management. The challenge each of those cybersecurity teams needs to come to terms with is the amount of time they want to spend time looking for these cybersecurity policy workarounds versus making it easier to securely access IT infrastructure.

The sad truth is both DevOps and cybersecurity professionals are wasting a lot of time and effort trying to outwit each other when that time could be put to better use.

July 5, 2022
Why Your DevSecOps Initiative Will Fail

When you’ve been in and around the security industry for long enough, you get used to the industry hype machine turning a cool innovation into, uh, meh. This hype cycle starts at the RSA conference each year, and folks like me look for new hot stuff on the show floor. For perhaps only the second time in 25 years, I wasn’t at the show in person, but it seems that DevSecOps was the preferred bandwagon on which every vendor jumped. Sigh.

I’m not sure whether it’s my increasing age or this business that has made me cynical, but here we are.

To be clear, from a customer’s perspective, there is great value in the concept of DevSecOps, as evidenced by the upcoming DevOps Connect: DevSecOps @ RSAC 2022 virtual event. Having these (sometimes) mortal enemies working together toward a common goal is great, in theory. But alas, in practice (and similar to what happened when DevOps hit the scene), it’s easier said (or displayed in a vendor booth) than done.

Thus, I’ve come to a sobering conclusion: Your DevSecOps initiative will fail.

Most organizations will talk a good game for a while and they may even try some stuff, buy some kit, send folks to training and the like. But in the end, despite all these efforts, you guessed it—they will still fail.

Is this a foregone conclusion for every organization? Well, no. But this isn’t my first rodeo, and I’m pretty sure this one will end like the others—in failure.

But let’s say you want it to be different this time. Really, you do. And you are willing to take some actions to give yourself a chance at success. If that’s the case, here are a couple of tips to increase your chances, however small.

Culture

First and foremost, DevSecOps is not a thing. It’s not a set of tools (no matter what the vendors tell you); you don’t buy it on a VAR line card. DevSecOps (like DevOps) is a cultural shift. Your teams need to work together. They need to collaborate. They need to have shared incentives. And they need to experience the consequences of not playing nicely in the sandbox.

Cultural shifts are hard. People don’t like to change. They resist. They undermine. They sabotage. It all sounds nefarious, but they do. So unless you can change your culture, you’ve got no shot.

Shift Left

Another one of these security-marketing-terms-run-wild is shift left. It means you want to integrate security testing directly into the development process as early as possible. You should be running security checks in the developer’s IDE to ensure they don’t violate security policy (like hardcoding API keys in their source, for example) before they even commit the code.

You must also integrate security testing into the CI/CD pipeline(s). Thus, you need tooling that works with your preferred pipeline.

Security Champions

Security testing will create angst for your developers. They will have false positives. They will have to fix things that they probably don’t understand. It will cause them to miss delivery dates. Of course, they should build it right the first time, but in their mind, they’ll see it as the security folks causing delays.

The developers will be annoyed, and you’ve got to manage that annoyance—or have senior management quash any rebellions, but that’s not a long-term solution.

On the other hand, you could establish a security champions program, which anoints (and trains) developers on each team to “represent” security within the development team. They help educate the developers on the tools and secure coding. They diffuse irritation when something goes wrong.

A strong security champions program is one of the leading indicators of DevSecOps success.

Break the Build

Finally, the security team must have the juice to break the build if a critical issue is found during the deployment. We talk about this with many organizations and they nod their heads. But they are lying to me and to themselves. When it comes down to it, someone on the dev team calls someone in senior management and, all of a sudden, that critical issue is now an alert, not a failed deployment.

Not being able to stop a build will kill your DevSecOps program. It’s like when a quality control issue forces someone to stop the assembly line. If you don’t stop the line, faulty products can result. In a security context, that means some critical vulnerabilities will be much more expensive to fix later.

So, there you have it. If you can evolve your culture, integrate security testing into your toolchain, empower security champions and empower your team to stop a deployment, you’ve got a chance at a successful DevSecOps program.

Unfortunately, you probably can’t do these things, and you’ll likely fail. In that case, I have some lovely property by a waterfall I’d like to sell you.

July 5, 2022
The Two Types of Code Vulnerabilities

Spell checkers, grammar checkers and predictive keyboards all help reduce errors in written communication, but in a creative medium where writers need to innovate new expressions, nothing can eliminate all errors. The same is true in the code we write.

Of course, your code is probably perfect but, on average, all code has bugs. Some of those bugs are benign. Some will cause unexpected early termination. A few will cause runaway resource consumption. And some bugs lead to security vulnerabilities that let users do things that are unexpected and sometimes undesirable.

Those security bugs are behavioral vulnerabilities because they depend on how the code behaves when executed. Another type is an intelligence vulnerability, something that’s part of the correct behavior of the code, but which gives away details about how to exploit a system. These are the two main types of code vulnerabilities; both come with risks.

Behavioral Vulnerabilities at Runtime

Tl;dr: How the code works and how attackers can leverage what it does to their advantage.

This covers a broad range of problems, but all of them are a result of the behavior of the code leading to undesirable outcomes in specific circumstances. Most of these are unintentional. An unescaped user input sent to a database can lead to a SQL injection vulnerability or an unsanitized string sent to a browser could create a cross-site scripting (XSS) vulnerability. Some behaviors are intended, but have unexpected consequences; the Log4j string substitution behavior that allowed it to output environment variables or read data from external resources was intentional, but the malicious usage we now call Log4Shell was not. In another recent example, a combination of behaviors could be exploited to gain root privileges on Linux desktop computers.

Intelligence Vulnerabilities in the Content

Tl;dr: What the content of the code tells an attacker about the system and how to access it.

In the 1950s, the phone company—there was pretty much just one at the time—began implementing completely automated dialing that didn’t require a human operator at the switching station to connect the call. The details were first published in a technical journal in November 1954 (see pages 1209 and 1309 here), and the information gleaned from that led to the creation of “blue boxes” that used insider knowledge to allow outsiders to control telephone equipment and make free long-distance calls.

That’s hardly the first example of insider knowledge being leveraged for outside advantage, but its role at the heart of computer hacking and the origins of the PC (the ‘hack’ inspired Wozniak and Jobs) is so legendary that it demands recognition here.

The phone system’s intelligence vulnerabilities were published in the company’s technical manuals—manuals that many thought were only for internal use, and nobody realized were available to untrusted readers. Today, though, intelligence vulnerabilities are in our code.

Secrets abound in code, along with the details about which systems those secrets connect to. These secrets were once difficult to manage and putting them in code was the only practical choice. Now we have tools like Hashicorp Vault, as one example, and secure keystores in almost every cloud, but the legacy and security debt of all those secrets in legacy code are a goldmine for attackers like Lapsus$ and others who specifically target code.

Security Is a Process, not a Product

There’s a lot hidden under the surface in the two categories outlined here. Each of us can name many types of behavioral vulnerabilities—many more than the different types of intelligence vulnerabilities—but the two classes of vulnerabilities represent relatively equal risk. Recent events have demonstrated how an attacker with inside knowledge gleaned from code—and with passwords and keys taken from it—can move quickly despite firewalls and other access controls.

Identifying secrets and other intelligence risks in code is relatively easy, but few teams do it because detection is the easy part. Integrating detection in developer workflows so they can take action in-context while working on and reviewing code is the most effective way to eliminate creating new security debt. And tools that give developers the information they need to understand the overall picture of intelligence risks in their code, the areas of highest risk—and that point them to actionable issues they can fix immediately to improve their code health—are necessary to help teams mitigate historical risks, ideally by rotating any secrets found.

Tools exist that can automate that process and help teams to eliminate more than half the risk in their code—but the first step is recognizing where that half resides.

June 30, 2022
Common RDS Misconfigurations DevSecOps Teams Should Know

Relational databases have become the option of choice for organizations wishing to streamline and scale the use, storage and retrieval of data. Many organizations choose AWS Relational Database Service (RDS) to forego the resource-intensive tasks related to database administration including management and continuous oversight. RDS is a fully managed service that simplifies and automates these processes, making it easy to set up, operate and manage relational databases in the cloud—including MySQL, PostgreSQL, MariaDB or Aurora—and their various time-consuming activities. Reducing costs and automating processes makes significant business sense and allows organizations to focus on performance, scalability and cost-effectiveness as data grows.

That said, AWS is not the owner or the party responsible for securing your data—this duty remains in the hands of the organization. As the cloud provider, AWS does offer an impressive suite of security measures for protecting the infrastructure that runs its cloud services, including access controls, database snapshots and encryption. Their policies, however, clearly state that safeguarding data is within the responsibility of the organization and, as the moderator of your environment, you will be accountable for what occurs within it.

The following are the six most common RDS misconfigurations related to security and compliance that DevSecOps teams should be aware of to secure their data stores and organizational assets.

Broken Geo-Trust (aka Data Sovereignty): RDS provides the convenient option to distribute data across various AWS regions. There are various benefits to this data migration including minimizing latency, disaster recovery capabilities and scaling operations. However, the security and governance risks of cross-geo replication may significantly outweigh these benefits. A common misconfiguration includes migrating replicas or storing backups and snapshots in another location. When sensitive data travels and is stored in another geographic location, the organization may be at risk of violating international compliance requirements such as Schrems II (for EU-to-U.S. data transfer). Additionally, data traveling to various locations may not be visible to security teams or managed by DevOps teams—without a continuously updated inventory, data will spread unobstructed and ungoverned.

The screenshot below displays a copy-snapshot operation of a U.S.-based RDS datastore to an EU region.

Inadequate Retention Periods: AWS allows organizations to retain database instances for a specific period of time as configured by the user. A common misconfiguration of this feature is the existence of unmonitored standalone snapshots, short-lived backups and a failure to permanently delete records. Organizations that retain records for a long period of time may be in breach of their GDPR obligations, whereas short-lived backups may jeopardize the organization’s ability to recover critical data in case of data loss or a ransomware attack. Clear guidelines and open communication between DevOps teams and compliance leads is the first step toward a healthy environment.

The screenshot below presents a recommended and comprehensive backup retention period configuration from an RDS datastore creation process.

Exposed Resources (Network Access): Publicly accessible database ports and RDS instances are a lucrative configuration loophole for malicious actors. Common misconfigurations may cause RDS database snapshots to be publicly accessible, thus providing unauthenticated users with privileges to access and abuse it through brute-force attacks, known CVEs and DDoS attacks—thereby exposing sensitive data. This risk will also impact the organization’s ability to comply with international regulatory requirements and should be a high-priority configuration when creating and maintaining such resources.

The screenshot below presents recommended network (public) access and default port configuration from an RDS datastore creation process.

Weak Encryption: Encryption of sensitive data—both at rest and in transit—is a necessary security baseline to ensure the integrity and confidentiality of organizational data and make it inaccessible to unauthorized users. Common encryption misconfigurations may include implementing inadequate encryption for communication channels such as TLSv1.2 (and higher), weak cipher suites or untrusted CA which may lead to a false sense of security. For data at rest, another common misstep is a lack of key rotation or exposure of the encryption key to unauthorized entities.

The screenshot below presents the recommended basic encryption-at-rest configuration to be enforced when creating an RDS datastore.

The screenshot below presents recommended basic encryption-in-transit configuration to be enforced when creating an RDS datastore.

Improper Authentication & Authorization (RBAC): A cornerstone of adequate data security hygiene is ensuring that access is only associated with a unique account based on the principle of least-privilege, using strong identification methods with appropriate justification. With RDS, users may not use IAM accounts, provide over-privileged access and permissions to either the main instance or to backups and refrain from implementing a user-access quarterly review.

The screenshot below presents the recommended authentication configuration to be enforced when creating an RDS datastore.

Incomplete Audits: Visibility cannot be considered a point-in-time activity. Monitoring of access and use of sensitive data is an essential component of tracking organizational assets and will provide crucial information in case of an incident or potential data breach. Incomplete or misplaced audit records including login/logout events, short-lived audits or leakage of sensitive data from RDS to audit logs increases the risk.

The screenshot below presents the recommended audit and log configurations when creating an RDS datastore.

Misconfigurations and single points of failure in cloud environments may be unavoidable for all organizations, especially those operating at scale, due to knowledge gaps, high velocity of data and changes and a lack of visibility as the amount of data increases. While the security baseline may be covered by RDS configurations, these are only the minimum required to protect your environment. DevSecOps teams are encouraged to work closely with their compliance leads to ensure that customer data is secured; leveraging RDS for its benefits is a complex and entirely more substantial responsibility. Organizations must view their data as an inherent part of their internal assets. As its owner, they should create appropriate ecosystems that allow continuous oversight and monitoring of the data, gaps that may arise and, most importantly, the controls in place to secure it.

June 29, 2022
Quick! Define DevSecOps: Let’s Call it Development Security

For a good long while, DevSecOps referred specifically to vendors like Veracode that did static application security scanning, dynamic application security scanning, software composition analysis and some form of runtime monitoring (usually interactive scanning). Then we realized that DevSecOps was potentially a lot more than that and, like DevOps, we drove the word to encompass all things that shift security left.

That’s where we are now. But that leaves the DevSecOps market confusing to a lot of people. I propose we rename the tools that specifically focus on code quality to Development Security—even though that name is not perfect and all-encompassing. It’s a better fit than terms in other spaces, like Password Management, which includes two-factor authentication (2FA), multifactor authentication (MFA) and, increasingly, passwordless and secrets management, none of which actually use passwords for the focus of their functionality.

This way, we can all understand that DevSecOps is the mindset and methodology and Development Security is one piece of implementing DevSecOps.

There are probably people smarter than I am who have come to this (or alternate) conclusions, and I’m happy to run with their solutions, too—this is just an attempt to make it less confusing for those who don’t live and breathe the security and DevOps markets. If a new person says, “I think we need DevSecOps,” they are in for a journey to actually figure out what they meant and if what they need is actually DevSecOps. We should strive to clarify that so, at the beginning of their research, it is clear that DevSecOps is like DevOps—an overarching term for policies, procedures, mindset and products while the tools that can help with DevSecOps, like those that make up the overarching DevOps toolchain, belong to a market segment named X. In my case, I proposed Development Security because it’s a close fit. What we actually call it is irrelevant, as long as new people understand it is a subset of DevSecOps.

While you continue to keep the systems spinning and the organization online, when you research these products, use phrases like, “I’m looking for Development Security tools that fit with a DevOps environment.” Markets are largely named by vendors and pundits but, in the end, all these people want to talk in terms their customer base recognizes. So, if enough of you ask for Development Security, that’s what they’ll all start calling it. Effective immediately, that’s what I’m calling it. It is a distinctive set of functionality that all orgs who do internal development need, so let’s give it a distinctive name. And yeah, drop me a line if you have a better name. I’m tied to making it easier, not to a specific term.

June 29, 2022