By James Wickett, DryRun Security and Brian Joe, Impart Security
This is the second of our two-part blogs marking an exciting collaboration between DryRun Security and Impart Security. With founders hailing from Signal Sciences, both teams bring their wealth of knowledge and experience to the forefront of the cybersecurity landscape.
Our Mission
With this joint venture we hope to advance the movement of embedding security within software, transforming it into a developer and DevOps-friendly tool. We firmly believe that the future of security lies in its seamless integration with the software that is at the heart of our digital world.
A Recap
In our previous post, we invited you to join us on this journey to explore, clarify and enrich the conversation around shifting security paradigms in an era defined by software and agility.
To start the process of understanding what’s next in the world of AppSec, we took a look at the past. We began in the early 2000s when cyber security was transformed by the advent of two vital technologies: Web Application Firewalls (WAF) and security testing tools such as Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST). This was the first wave in defense and detection, or Wave 1.
By 2010 Wave 2 rolled in. Wave 2 marked a change from security being an isolated concern of security professionals and auditors, to becoming an integral part of development and operations (DevOps) and security teams.
We’re now in Wave 3: Contextual, Integrated Defenses
Wave 3: Contextual, Integrated Defenses
2020 brough isolation (looking at you Coronavirus) with an even bigger reliance on technology. With that reliance so rose cloud native application development, the third wave of defense and detection.
With Cloud Native, the nexus of product development has significantly shifted towards Continuous Integration/Continuous Deployment (CI/CD) pipelines, establishing them as the primary hub for software development. Application Programming Interfaces (APIs) have emerged as the modern standard for data exchange.
This standardization in the process of how applications are built has fundamentally increased the available context surrounding the actions of both developers and users.
It's a stark contrast from the past, where security teams had to invest considerable time and effort to glean this type of context, either through questionnaires, meetings, or combing through millions of access logs.
Now, with the context coming through the firehose of devtools, CI/CD pipelines, and API traffic, we can more easily answer questions that were once hard to tackle.
We can now figure out who's creating or using an API, understand where the data in an application came from, and see what else the people building and using the API are up to. On the dev side, we can gather static, change, and app context as developers write and merge code.
This wealth of information provides a detailed picture of how applications work and interact. Being able to see these details is changing the way we think about and approach security in applications in a good way.
Enter Contextual Security Analysis
We call this approach Contextual Security Analysis (CSA): the next generation of AppSec. It uses all the pieces of context (static, change, app) gathered as developers are writing code (e.g. codepath, functions, author, language) to make contextually aware assertions in near real-time.
Contextual Security Analysis uses factors of context to analyze changes as they happen in near-real time. The analysis happens across multiple factors because these all work together to determine if a change is risky or not. For instance—a sensitive file being touched by someone who rarely commits code to a particular repo is worth digging in deeper, but if they’re just making changes to a template using safe patterns, then the risk is little to none. In both cases, it’s the context about the change that matters.
Contextual Security Analysis doesn’t just use the traditional testing approach of SAST/DAST or the regex approach of WAF. It is the behavioral analysis of a deeper range of signals and data that is common and now easily accessible in cloud native development patterns. When we talk about the data that we use to signal risk, we use the SLIDE model to consider what sources should be included.
SLIDE model
The context clues we gather from any particular change fit into one of these five areas:
- Surface - how the surface of the application changes
- Language - the language and framework that the application is written in
- Intent - evaluates the person making the change, both in their patterns and their purpose
- Detection - the tooling in place to detect vulnerabilities and security issues
- Environment - the purpose of the application and service in the organization
CSA in Four Scenarios
CSA reduces the noise and "gates" that Wave 1 and Wave 2 security tooling and processes have traditionally put in place. As Wave 3 develops, we’ll continue to see new patterns emerge. Let’s look at four scenarios of where wave 3 is heading.
Detailed Analysis of Code, API Specs, and Business Logic Scenario
Contextual security dives deeper than just scanning code. It critically examines API specifications and business logic. For instance, consider an API that enables fund transfers between bank accounts. While traditional methods might check for SQL injection or cross-site scripting, contextual analysis would probe the logic, ensuring that transfer limits are enforced and the correct account details are used, preventing unauthorized transfers or potential fund leaks.
Developer Activity Insights Scenario
Understanding developer behaviors can be vital for security. Monitoring which developer made the latest changes to a piece of code can give insights into potential risks. For example, if a junior developer with limited experience in security updates a critical payment module, it might necessitate a thorough review. Tracking the frequency of updates can also highlight irregularities. If a code segment that usually remains static sees sudden frequent changes, it could indicate a breach or a potential issue.
User Activity Patterns Scenario
Monitoring how users interact with APIs or platforms is crucial. Say an API user typically accesses data once a week, but suddenly there's a spike in requests, or they're directing large amounts of data to an unfamiliar endpoint. Such anomalies can signal a compromised account or malicious intent. It's not just about blocking unauthorized access but understanding the nuances of legitimate user behavior to detect subtle anomalies.
Context from Internal Assets Scenario
An in-depth understanding of internal tools and repositories is essential. For example, if a company uses a particular version control system and there's an irregular commit to an unknown branch, or a pipeline that's meant for testing starts deploying to production, these can be early indicators of internal issues or external threats trying to exploit system vulnerabilities.
It’s about the Benefits
The next wave of security tools are taking advantage of these new sources of information, and fusing them together natively with the Wave 1 (Protect Right) and Wave 2 (Shift Left) approaches into integrated, contextual solutions.
CSA delivers a user experience that
- minimizes false positives
- improves collaboration
- enables better decision making
- empowers developers to move and assess with greater agility
- increases visibility into the system
- ultimately lessens the workload for security teams
Integrating CSA into Your Security Program
We’ve written a great deep dive into Contextual Security Analysis that can help you incorporate this approach into your own application security program. It’s free and we invite you to download it from our Resources page. This e-book will definitely give you a leg-up on building your own in-house CSA program.
If you would like a jump-start into Contextual Security Analysis, we’re here to help you utilize CSA techniques and integrate them directly into existing developer workflows and runtime technology stacks within your enterprise so that you get a seamless experience.
Companies like ours (DryRun Security and Impart Security) are the next wave in security tooling because we’re leveraging the under-utilized context and integrating them natively with the Wave 1 (Protect Right) and Wave 2 (Shift Left) approaches to enrich their detection and response models for both developers and security teams.
Here at DryRun Security, we’re focused on source code analysis while Impart Security is focused on API security. Both solutions give you context in near real time with easy setup and integration into your CI/CD pipeline so you can get the positive security outcomes you need.
What do you think?
We’d love to know your thoughts on the next generation of AppSec. Email us at hello@dryrunsecurity.com or info@impart.security, or drop a comment via LinkedIn: DryRun Security | Impart Security
.webp)
