Security Engineering - HEALTHYBYTE

The Anatomical Evolution of Account Takeover Attacks

Shasheen Bandodkar — Mon, 03 Nov 2025 08:01:00 +0000

B Sides ‘25 Orlando
B Sides ‘25 Chicago

Why CVEs will not help with AI Models

Shasheen Bandodkar — Tue, 14 Oct 2025 04:00:00 +0000

The security industry as a whole has spent decades building robust frameworks for identifying, tracking, and remediating software vulnerabilities. At the heart of this system lies the CVE program (Common Vulnerabilities and Exposures), a method to catalog security flaws that has become synonymous with vulnerability management. With AI models now, we face an uncomfortable truth: the CVE framework fundamentally cannot address the security challenges posed by machine learning systems. This is not a minor limitation that can be patched with incremental improvements. The mismatch runs deep, rooted in foundational differences between how traditional software and AI models operate, fail, and expose risk.

The CVE Framework: Built for a Different Era

To understand why CVEs fail for AI models, it’s important to understand what they were designed to handle. The CVE system excels at cataloging vulnerabilities in traditional software because it makes several core assumptions:

Vulnerabilities exist in source code or binaries with deterministic behavior.
A vulnerability can be precisely located and described.
Versions can be clearly identified and compared.
Fixes can be deployed as patches without fundamentally altering the software's purpose.
The vulnerability is reproducible across identical deployments.

How AI Models Break These Assumptions

AI models, particularly large language models and deep neural networks, operate under entirely different principles that violate every assumption the CVE framework relies upon.

The Non-Deterministic Problem
- Traditional software follows deterministic execution paths. Given the same input and state, the output is predictable and reproducible. This is fundamental to how we identify and verify vulnerabilities.
- AI models are non-deterministic by design. The same prompt to GPT-4/GPT-5 can yield different responses even with identical model weights, depending on sampling parameters, system prompts, or subtle environmental factors. A vulnerability like prompt injection might succeed in one inference run and fail in another, even against the same model version, let alone different models
- How do you assign a CVE to a vulnerability that only manifests probabilistically?
Vulnerabilities in Weights and Biasis, Not Code
- CVEs point out flaws in code. But AI model vulnerabilities often reside in trained weights & biases, the billions of parameters that define model behavior. These weights are not human-readable code. They are the emergent product of training on massive datasets.
- Example: Consider a backdoor embedded in a model through data poisoning. The malicious behavior exists in the weight matrices, not in any trainable code. There is no line number to point to, no function call to patch. The vulnerability is distributed across millions of parameters in ways we cannot precisely locate or understand. Traditional static analysis tools are useless here. You cannot grep for a backdoor in a 175-billion-parameter model.
Data Poisoning: Vulnerabilities Before Deployment
- In traditional software, vulnerabilities arise from implementation errors made during development. The timeline is clear: code is written, bugs are introduced, the software ships, and vulnerabilities are discovered.
- AI models introduce a new attack surface: the training data itself. An attacker who can poison training data can embed vulnerabilities before the model even exists in its final form. These vulnerabilities emerge during training, not during traditional development.
- How do you version control a vulnerability that exists in your training corpus? Do you issue a CVE for a dataset? Against which vendor? The organization that collected the data, the one that preprocessed it, or the one that trained the model?
The Retraining Problem
- When a CVE is issued for traditional software, the response is clear: apply the patch. Patching is relatively cheap, fast, and doesn't fundamentally alter the software's functionality.
- AI models cannot be patched in this sense. If a vulnerability is discovered in a trained model, your options are limited and expensive:
  - Retrain the entire model (costs millions of dollars for large models)
  - Fine-tune to mitigate the issue (may not fully address the vulnerability and can introduce new problems)
  - Implement runtime guardrails (defensive measures that don't fix the underlying issue)
  - Deploy a different model entirely (requires extensive validation and integration work)
- None of these maps to the traditional patch distribution and verification process that CVEs were designed to support.

Context-Dependent Vulnerabilities

A SQL injection vulnerability in a web application is exploitable regardless of whether that application manages a shopping cart or a hospital database. The vulnerability exists in the code, independent of the deployment context.
AI model vulnerabilities are often highly context-dependent. A prompt injection attack that works when a model has internet access might fail in an air-gapped environment. A jailbreak that succeeds with one system prompt might be completely ineffective with another.
This context sensitivity means that a vulnerability in an AI model might not actually pose a risk in many deployment scenarios. How do you scope a CVE when the exploitability depends on integration patterns, system prompts, and available tools or plugins?

Emergent Vulnerabilities and Jailbreaks

Traditional vulnerabilities are often implementation bugs, mistakes/misconfigurations made by devs. AI model vulnerabilities frequently arise from emergent properties of the model itself.
Jailbreak techniques that bypass safety guardrails are not bugs in any traditional sense. They exploit the fundamental way language models process and generate text. There is no code to fix. The "vulnerability" is an inherent property of how the model represents and manipulates information.
When security researchers discover a new jailbreak technique that works across multiple models from different vendors, what exactly gets the CVE? The technique itself? Each susceptible model? The underlying transformer architecture?

The Versioning Nightmare

CVEs rely on precise version identification. "This vulnerability affects versions 2.3.0 through 2.5.7" is a clear, actionable statement.
AI models have versions, but they are not comparable in the same way. A model might be updated with:
- Different training data
- Modified architectures
- New fine-tuning
- Changed inference parameters
- Updated system prompts or safety layers
Two versions of GPT-4 might be dramatically different in their vulnerability profile, even if they share the same version number. Conversely, different models might share identical vulnerabilities because they were trained on similar data or use similar architectures.
The linear versioning model that CVEs depend on does not reflect the reality of AI model development and deployment.

What We Actually Need

The failure of CVEs to address AI model security is not just a theoretical concern. As AI systems become critical infrastructure, we need frameworks that actually work for this new attack surface.

These are some approaches that could work:

Model Cards and Transparency Artifacts

Rather than cataloging discrete vulnerabilities, we need comprehensive transparency about how models were trained, what data they were exposed to, and what risks they might carry. Model cards, datasheets for datasets, and similar documentation provide context that CVEs cannot capture.

Behavioral Testing Frameworks

Instead of identifying specific vulnerabilities, we need standardized tests for adversarial robustness, prompt injection and filtering resistance, bias, and safety. These tests should be run continuously, and results should be publicly available.

Supply Chain Security for ML

Just as we track software dependencies, we need frameworks for tracking data provenance, model lineage, and the full ML supply chain. This addresses risks that CVEs were never designed to handle.

Capability-Based Risk Assessment

Rather than cataloging vulnerabilities, we should assess and disclose model capabilities that could be misused. This shifts focus from specific exploits to potential for harm.

Continuous Evaluation Pipelines

AI model security cannot be a point-in-time assessment. It would need continuous evaluation frameworks that monitor model behavior in production and detect degradation or emergent risks.

Conclusion

The CVE framework represents decades of wisdom in vulnerability management. It has been instrumental in making traditional software more secure. But we must withstand the temptation to force AI models into this existing framework simply because it is familiar. AI models present fundamentally different security challenges that require fundamentally different solutions. Trying to wedge them into the CVE system will end up giving us a false sense of security while missing the actual risks.

As a security industry, it is crucial to experiment, iterate, and build new standards that actually address how AI models fail and how they can be exploited. This work is pressing as AI systems are already deployed in critical applications, and our vulnerability management processes are still stuck in the traditional software era.

Permalink

Can RASP be implemented in a Monolithic Architecture?

Shasheen Bandodkar — Mon, 18 Aug 2025 07:00:00 +0000

Runtime Application Self-Protection (RASP) is an effective method to enhance application security by embedding protective mechanisms directly within the runtime environment. While RASP is often associated with modern, distributed architectures such as microservices, many organizations continue to rely on monolithic systems.

The question then is, could RASP be effectively implemented in a monolithic architecture?

What is RASP?

RASP integrates directly into an application's runtime, enabling it to monitor and respond to attack vectors in real time. Unlike traditional perimeter defenses such as Web Application Firewalls (WAFs), which operate externally, RASP enables the application itself to inspect inputs, outputs, and execution flows. It can detect and mitigate attacks like SQL injection, cross-site scripting (XSS), and zero-day vulnerabilities by analyzing context-specific behaviors within code.

For example, RASP can distinguish between legitimate and malicious database queries based on the application's internal state or it can identify and block unauthorized file access attempts by examining the runtime context of file system calls, preventing attacks such as path traversal, etc. It provides deep contextual insight and protection, however Rasp’s implementation requires compatibility with the application's runtime environment.

Characteristics of Monolithic Architectures

Monolithic architectures involve building an application as a single, unified codebase that encompasses all components, including user interfaces, business logic, and data access layers. This architecture simplifies initial development and deployment, as the entire application is packaged and scaled as one unit.

Monoliths present certain challenges from a security aspect. They are tightly coupled, which means that a vulnerability in one area can potentially affect the entire system. Security in monoliths typically includes static code analysis, perimeter firewalls, and logging, but these may not adequately address runtime threats. As organizations seek to modernize security measures without overhauling their architecture, integrating advanced tools like RASP can be extremely beneficial.

Feasibility of RASP in Monolithic Architectures

Can Rasp be integrated into a monolith? Yes. It is not inherently limited to microservices, rather, it depends on the ability to instrument the runtime environment. In a monolith, RASP can be applied uniformly across the entire application, potentially simplifying deployment compared to distributed systems, where agents must be managed across multiple services. Compatibility with the environment is key. RASP mostly supports common runtimes such as the Java Virtual Machine (JVM), .NET, Node.js, and Python. In practice, security teams can also successfully integrate RASP into legacy systems built with frameworks like Java Spring or PHP without requiring a complete architectural refactor. However, custom or less common runtimes may increase complexity.

Implementation of RASP

To implement RASP in a monolithic application:

Evaluate Your Environment and Risks: Assess your application's runtime and identify primary attack surface and vectors, such as those outlined in the OWASP Top 10 or any attack framework. Check the compatibility with RASP tools and prioritize areas like input validation and data handling.
Integrate the RASP Agent: Integrate/Deploy the agent into your application's deployment process. For Java, add the agent JAR to the classpath and configure it within your application server. In Node.js, include it via a module import in the main entry point. Deploy initially in a non-production environment like staging or development, and use profiling tools to measure any latency, which is typically 5-10% if not optimized.
Define and Configure Policies: Customize detection rulesets to focus on high-risk components, such as database interactions, APi endpoints or authentication workflows. Establish thresholds for blocking versus monitoring, and implement whitelists to avoid disrupting internal operations.
Conduct Comprehensive Testing: Execute your existing test suite alongside security-specific tests, such as those using OWASP ZAP or BurpSuite. Simulate attacks to verify RASP's effectiveness, and monitor for any unintended effects on the monolith's integrated components.
Monitor and Refine: Integrate RASP outputs with your SIEM or detection & response platform system. Set up alerting for detected incidents and regularly review performance metrics to fine-tune configurations.

Challenges of Implementing RASP and Potential Mitigations:

Performance Overhead: Runtime inspection can introduce latency in tightly coupled systems where a single process handles diverse workloads, potentially amplifying delays during high-traffic periods or complex operations.
- Selecting optimized tools with low-overhead instrumentation, combined with external filters like WAFs to offload initial threat detection, and tuning rules to focus only on critical paths, can be a method to mitigate this. Additionally, you can also consider hardware scaling or asynchronous processing, where it’s possible to maintain responsiveness..
False Positives: A monolith's interconnected logic may trigger unnecessary alerts, as internal function calls or data flows could be misinterpreted as external threats due to the lack of clear service boundaries.
- You can address this with targeted whitelisting of known safe patterns, phased deployment starting with monitoring mode to gather data. Leverage adaptive tuning with regular audits of alert logs to help refine rules over time.
Deployment and Maintenance: Changes to the monolith affect the entire application, often requiring full redeploys that could introduce downtime or integration risks, especially when updating RASP configurations alongside code changes.
- Ensure your CI/CD pipeline incorporates security validations by automating tests for RASP functionality, using blue-green deployments to minimize disruptions, and maintaining detailed documentation of configurations to streamline ongoing maintenance.
Cost Implications: Commercial solutions can be expensive for large-scale monoliths. Open-source options can be a method to manage expenses.

Benefits of RASP in Monoliths

RASP offers multiple advantages in monolithic environments, including enhanced runtime visibility, reduced dependency on external security layers, and the ability to respond dynamically to threats. It is particularly beneficial in regulated sectors like finance and healthcare, where compliance requires robust security protection. The unified nature of monoliths can make RASP deployment more straightforward than in fragmented systems.

Why RASP Might Be Better Than DAST in a Monolith

When compared to Dynamic Application Security Testing (DAST), which involves external scanning of a running application to identify vulnerabilities through simulated attacks, RASP provides several select benefits in monolithic architectures. DAST operates as a black-box tool, probing the application from the outside without insight into internal code execution, which can lead to incomplete coverage in tightly coupled monoliths where vulnerabilities may lurk in interconnected logic not easily exposed to external tests. In contrast, RASP's internal instrumentation offers context-aware detection, allowing it to monitor and block threats in real time based on the application's actual runtime behavior, rather than just during periodic scans.

DAST is primarily a testing tool used in development or staging environments, generating reports for manual remediation, whereas RASP provides continuous protection in production, automatically mitigating attacks without interrupting operations. This is especially valuable in monoliths, where redeploying fixes for DAST-identified issues requires updating the entire system, potentially causing downtime. RASP also reduces false positives by leveraging application context, something DAST struggles with due to its external perspective. Overall, while DAST is useful for pre-deployment vulnerability discovery, RASP's proactive, embedded approach makes it a more effective choice for ongoing security in monolithic setups, complementing rather than replacing DAST in a comprehensive strategy.

A Viable Option for Enhanced Security

RASP can be effectively implemented in monolithic architectures, providing a pragmatic means to bolster security without necessitating a full migration to microservices. Its efficacy depends on careful tool selection, thorough testing, and continuous monitoring. Organizations with legacy monoliths should consider RASP as part of a layered security strategy.

Permalink

Confidential Computing for GPU Clusters in the Cloud: Security Attack Vectors and Trusted Execution Environment Exploitation (with NVIDIA Hopper and Blackwell)

Shasheen Bandodkar — Mon, 28 Jul 2025 07:01:00 +0000

As cloud adoption revs for organizations, they increasingly leverage GPU clusters for different functions such as AI, machine learning, and high-performance computing. Protecting sensitive data during computation within the cluster, especially when the data is in use, has become a top priority. This dive into confidential computing, which is powered by Trusted Execution Environments (TEEs), secures data even while it is being processed. With the demand for premium GPUs such as NVIDIA’s Hopper (H100) and Blackwell GPU architectures, confidential computing is extending beyond CPUs to the world of accelerated computing.

GPU Clusters in the Cloud

Cloud providers like AWS, Azure, and Google Cloud offer powerful GPU clusters (such as NVIDIA H100, A100, and soon Blackwell) for demanding workloads, including AI/ML model training and inference, scientific simulations, financial modeling, and rendering. These clusters are often multi-tenant, with multiple customers sharing physical hardware. This raises the stakes for data-in-use security, as traditional perimeter defenses (encryption at rest or in transit) do not protect data while it is being processed in memory.

Confidential Computing & Trusted Execution Environments (TEEs) for GPUs

Confidential computing refers to technologies that protect data-in-use by isolating computations in hardware-based TEEs. Traditionally, TEEs like Intel SGX and AMD SEV have focused on CPUs. NVIDIA’s Hopper and Blackwell architectures introduce confidential computing features for GPUs, enabling secure enclaves for accelerated workloads.

Key features of Hopper and Blackwell include:

Hardware-enforced memory isolation ensures each tenant’s data is isolated at the hardware level.
Encrypted memory reduces the risk from physical attacks or memory scraping.
Attestation allows remote parties to verify the integrity of the GPU’s secure environment before sending sensitive data.
Secure boot and firmware validation, preventing unauthorized code from running on the GPU.

Security Attack Vectors for Data-in-Use

Data-in-use refers to data actively processed by applications, residing in system memory (RAM, GPU VRAM) or CPU/GPU registers. Unlike data-at-rest or data-in-transit, data-in-use is exposed to the compute environment, making it a prime target for sophisticated attacks.

Side-Channel Attacks: Attackers can infer sensitive data by observing indirect information leaks:

Timing attacks: Measuring how long operations take to infer secrets, such as cryptographic keys or neural network inputs.
Cache attacks: Manipulating and observing cache usage (e.g., Flush+Reload, Prime+Probe) to deduce memory access patterns.
Power analysis: Monitoring power consumption to reveal data-dependent computation patterns.
Electromagnetic (EM) emanations: Capturing EM signals from hardware to reconstruct processed data.

Memory Attacks:

Memory scraping/dumping: Attackers with access to the host (e.g., via hypervisor compromise) can dump system or GPU memory, extracting plaintext data.
DMA (Direct Memory Access) attacks: Malicious peripherals or compromised devices can read memory directly, bypassing OS-level protections.
Memory remanence: Data may persist in memory after use; if not properly cleared, subsequent tenants or attackers can recover it.

Hypervisor/Host Compromise:

Host OS/hypervisor attacks: If the underlying host or hypervisor is compromised, attackers can potentially access all memory, including that of TEEs, or manipulate the environment to weaken isolation.
VM escape: Exploiting vulnerabilities in virtualization software to break out of a guest VM and access host or other guest resources.

Insider Threats & Multi-Tenancy:

Malicious cloud staff: Employees with privileged access may intentionally or unintentionally expose sensitive data.
Noisy neighbor attacks: Co-tenants on the same hardware may exploit shared resources to infer or access data.

Supply Chain Attacks:

Firmware/driver tampering: Malicious or vulnerable firmware/drivers can introduce backdoors or weaken security guarantees.
Hardware implants: Physical tampering during manufacturing or supply chain transit.

Exploiting Trusted Execution Environments

TEEs are designed to provide isolated, secure environments for sensitive computations. However, they are not immune to attack. Here’s how attackers may target the TEEs:

Side-Channel Attacks on TEEs:

Spectre, Meltdown, Foreshadow: These CPU vulnerabilities exploit speculative execution and caching to leak secrets from within TEEs (e.g., Intel SGX). While not directly targeting GPUs, similar microarchitectural attacks are plausible as GPU TEEs become more complex.
Cache/timing attacks on enclaves: Even with memory encryption, attackers can observe cache usage or execution timing to infer enclave operations.

Attestation Attacks:

Fake/bypassed attestation: If the attestation process (which proves the TEE is genuine and untampered) is compromised, attackers can trick users into trusting a malicious environment.
Replay attacks: Reusing old attestation tokens to gain unauthorized access.

Rollback and Replay Attacks:

State rollback: For TEEs that maintain state (e.g., secure AI model training), attackers may revert the enclave to a previous state, potentially re-exposing sensitive data or undoing security patches.
Replay of encrypted data: Replaying previously captured encrypted data to manipulate enclave behavior.

Exploiting TEE APIs and Implementation Bugs:

API misuse: Vulnerabilities in the TEE’s API (e.g., buffer overflows, improper access controls) can allow attackers to escape the enclave or leak data.
Implementation bugs: Flaws in the TEE firmware, microcode, or drivers can be exploited for privilege escalation or data exfiltration.

Physical Attacks:

Cold boot attacks: Physically extracting memory modules and reading residual data.
Bus snooping: Monitoring data on the memory bus, especially if encryption is not end-to-end.

Real-World Examples:

Foreshadow (L1 Terminal Fault): Demonstrated extraction of secrets from Intel SGX enclaves.
SGAxe: Extracted attestation keys from SGX, undermining trust in the enclave.
NVIDIA CVEs: While not always TEE-specific, vulnerabilities in GPU drivers/firmware (e.g., CVE-2023-31027) can be leveraged to attack the TEE.

Security Attacks on GPU Confidential Computing (Hopper/Blackwell Focus)

NVIDIA’s Hopper (H100) and Blackwell architectures introduce confidential computing features for GPUs, but also present new attack surfaces:

Shared Memory and Resource Contention:

GPU memory isolation flaws: If hardware or firmware fails to properly isolate memory between tenants, attackers may access residual data from previous jobs.
Resource contention side channels: Attackers can measure resource contention (e.g., memory bandwidth, compute unit usage) to infer co-tenant activity or data.

GPU-Specific Side Channels:

Timing attacks: By submitting jobs and measuring execution times, attackers can infer data-dependent behavior of co-located workloads (e.g., neural network inference).
Memory access pattern leakage: Observing which memory regions are accessed, or the frequency of access, can leak information about the data or algorithms in use.
Instruction-level side channels: Some research suggests that instruction scheduling and execution order on GPUs can be exploited to leak information.

Attacks on GPU Drivers and Firmware:

Driver vulnerabilities: Bugs in the GPU driver stack (e.g., buffer overflows, privilege escalation) can allow attackers to escape isolation or access protected memory. Example: CVE-2023-31027.
Firmware attacks: Malicious or vulnerable firmware can undermine all hardware protections, allowing attackers to bypass memory encryption or isolation.

Data Leakage via GPU Memory:

Improper memory clearing: If GPU memory is not zeroed between jobs, sensitive data from one tenant may be accessible to the next. This is especially critical in multi-tenant cloud environments.
Memory remanence: Even after power-off, data may persist in GPU memory modules, allowing physical attackers to extract information.

Attacks on Attestation and Secure Boot:

Fake attestation: If the attestation process is compromised, attackers can present a malicious environment as secure.
Secure boot bypass: Exploiting flaws in the secure boot process to load unauthorized firmware or drivers.

Multi-Tenancy and Noisy Neighbor Attacks:

Cross-VM attacks: In cloud environments, attackers may attempt to infer or access data from other VMs sharing the same GPU.
Denial of service: Malicious tenants may exhaust GPU resources, impacting the availability or performance of other workloads.

Research and Case Studies:

"Vulnerabilities in GPU Memory Management" (2016): Demonstrated that GPU memory can persist across jobs, leaking sensitive data.
"Practical Timing Side Channel Attacks against GPU Accelerated Applications" (2020): Showed that attackers can infer neural network architectures and data by measuring execution times on shared GPUs.
NVIDIA Security Bulletins: Regularly report vulnerabilities in drivers and firmware, some of which could be leveraged in cloud GPU environments.

Mitigations and Best Practices

Keep firmware and drivers up to date.
Use attestation to verify the integrity of the GPU environment.
Limit the attack surface by disabling unnecessary features and APIs.
Enforce strong hardware-enforced partitioning and encrypted memory.
Avoid co-locating sensitive workloads with untrusted tenants.
Monitor for anomalous behavior, such as unusual memory access patterns or failed attestation attempts.
Log and audit all access to GPU resources.
Choose cloud providers with strong confidential computing guarantees and request attestation reports for sensitive workloads.

Conclusion

Confidential computing for GPU clusters in the cloud is a major step forward for data-in-use security, but it is not an elixir. Attackers continue to innovate, targeting both hardware and software layers. As NVIDIA’s Hopper and Blackwell architectures bring confidential computing to accelerated workloads, understanding and mitigating new attack vectors is crucial. Organizations must stay vigilant, keep systems updated, and adopt best practices to protect sensitive data in the cloud era.

References

NVIDIA Product Security
Naghibijouybari, M., et al. "Practical Timing Side Channel Attacks against GPU Accelerated Applications." 2020.
"Vulnerabilities in GPU Memory Management." 2016.
NVIDIA Hopper Architecture Whitepaper:
NVIDIA Blackwell Architecture Overview:

Permalink

Can AI be an actionable communicator for code scanning?

Shasheen Bandodkar — Mon, 07 Jul 2025 07:00:00 +0000

New critical vulnerabilities light up your scanners, and if you’re in security, you probably watch developers dismiss your carefully crafted alerts with the same enthusiasm as spam emails. Security teams are often overwhelmed with security data but starved for effective security communication. The codebase is scanned with an army of code-scanning tools, but the result is always a growing disconnect between the people of find security issues and the people who need to fix them.

But what if AI could step in, not as a tool that generates more alerts but as a translator that helps bridge the gap between security findings and developer actions?

The Communication Crisis

The security multi-tool chain has gotten way out of hand. Each tool speaks its own language. Here’s a Trivy vulnerability:

{
  "VulnerabilityID": "CVE-2023-44487",
  "Severity": "HIGH", 
  "InstalledVersion": "2.4.5",
  "FixedVersion": "2.4.7",
  "Title": "HTTP/2 Rapid Reset Attack",
  "Description": "The HTTP/2 protocol allows a denial of service...",
  "References": ["https://nvd.nist.gov/vuln/detail/CVE-2023-44487"]
}

Even though this alert is technically accurate, it leaves developers with critical questions such as:

How does this affect my application?
What’s the business impact?
Where exactly should I fix this?
What’s the remediation priority relative to the current sprint?

On top of that, the false positive problem is always frustrating, which means roughly half of the critical alerts are not actually critical. It’s like the smoke detector went off, every time you slightly burnt your toast.

Developers are often problem-solvers, they want to fix things, but without context and an explanation of the fix, it’s not really actionable. They do not want to be spending an hour researching about the security alert or whether it is legitimate or not. They want to know whether the vulnerability is real. Can it be fixed quickly? What would happen if ignored?

How AI Can Transform Security Communication

Code Aware Contextual Analysis: AI does not look for an isolated finding, it would index your entire codebase and its entire context.

Traditional Scanner Output:

CWE-89: SQL Injection
Severity: HIGH
Location: src/controllers/UserController.php:67

AI’s Contextual Analysis Process:

// AI examines the actual vulnerable code:
public function login(Request $request) {
    $email = $request->input('email');
    $password = $request->input('password');
    
    // Line 67 - VULNERABILITY: Direct string concatenation
    $user = DB::select("SELECT * FROM users WHERE email = '$email' AND password = '$password'");
    
    if ($user) {
        // Login successful
        return redirect('/dashboard');
    }
}

AI then checks:
1. Is user input directly concatenated? (YES - major red flag)
2. Are there any input validation rules? (checks Request validation)
3. Is this endpoint public? (checks routes and middleware)
4. What's the team's usual database pattern? (looks for existing safe patterns)
5. How critical is this system? (analyzes business context)

AI’s Enhanced Communication (Enhanced PR Comment Style Example):

🛡️ Security Alert: SQL Injection Vulnerability Detected

🔴 CRITICAL SECURITY ISSUE

File: src/controllers/UserController.php
Line: 67
Issue: Direct string concatenation in SQL query

🎯 Vulnerability Analysis

// ❌ VULNERABLE CODE (Line 67):
$user = DB::select("SELECT * FROM users WHERE email = '$email' AND password = '$password'");

⚠️ Risk Assessment:

Endpoint: /login (public-facing, no authentication required)
Input validation: None found in LoginRequest
Data exposure: Full user database including passwords
Attack vector: ' OR '1'='1 bypasses authentication
Impact: All 50,000+ registered users at risk

🔧 Recommended Fixes

🚀 Option 1: Quick Fix (5 minutes)

// ✅ Use parameterized queries:
$user = DB::select(
    "SELECT * FROM users WHERE email = ? AND password = ?", 
    [$email, $password]
);

⭐ Option 2: Best Practice (10 minutes) - Matches your team's pattern

// ✅ Use Eloquent ORM (your usual approach):
$user = User::where('email', $email)
            ->where('password', $password)
            ->first();

🏆 Option 3: Complete Solution (30 minutes)

// ✅ Secure authentication with validation:
// Add LoginRequest validation + use Auth::attempt()

📊 Team Context

Based on your codebase analysis, I see you prefer Eloquent ORM in PaymentController and OrderController. Option 2 follows your established patterns.

🎯 Action Required

Choose fix approach above
Test with malicious input: admin@test.com' OR '1'='1
Consider adding rate limiting for login attempts

Priority: 🔴 HIGH - Authentication bypass affects all users

🤖 AI Security Assistant • [Fix with Option 2] [Show me complete solution] [Learn about SQL injection]

The AI would provide specific, runnable code fixes based on the tech stack. However, this is not just about adding AI to your tech or security stack, it is more about fundamentally reimagining how security and development teams collaborate.

The New Three-Way Handshake: AI, Security Engineers, and Developers

Before AI, security engineers would spend their time writing generic vulnerability reports that developers often ignore or misunderstand. Developers get frustrated with unclear, irrelevant alerts and start dismissing security findings altogether. It becomes an adversarial relationship where security "blocks" development.

Traditional workflows would consist of: Security Tool → Generic Alert → Security Engineer → Email Report → Developer → ¯\_(ツ)_/¯

With AI, now security engineers and developers have a new collaborative workflow:

              Security Engineer
            (Strategy & Training)
                ↗          ↖
             📚              🎯
          ↙                     ↘
   AI System      ←  😊  →     Developer
  (Translation &              (Implementation
   Learning)                   & Feedback)

Security Engineers become AI Trainers: Instead of spending hours writing vulnerability descriptions, security folks become strategic coaches. The security engineer configures the AI context. Let human oversight step in to handle complex escalations.

Developers become Security Partners: Instead of being passive recipients of security alerts, developers become active participants in the security process and workflow. They provide the AI, the context of the codebase patterns, and their implementation, and are proactive with security contributions.

AI becomes the Intelligent Transition Layer: AI is the bi-directional bridge that is in a continuous feedback loop, maintaining accuracy by building trust and culturally transforming the workflow where security engineers stop being the team that says “NO”, and developers start thinking about security proactively instead of reactively and AI is the facilitator of collaboration instead of friction.

The technology to make this happen exists today. The scanning tools today have integrated AI but provide no context. What is needed now is the will to put this together in ways that prioritize human relationships along with the technical aspect. The organizations that figure this out quickly will have more productivity, a better security posture, and will build a culture of enablement.

Permalink

How to Evaluate Your Next Company?

Shasheen Bandodkar — Mon, 09 Jun 2025 07:01:00 +0000

During a job search, it’s easy to get caught up in the whirlwind of technical questions, compensation packages, and team vibes, leaving little room to evaluate the company itself. Yet, this step can make or break your career happiness and growth. It’s crucial to assess your next opportunity from a business aspect.

The Trap: Where We Lose Focus

When hunting for a job, most of us zero in on a few key priorities:

Coding and Design Questions: You’re grinding coding questions or perfecting system design to ace interviews.
A Good Salary: Who doesn’t want a good paycheck that reflects their worth?
Team and Environment: You’re looking for smart colleagues and exciting challenges.

But the catch: these are only part of the picture. We often neglect the bigger questions about the company’s health and future. Sometimes, you might feel you don’t have a choice. One decent offer comes along, and you grab it. However, as you grow in your career, settling without scrutiny can cost you more than you think.

Why Evaluating a Company Is Critical

Early in your career, any job might feel like a win as long as it offers experience or pays the bills. But as you gain seniority, it’s not just about solving problems or writing code, it’s about joining a company where you can thrive long-term. A poor choice could mean stagnation, instability, or a work environment that drains you. On the flip side, a well-evaluated company can boost your career, align with your goals, and even offer financial upside (hello, equity!). So, how do you dig deeper, especially with startups and mid-sized companies?

Key Factors You Should Consider

1. Risk Assessment: High Risk, High Reward

Every company carries some level of risk, especially startups. Joining one could mean big rewards, think equity windfalls or rapid career growth if they succeed. But on the flip side? Many don’t make it.

Ask yourself:

How much risk can I handle?
Am I okay with the chance of job-hunting again if things go south?

If you’re risk-averse, a stable, established company might suit you better. If you’re ready to roll the dice, dig into the details below.

2. Evaluation Criteria to gauge a company’s potential, focus on these areas:

a. Revenue and Revenue Growth Rate

Is the company making money? More importantly, is the revenue growing? Look for signs of financial health:

Are they acquiring new customers?
Who’s investing in them, and why? Big-name VCs might signal confidence, but dig into their motives.

This information isn’t always public, especially for startups. You might need to sleuth—check press releases, ask subtle questions in interviews, or tap your network for insights.

b. Market Expansion Opportunities

Is the company in a growing market? A product that solves a real problem and scales easily has a better shot at success. Consider:

Does their solution fit seamlessly into customers’ lives?
Is there room for them to expand?

For example, a startup with a clunky onboarding process might struggle to grow, while one with a user-friendly product could take off.

c. Partnerships and Customer Feedback

Who’s working with the company? Strategic partnerships can signal strength. More crucially, what do customers think?

Are they loyal customers or grudging users?
Does the product solve a genuine problem?

If you can, test the product yourself or hunt for reviews. Happy customers often mean a healthier company.

d. Competition

Where does the company stand in the market?

Are they a leader, a contender, or lagging behind?
What’s their unique value proposition (UVP)? A strong, defensible UVP like proprietary tech can set them apart.

Compare them to competitors. If the #3 player is nipping at their heels, how are they staying ahead?

The Ripple Effect of a Struggling Company

If these factors aren’t solid, the cracks will show up in your workday

Projects Losing Funding: That exciting initiative you joined for? Suddenly shelved.
Frequent Re-orgs: Constant shuffling means chaos and unclear goals.
Tightened Spending: Budget cuts can kill perks, tools, or even headcount.
Talent Attrition: When the best people leave, morale and momentum tank.
General Dissatisfaction: A shaky company breeds frustration and burnout.

These aren’t just annoyances, they’re career roadblocks.

Conclusion

Choosing your next company isn’t just about the role or the paycheck, it’s about betting on a place that supports your growth and sanity. By weighing risks, digging into revenue, market potential, customer sentiment, and competition, you’ll spot the winners from the wobblers. Don’t be afraid to ask hard questions during interviews, good companies will respect it. If an offer doesn’t check your boxes, keep searching. Your career’s worth it. Next time you’re job hunting, evaluate the company as much as they evaluate you. You’ve got this!

Permalink

How Should You Prioritize Product Security?

Shasheen Bandodkar — Mon, 02 Jun 2025 09:08:00 +0000

Product security presents a formidable challenge due to It’s vast, dynamic, and constantly shifting tendency that can be both exciting and daunting.

1. Navigating the Vastness of Product Security

Product security is not a singular, manageable task. It’s a sprawling, multifaceted discipline that can feel overwhelming. With new threats emerging daily and with an endless list of potential vulnerabilities, it is easy to get lost. Prioritization is not merely helpful, it is essential !

Why Prioritization Matters:

Time, budget, and resources are always finite. If they were infinite I would not be writing this blog! It is not possible to secure everything at once and therefore, it is crucial to focus on the areas that have the greatest impact on your product’s safety and user trust.
The security landscape is constantly evolving. A vulnerability that may be low-risk today could be critical tomorrow. Prioritization is not a one-time decision; it is a living process that adapts to new risks and realities strategically.
Think of it like tending a garden: you cannot water every plant equally every day, but you can focus on the ones that need it most based on the weather and soil conditions.

2. Exploring the Domains of Product Security

To prioritize product security effectively, it is vital to understand the various domains involved. Product security spans multiple domains, each with its own unique challenges and stakes. Each domain is a component of the overall system. The key is identifying the most critical components for your product based on its risks and user requirements. A summary of the key areas and their significance:

Application Security: Application security encompasses safeguarding the software itself through rigorous code reviews, adherence to secure coding practices, and the utilization of tools such as Static Application Security Testing (SAST) to identify vulnerabilities in code and Software Composition Analysis (SCA) to manage risks associated with third-party libraries. Prioritizing application security is crucial as compromised code often serves as an entry point for malicious actors.
Network Security: Protecting the infrastructure supporting the product is paramount. It involves employing firewalls, intrusion detection systems, a secure network architecture, and regular network and host scanning to identify potential vulnerabilities. The failure of the network can have cascading effects on the entire system.
Data Security: Safeguarding data is paramount, whether stored in databases or transmitted across the internet. Encryption, access controls, and data loss prevention measures are vital, particularly for products handling sensitive information.
Identity and Access Management (IAM): Defining and enforcing access controls is critical to prevent unauthorized access. Strong authentication mechanisms, such as MFA, and stringent permissions are essential. Regular audits further enhance security measures.
Vulnerability Management: Proactive vulnerability management involves systematically identifying and addressing weaknesses before malicious actors exploit them. This includes conducting penetration testing to simulate attacks, participating in bug bounty programs to crowdsource vulnerability discovery, and employing continuous scanning for known issues.
Infrastructure as Code (IaC) Scanning: Modern product often relies on IaC for deployment. Scanning these configurations ensures that no security vulnerabilities, such as open ports or weak permissions, inadvertently enter the infrastructure.
Compliance and Regulatory Requirements: Regulations vary by industry and region, specifying what must be prioritized. Ignoring them is not an option in regulated fields such as healthcare or finance.
Incident Response and Recovery: In the event of an incident, a plan to detect, respond, and recover is essential. Prioritizing this ensures that damage is minimized and recovery is swift.

3. Can Tooling Truly Assist?

Tools are prominent in the security industry, promising to enhance efficiency, speed, and safety. However, are they the ultimate solution?

Advantages of Tools:

Efficiency: Automated scans or compliance checks save time, allowing teams to focus on strategic aspects.
Consistency: Tools maintain consistency in applying rules consistently, eliminating human errors.
Scalability: As products grow, tools can adapt effectively, surpassing human capabilities.

Limitations of Tools:

False Alarms: Tools may generate numerous urgent alerts that turn out to be false, leading to unnecessary concerns.
Blind Spots: Tools lack understanding of product nuances and context, potentially flagging legitimate features as vulnerabilities.
Over-reliant risk: Over-reliance on tools can create a false sense of security, disregarding potential vulnerabilities.

The Human-Tool Partnership: Treating Tools as Complementary Partners

Tools are most effective when utilized as complementary partners to human judgment. A human expert, deeply familiar with the product, is essential to determine the significance of identified vulnerabilities. For instance, a scanning tool may detect a potential SQL injection flaw, but it requires human confirmation to assess its exploitability within the application and environment.

4. Communication Improvement: Bridging the Gap Between Security and Engineering

Historically, security and engineering teams operate in distinct silos, driven by divergent objectives and communication challenges. While there has been gradual progress in improving collaboration, there remains ample room for enhancement.

Challenges:

Clashing Priorities: Engineering teams prioritize rapid feature delivery, while security teams advocate for a more cautious approach to security measures. This tension is inherent to the nature of these roles.
Jargon Barrier: Security terminology, such as “zero-day exploit,” may be incomprehensible to developers focused on meeting deadlines.
Lack of Shared Vision: Without aligned goals, each team operates independently.

Improvement Strategies:

Shared Goals: Establish common metrics, such as a reduction in high-risk bugs by 20%, serves as a guiding principle for both teams.
Regular Check-Ins: Implement weekly security-engineering check-ins where security personnel present new threats, and engineering teams share challenging deadline-driven projects. These interactions foster trust and mutual understanding.
Knowledge Exchange: Security professionals should attend sprint planning sessions, and engineers should receive training on secure coding practices. Knowledge exchange enhances empathy and collaboration.

Start small and then grow objectives in scale and confidence

Security Champions: Appoint security-savvy engineers within each development team to facilitate communication and advocate for security best practices.

Empathy: Key to Effective Collaboration

Empathy plays a pivotal role in fostering collaboration. Security teams often face the pressure of meeting release deadlines, while engineering teams may be concerned about the potential impact of seemingly minor flaws on the product’s success. By creating a sense of understanding and shared responsibility, both teams can prioritize tasks more effectively.

5. Prioritizing the Product’s Well-being

Security is not merely an abstract concept; it is a fundamental aspect of protecting the product and its users. Prioritization should commence from the outset.

Identifying Risk Profiles: Different products, such as banking applications and gaming applications, have distinct priorities. For instance, a banking application’s primary concern may be data breaches, while a gaming application’s focus might be on preventing cheating. By mapping the risks associated with each product, organizations can allocate their efforts strategically.

Integrating Security into the Product’s Development Process

Security should not be an afterthought; it should be an integral part of the product’s development process. This includes designing security mechanisms from the ground up, implementing secure coding practices, and conducting continuous testing throughout the deployment lifecycle.
Prioritizing User Safety and Trust

The primary objective should be to ensure the safety and trustworthiness of users. Features such as multi-factor authentication should be prioritized over flashy but less critical features. A security breach can have a more significant impact on users than a delayed update.

6. Enhancing Prioritization with Additional Considerations to further strengthen prioritization, organizations should implement the following strategies:

Building a Security Culture: Security is not solely the responsibility of the security team; it should be a shared concern among all employees at an organization. Organize workshops, celebrate successful security fixes, and make security an integral part of the company’s culture. When junior developers feel comfortable reporting flaws, it creates a positive, collaborative and successful environment.
Leadership by Example: Executives should treat security as a critical aspect of the company’s operations. If security is perceived as a “nice-to-have,” it will likely be neglected and at a certain aspect act as a hinderence. Leaders must allocate sufficient resources, raise awareness about security, and link it to the product’s success. For instance, a CEO who asks, “How secure is this product release?” demonstrates a commitment to the company’s security goals.
Maintain Curiosity and Adaptability: The threat landscape is constantly evolving, with ransomware emerging as a current concern and AI-driven attacks poised to becoming a present challenge. To effectively manage this situation, it is crucial to remain vigilant and adaptable.

Stay Informed and Prioritize: Subscribe to relevant security newsletters to stay abreast of the latest developments. This proactive approach can help you prioritize security measures effectively.

7. Empathy: The Foundation of Effective Prioritization

Empathy is not a weakness; it is a strategic asset that underpins effective prioritization.

For Engineering Professionals: Security professionals should prioritize tasks based on their urgency and impact on the product’s functionality. They should focus on delivering quick fixes rather than comprehensive overhauls. Change needs to be gradual, not immediate.
For Security Professionals: Security professionals should consider the potential impact of major and minor bugs on the product’s reputation and public image. They should proactively address these issues to prevent potential crises.
For Users: Every decision should be guided by the principle of ensuring the safety and well-being of users. A secure product is not just compliance checkbox, it is a commitment to protecting users’ data and privacy.

Conclusion: Prioritization as an Art Form

Prioritizing product security is a complex balancing act that requires careful consideration of various factors, including domain expertise, tools, teams, and the product’s overall objectives. By cultivating empathy, fostering a strong organizational culture, and maintaining a clear focus on critical security concerns, organizations can transform the vastness of security into a powerful force that safeguards their products and users.

Permalink

Building Agent-Bando: Learning The Inner Workings with Open-Source LLMs

Shasheen Bandodkar — Mon, 26 May 2025 07:00:00 +0000

https://github.com/Shasheen8/agent-Bando

This project was all about learning how AI models behave, from a security perspective. Agent Bando is a lightweight Flask-based web app I built to query Common Vulnerabilities and Exposures (CVEs) like CVE-2025-30400 and generate dynamic tables and AI-powered summaries, with open-source large language models (LLMs) to craft a partial SOC assistant, diving deep into prompt tuning and cost implications from a security perspective

Agent Bando is a lightweight web tool for SOC analysts to fetch CVE details fast. Type a CVE ID (e.g., CVE-2024-6387), and it delivers:

Dynamic Table: Displays Severity, Impact, Affected Products, MITRE ATT&CK Techniques, and more, with handy tooltips.
AI-Generated Summary: A Markdown-rendered report covering:
- Vulnerability description and attack vector
- Severity and exploit details
- Affected products (e.g., Cisco IOS XE, Juniper Junos OS)
- MITRE mappings, threat actors, bug bounties, and SOC actions

The app runs on Flask, with agent.py handling LLM queries, main.py serving the UI, index.html rendering the interface, style.css adding polish, and logger.py logging to agent_bando.log. It’s a simple setup, but it’s a playground for AI experimentation.

Why Together AI?

Together, powers the backend AI muscle. Here’s why it’s awesome:

Open-Source Model Zoo: Hosts models like Llama-4-Maverick-17B and DeepSeek V3-0324, perfect for testing without heavy infrastructure.
Blazing Fast: CVE queries return in seconds, keeping the UI snappy.
Budget-Friendly: Competitive pricing lets me experiment without draining my wallet.
Simple API: Using together, I hooked up model calls in agent.py with a TOGETHER_API_KEY in .env.
Model Switching: Toggling between Llama-4 and DeepSeek was a one-line change.

Together AI made it easy to focus on prompt tuning and cost analysis, not server wrangling. It’s a game-changer for AI-driven security projects!

Llama-4-Maverick-17B vs. DeepSeek V3-0324: The Experiment

Meta Llama-4-Maverick-17B-128E-Instruct-FP8

Pros: Its mixture-of-experts architecture shines for detailed text and image understanding. Summaries were verbose, with rich MITRE mappings and threat actor insights, especially with larger prompts (max_tokens=2000).

Cons: Slower inference and higher output token costs. Smaller prompts (max_tokens=1000) sometimes cut off key sections.

Output Example (for CVE-2017-0144): Check the image above

Cost Breakdown: Rough Calculation

Pricing: $0.27/1M input tokens, $0.85/1M output tokens.

Standard Query (500 input tokens, 1000 output tokens):
- Input: (500 / 1M) * $0.27 = $0.000135
- Output: (1000 / 1M) * $0.85 = $0.00085
- Total: ~$0.000985 (~0.1 cents/query)
- 1000 queries: ~$0.985
Larger Prompt (1000 input tokens, 2000 output tokens):
- Input: (1000 / 1M) * $0.27 = $0.00027
- Output: (2000 / 1M) * $0.85 = $0.0017
- Total: ~$0.00197 (~0.2 cents/query)
- 1000 queries: ~$1.97

Deepseek/DeepSeek-V3-0324

Pros: Faster inference and concise summaries, great for quick SOC queries. Reliable JSON output for tables, even with smaller prompts.

Cons: Less detailed summaries, sometimes skipping threat actors or news. Larger prompts improved output but at a higher cost.

Output Example (for CVE-2017-0144): Check the image above

Cost Breakdown: Rough Calculation

Pricing: $1.25/1M tokens (input and output).

Standard Query (500 input tokens, 1000 output tokens):
- Input: (500 / 1M) * $1.25 = $0.000625
- Output: (1000 / 1M) * $1.25 = $0.00125
- Total: ~$0.001875 (~0.19 cents/query)
- 1000 queries: ~$1.875
Larger Prompt (1000 input tokens, 2000 output tokens):
- Input: (1000 / 1M) * $1.25 = $0.00125
- Output: (2000 / 1M) * $1.25 = $0.0025
- Total: ~$0.00375 (~0.38 cents/query)
- 1000 queries: ~$3.75

Prompt Tuning and Costs - $1 Starting Credit

Small Prompts: Early on, I used max_tokens=1000, but summaries were truncated (e.g., missing Threat Actors). Costs were low (~0.1 cents/query for Llama-4), but output quality suffered.
Larger Prompts: Bumping to max_tokens=2000 in agent.py completed summaries, doubling output token costs (e.g., $0.0017 for Llama-4, $0.0025 for DeepSeek). With testing max_tokens=3000 for Llama-4 to leverage its verbose strengths, expecting ~$0.0028/query.
Optimization: I tightened prompts to request concise JSON and summaries, cutting output tokens by ~20% (e.g., from 1000 to 800). Logging token counts in agent_bando.log helped in balancing cost and quality.
Key Insight: Llama-4’s lower output token cost ($0.85 vs. $1.25) makes it cheaper for large prompts, critical for security apps needing detailed outputs.

For a SOC running 10,000 queries monthly, Llama-4 costs ~$9.85-$19.70 (depending on prompt size), while DeepSeek runs ~$18.75-$37.50. Llama-4’s cost edge and richer outputs make it tempting for Agent Bando’s next phase of testing and building.

Why I Built Agent Bando

Agent Bando was an experiment to explore AI models through a security lens. SOCs drown in CVE data, and I wanted to see if LLMs could simplify analysis while learning:

Prompt Tuning: How crafting precise prompts (e.g., Markdown + JSON) affects output quality and cost.
Cost Implications: How token sizes impact budgets, crucial for scaling AI in security.
Model Behavior: How models like Llama-4 and DeepSeek handle structured security data.

This wasn’t about testing security features like prompt injection (that’s next!). Instead, the focus was on using AI to summarize CVEs, map MITRE techniques, and suggest SOC actions. Every prompt tweak or model switch was a lesson for me about AI’s potential and pitfalls in security contexts. Agent Bando’s simplicity belies its value as a learning tool.

Next Steps for Agent Bando

Test Security Features: Experiment with prompt injection to probe LLM vulnerabilities, ensuring Agent Bando’s outputs are secure. (DeepSeek will probably be a good model for this)
Integrate Tools: Connect to production data (e.g., SIEM, EDR, MDM, Vuln Mgnt logs, asset inventories) for context-aware CVE insights
Enhance UI: Add CVE autocomplete, a summary export button, or a dark mode for SOC night owls.
Optimize Costs: Fine-tune prompts further and test Llama-4 with max_tokens=3000 to maximize detail without breaking the bank. (Inference Testing)

Try It

GitHub Repository: https://github.com/Shasheen8/agent-Bando

Try It: Clone, set up your TOGETHER_API_KEY, and query CVEs at http://localhost:5001.

Together AI’s open-source models made it easy to experiment, and comparing Llama-4 and DeepSeek taught me how to balance prompt size, cost, and output quality (Inference).

Permalink

Building a Vulnerability Disclosure Program

Shasheen Bandodkar — Mon, 19 May 2025 07:00:00 +0000

If you're company's online presence is in the form of a website, app, or infrastructure, keeping it safe and secure is a big deal. A vulnerability disclosure program does this exact thing, i.e, A bug bounty program. The program focuses on checking weak spots before people who cause trouble create chaos.

Why Is a Vulnerability Disclosure Program Required?

A VDP is a proactive approach to protect users and data, safeguard brand reputation, and mitigate risks.

Proactive Risk Mitigation: Threats evolve as technology rapidly evolves. A VDP enables organizations to identify and fix vulnerabilities before malicious actors exploit them, reducing the likelihood of data breaches or service disruptions.
Building Trust with Users: A VDP ensures commitment to security through a transparent structure, organizations foster trust across customers, partners, and stakeholders. Publicly or privately acknowledging the contributions of ethical hackers reinforces this trust.
Leveraging the Security Community: The cybersecurity community possesses a huge talent pool of security researchers and ethical hackers (White-hat) with diverse skills and perspectives. A VDP taps into this expertise, providing insights that internal teams might overlook or not be able to prioritize.
Compliance and Regulatory Alignment: Organizations and industries, once they reach a certain scale, are subject to regulations (e.g., GDPR, CCPA, or PCI DSS) that demand robust security practices. A VDP enables organizations to meet these requirements by systematically addressing vulnerabilities.
Cost-Effective Security: An effective VDP significantly minimizes the outcome of a breach occurring. A long-term and synchronized provision ensures cost-effective measures against a probable breach.
Reputation Management: A well-managed and structured strategy signals an organization prioritizes security, enriching its reputation. Contrarily, ignoring vulnerabilities can damage credibility.

Key Components of a Vulnerability Disclosure Program

Establishing a Vulnerability Disclosure Program requires a multi-aspect focus, which includes: planning, strategy, prioritization, execution, and communication.

1. Purpose Statement

A clear purpose effectively dictates and buys stakeholder and leadership buy-in, inherently setting the tone and aligning with the organization's mission and values.

Articulate Commitment: Highlight the organization's dedication to securing assets and user/customer trust.
Encourage Collaboration: Invite ethical hackers and security researchers to contribute responsibly.
Define Program Goals: Highlight goals like reducing risks, protecting user data, and improving platform/product/enterprise security.

2. Requirements for a VDP: Addressing the requirements of a VDP:

a. Leadership Buy-In

Secure support from execs and stakeholders through effective communication and risk-based analysis.
Educate leadership on the advantages of a VDP, such as risk reduction, cost benefits in the long term, and enhanced trust across customers.

b. Dedicated Security Team

You would require a dedicated team for this program. This team can also be a one-person team, but the number may need to increase as the company scales.
The team would be responsible for tasks such as triaging reports, communicating with researchers, coordinating fixes, automations, etc.
Ensure the team has expertise in vulnerability assessment and remediation.

c. Legal Framework

Develop a Safe Harbor (VDP) policy to protect researchers who act in good faith from legal repercussions.
It would require buy-in and guidance from legal counsel, security, and leadership to ensure compliance with laws and regulations.

d. Reporting Platform

Choose a platform for receiving and managing vulnerability reports (e.g., HackerOne, Bugcrowd, or an in-house solution). If you're starting, you will likely require an external platform.
Provide clear instructions for submitting reports, including required details like vulnerability description, affected assets, and proof-of-concept (PoC). These instructions will be hosted on your company's site and made publicly visible.

e. Response SLAs

Define Service Level Agreements (SLAs) for acknowledging and resolving reports (e.g., acknowledge within 48 hours, resolve critical issues within 7 days).
Communicate SLAs to researchers to set expectations.

f. Bug Bounty (Optional)

Choose whether to offer monetary rewards for valid reports. If offering bounties, define reward tiers based on vulnerability severity (e.g., $100 for low, $10,000 for critical) based on company thresholds.
Ensure transparency in the reward process to maintain researcher and community trust.

3. Defining the Scope

The scope of a VDP outlines which assets, environments, and vulnerability types are eligible for testing and reporting. A clear and well-defined scope prevents perplexity and ensures researchers focus on relevant areas.

a. In-Scope Assets

Web Applications: Include domains and subdomains owned by the organization (e.g., *.example.com).
Mobile Applications: Specify iOS and Android apps, including app store IDs for clarity.
APIs: Include endpoints used for communication between the platform and users.
Infrastructure: Cover cloud-based infrastructure supporting services.

Example In-Scope Assets:

Web: Production: *.example.com (Critical), Testing: *.example.xyz (High)
Mobile: Example iOS App (App Store ID: 123456), Example Android App (Play Store ID: com.example.app)
APIs: All public-facing API endpoints
Infrastructure: Example-owned AWS/GCP resources (EC2, VPC, etc)

b. Out-of-Scope Assets

Exclude assets not owned or controlled by the organization (e.g., third-party services, cloud providers).
Prohibit testing on non-production environments (e.g., dev/staging) or user-generated content.
Clearly list out-of-scope domains (e.g., blog.example.com, shop.example.com).

Example Out-of-Scope Assets:

Third-party services: analytics.example.com, paymentprocessor.com
Non-production environments: dev.example.com, test.example.com
User-generated content: reviews, listings, or images

c. Accepted Vulnerability Types:

Some reference frameworks to use: OWASP TOP 10, MITRE, NIST, CIS, etc

Authentication/Authorization: Broken authentication, session flaws, or improper access controls.
API Security: Insecure endpoints, improper validation, or data exposure.
Web Vulnerabilities: XSS, SQL Injection, CSRF, SSRF, or directory traversal.
Mobile Security: Insecure data storage, hardcoded secrets, or lack of TLS.
Sensitive Data Exposure: Leaking PII, financial data, or unauthorized account access.
Security Misconfigurations: Default credentials, unpatched software, or vulnerable libraries.
Business Logic Flaws: Exploitable transaction or platform logic.

d. Out-of-Scope Vulnerability Types

Low-impact issues: Missing HTTP headers (e.g., HSTS, CSP) without demonstrable impact.
Informational issues: Software version disclosure, descriptive error messages.
Prohibited attacks: DoS/DDoS, brute-force, or automated scans.
Non-exploitable issues: Clickjacking on non-sensitive pages and open redirects without impact.

Example Out-of-Scope Vulnerabilities:

Missing best practices (e.g., SPF/DKIM/DMARC, HttpOnly cookie flags)
Vulnerabilities requiring outdated browsers or unlikely user interaction
Public zero-day vulnerabilities patched within the last 30 days

4. Rules of Engagement

Rules of engagement ensure responsible testing and protect both the organization and researchers. It includes:

Prohibited Actions:
- Do not create fake accounts or fraudulent content on production systems.
- Avoid DoS/DDoS attacks or tests that disrupt services.
- Do not access or modify user data without consent.
- Prohibit public disclosure of vulnerabilities before resolution.
Permitted Actions:
- Create test accounts on designated environments (e.g., sandbox.example.com) with specific naming conventions (e.g., hacker-username).
- Delete test accounts after testing.
- Use test accounts for research without impacting real users.
Reporting Guidelines:
- Submit reports via the designated platform with detailed information (e.g., PoC, screenshots, impact).
- Include attack scenarios and risk assessments to aid triage.
- Abide by applicable laws and regulations.

Example Naming Convention:

For testing on sandbox.example.com, create accounts with the prefix "research-" (e.g., hacker-johnsmith). De-commission accounts after testing.

5. End-User Engagement

Effective engagement and communication with researchers and the broader community are critical to a VDP's success. It builds and harbors trust, encourages participation, and ensures smooth collaboration (present and future).

a. Clear Communication

Publish a detailed VDP policy on a publicly accessible webpage (e.g., example.com/security).
Provide contact information for inquiries (e.g., security@example.com). Helps with private disclosures
Use simple, accessible language to describe the program, scope, and rules.

b. Streamlined Reporting Process

Offer a user-friendly reporting platform with clear submission guidelines.
Require specific details in reports, such as:
- Vulnerability description
- Affected asset(s)
- Steps to reproduce
- Impact and risk assessment
- PoC, screenshots, or videos
- Timelines
Acknowledge reports promptly (e.g., within 48 hours) and provide updates on resolution progress.

c. Safe Harbor Assurance

It reassures researchers that responsible disclosures will not face legal action.

d. Recognition and Incentives

Acknowledge researchers' contributions through a public "Hall of Fame" or thank-you page. (Optional)
Offer clear reward tiers based on severity and impact, based on valid bug bounty reports.
Provide non-monetary incentives, such as swag or exclusive program invites. (Optional)

e. Community Engagement (Post Effective Successful VDP)

Participate in security conferences or webinars to promote the VDP.
Share success stories (anonymized if necessary) to highlight the program's impact.
Solicit feedback from researchers to improve the program.

6. General Steps for Successful VDP

To maximize the effectiveness of a VDP, consider these best practices:

Start Small and Scale: Begin with a limited scope (e.g., one domain) and expand as the program matures.
Iterate Based on Feedback: Regularly update the VDP policy based on researcher input and evolving threats.
Automate Triage: Use tools to filter out low-quality reports and prioritize critical issues.
Educate Internal Teams: Train developers and IT staff on secure coding and vulnerability remediation.
Monitor Program Metrics: Track metrics like report volume, resolution time, and bounty costs to assess performance.
Stay Transparent: Publicly disclose resolved vulnerabilities (with researcher consent) to demonstrate accountability.

Implementation Steps: Follow these steps to launch a VDP

Draft the Policy:
- Define the purpose, scope, rules, and Safe Harbor clause.
- Consult legal and security teams for approval.
Set Up Infrastructure:
- Choose a reporting platform (e.g., HackerOne, Bugcrowd, or email-based).
- Configure test environments (e.g., sandbox.example.com) for researcher access.
Publish the VDP:
- Create a dedicated webpage (e.g., example.com/security).
- Promote the program via blog posts, social media, and security forums.
Manage Reports:
- Acknowledge reports promptly and assign them to the security team.
- Validate vulnerabilities, coordinate fixes, and communicate with researchers.
Reward and Recognize:
- Issue bounties or non-monetary rewards for valid reports.
- Update the Hall of Fame or thank-you page.
Review and Improve:
- Analyze program performance and gather researcher feedback.
- Update the policy and scope as needed.

Challenges and How to Address Them

Challenge: Overwhelming report volume.
- Solution: Use automated triage tools and clearly define out-of-scope issues to filter low-quality reports.
Challenge: Researcher dissatisfaction with rewards or response times.
- Solution: Set clear expectations for SLAs and bounties. Communicate transparently during the triage process.
Challenge: Legal concerns from researchers.
- Solution: Provide a robust Safe Harbor policy and work with legal counsel to address third-party issues. (Focus on the fine-grained details)
Challenge: Internal resistance to fixing vulnerabilities. (Can be a separate blog in itself)
- Solution: Enlighten teams on the risks of unpatched vulnerabilities and prioritize fixes based on severity. (Can be a separate blog in itself)

Conclusion

A Vulnerability Disclosure Program is like having a team of friendly sherlocks keeping the organization's assets safe. It is a great way to be proactive, catch large and small-scale problems early, and make users/ customers happy by building trust and showing the world that the organization takes the safety of systems and data seriously. Defining a clear purpose, scope, and engagement strategy, organizations can addresses vulnerabilities and strengthen their security posture. Start small, iterate often, and engage transparently with researchers to build a program that delivers lasting value, and your VDP can become a cornerstone of your organization's security strategy.

References:

Permalink

Superman vs Batman - Leadership Styles in Security Engineering

Shasheen Bandodkar — Mon, 12 May 2025 07:17:00 +0000

Security engineering is a world of high stakes, and leadership is more than a title, it's the backbone of trust, decision-making, and resilience. In security engineering, moments like these don't just test your tech skills; they test your ability to lead. Leadership here isn't about a fancy title, it's stepping up, keeping calm, and guiding your team through the bedlam. To unpack what makes a great leader in this field, I will compare two legends: Superman, the bold, in-your-face hero (the symbol of hope), and Batman, the quiet, strategic genius (the silent guardian). These two styles, flashy vs. subtle, offer a lens to explore how we lead in the wild world of cybersecurity.

The Superman Leadership Style: The Visible Vanguard

What is the Superman Leadership Style?

Superman represents the leader who is always in the spotlight (you can't miss), think of a CISO during a breach, or a team lead establishing security policies. This style is characterized by:

High Visibility: The go-to person for updates when execs need answers and decisions.
Hands-On Approach: He is involved in day-to-day operations and crises, the nitty gritty.
Inspirational Presence: Energizes the team and promotes unity under pressure.

Positives of the Superman Style

Reliability Under Fire: Superman coordinates the response and team when a crisis on a pedestal, such as a ransomware attack, hits, ensuring clarity and calm.
Clear Vision: Articulates the "why" behind security efforts, giving the team purpose.
Team Morale Booster: Celebrates wins and shares credit, building a motivated, cohesive team.

Negatives of the Superman Style

Crushing Expectations: The pressure to be flawless is relentless—any misstep is magnified.
Burnout Risk: Constantly leading from the front, especially in 24/7 incident responses, can lead to exhaustion.
Tough Calls Backlash: Enforcing unpopular policies (e.g., mandatory two-factor authentication) makes Superman the target of resistance.

Granular Examples in Security Engineering

Incident Response Leadership: Superman leads the war room during a DDoS attack, directing traffic rerouting and updating stakeholders.
Policy Champion: Pushes for a zero-trust model, explaining its necessity to skeptical teams.
Training Advocate: Leads phishing awareness sessions, making security tangible for non-technical staff.

The Batman Leadership Style: The Strategic Shadow

What is the Batman Leadership Style?

Batman embodies the leader who operates with subtlety and foresight—think of a senior engineer designing security architecture or an analyst preempting threats. This style is defined by:

Strategic Focus: Prioritizes long-term planning over daily firefighting.
Behind-the-Scenes Impact: Work often goes unnoticed but is foundational to success.
Expert-Driven Influence: Commands respect through technical mastery, not loud proclamations.

Positives of the Batman Style

Strategic Foresight: Anticipates threats (e.g., supply chain attacks) and designs proactive mitigations.
Decisive Precision: Halts risky deployments (e.g., spotting an exploitable API) based on evidence, not ego.
Respect Through Results: Earns admiration from peers who witness the impact of their quiet, critical work.

Negatives of the Batman Style

Perceived Aloofness: Reserved demeanor can intimidate juniors, who may hesitate to seek help.
Undervalued Work: Preventing breaches through design rarely earns public praise, and contributions can be overlooked.
Misunderstood Intent: Insistence on rigor (e.g., rejecting rushed deployments) is an obstruction.

Granular Examples in Security Engineering

Security Architecture Design: Spends weeks mapping a microservices environment to prevent lateral movement in breaches.
Threat Modeling Mastery: Identifies a SQL injection risk in a third-party library before launch, averting disaster.
Post-Mortem Insight: Breaks down logs after an incident to propose long-term fixes and improvements, not just quick patches.

Leadership Beyond Titles: Everyone's a leader

In security engineering, leadership is not confined to a job title; every team member, from interns to architects, shapes outcomes through their actions and influence.

A granular example:

Superman Traits in a Newcomer: A junior engineer notices a spike in failed logins, escalates it, and leads a quick huddle to investigate.
Batman Traits in a Newcomer: Another junior master's penetration testing tools and flags a subtle XSS vulnerability during a code review.

How can you nurture these traits:

For Superman-Types: Assign them to present security updates or lead small projects to channel their initiative.
For Batman-Types: Pair them with mentors on complex tasks (e.g., reverse-engineering malware) to deepen their expertise.

Adaptability in Leadership: Blending Styles for Success

Why Adaptability Matters

Security engineering is unpredictable. A phishing campaign may demand Superman's urgency, while a cloud migration needs Batman's strategy. Rigid leaders will eventually falter; adaptable ones always thrive.

Quick adapatibility scenarios

Active Breach Response:
- Superman Mode: Leads the incident call, assigns tasks (e.g., "Isolate the server"), and updates the CTO/CISO.
- Batman Mode: Analyzes attack vectors post-crisis, designing new defenses (e.g., an email filter).
Project Planning:
- Superman Mode: Kicks off a penetration testing initiative with a clear goal: "Fin" every weak spot."
- Batman Mode: Maps the attack surface, prioritizing high-risk areas like public APIs.

How to Adapt Based on Situations

Leaders must read the room and situation. A Superman-style individual might step back during stable periods, letting Batman-types lead Research & Development. A Batman-style leader might step up during crises, offering clear directives.

The Stepping Up or Back Versatility

The Need for Flexibility

Over time, security engineers face moments requiring both styles. Versatility, knowing when to shine or strategize, defines great leaders.

Example:

Be Superman: During a zero-day exploit, lead a rapid patch deployment and reassure rattled executives.
Be Batman: When a key team member is out, quietly take over their vulnerability scanning duties without fanfare.

Building Trust Networks

Superman's Network: Relies on Batman for technical depth (e.g., consulting an encryption expert before pitching a policy).
Batman's Network: Builds allies across the team, ensuring their quiet wins (e.g., fixing a misconfiguration) are noticed by Superman-types.

Conclusion: Craft Your Leadership Legacy

Superman Excels in visibility, crisis leadership, and team unity, but must manage burnout and backlash.

Batman shines in strategy, foresight, and technical depth, but must bridge the gap to be seen and understood.

Blend and Adapt: The best leaders toggle between styles, meeting the moment's demands while nurturing their team's diversity.

Reflect on your style: Are you Superman, Batman, or a blend of both? Stretch yourself by embracing the strengths of each step up with bold action when urgency calls, or dive deep into strategy when foresight is needed. Encourage your team's Superman to strategize and Batman to speak up. Equally important, your leader should have the ability to step up and recognize your strengths, whether you're leading from the front or solving problems in the shadows. In security engineering, where threats never rest, versatility, collaboration, and recognition are your superpowers. Be the leader your team needs, boldly visible or brilliantly subtle, whenever the task or situation demands it.

Permalink

How to build a scalable IGA system?

Shasheen Bandodkar — Mon, 14 Apr 2025 06:59:00 +0000

Building a Scalable Identity Governance and Access Management

An IGA system ensures scalability, rapid deployment, and centralized governance. It consists of:

Central Configuration Hub: A tenant acts as the central unit, managing identity workflows, policies, and credentials. It standardizes automation, governance, and auditing for all applications, providing a unified view for oversight.
Virtual Appliance (VA): A cloud-based VA handles downstream API calls, connecting directly to SaaS apps. It executes account provisioning and de-provisioning via APIs, manual CSV uploads, or database integrations, ensuring flexibility for diverse systems.
User Portals: Manage workflows like birthright access and certifications while the VA operationalizes changes. For non-API systems, data is aggregated manually and routed to app owners via integrations like Jira, which are all tracked centrally in the tenant.
Connectors: These bridge the tenant to applications, enabling automation and visibility. Without them, governance becomes manual and error-prone:
- Direct Connectors: Pre-built APIs (e.g., for Google Workspace or AWS) sync data in real time (e.g., every 3 hours).
- Manual Connectors: For legacy apps, CSV or database uploads feed data to the VA for processing and task routing.
- Schema Definition: For consistency, define account attributes (username, ID) and entitlements (roles, groups) per source.
- Troubleshooting: Monitor VA logs for issues like aggregation failures (e.g., pagination loops) and tweak connector rules.

Automating Birthright Access

New hires need real-time, secure access to perform their roles without excess privileges. Birthright provisioning automates this process:

Source Integration: Connect your HR system (e.g., Workday or ADP) as the authoritative source via connectors or CSV uploads.
Role Mapping: Define birthright roles in the tenant based on HR attributes (e.g., department, job title); a developer might get read-only cloud access and email, while a manager gets broader permissions.
Automation: Workflows trigger provisioning upon identity creation, with the VA executing API calls (e.g., enabling SSO) or adding group memberships.
Validation: Audit logs confirm successful provisioning, alerting, and monitoring (e.g., integrated with SOAR tools) to catch failures.

Granular Access Control

Over-privilege is a critical security risk. Granular access control aligns with zero trust principles, reducing the attack surface:

Entitlement Schema: Define roles and groups per app via connectors (e.g., privileged roles vs. discretionary groups in collaboration tools).
RBAC Enforcement: Map entitlements to roles—data analysts might access specific cloud storage but not administrative functions.
Zero Trust: Require continuous authentication (e.g., MFA via push notifications) and device compliance (via MDM) before granting access.
Dynamic Policies: Use tenant rules to adjust access based on context, like distinguishing contractors from full-time employees.

Periodic Access Reviews

Entitlements drift over time—ex-employees or contractors might retain access unnecessarily. Periodic reviews ensure compliance (e.g., SOX, SOC2):

Connector Setup: Import account and entitlement data from all sources, auto-correlating accounts to identities.
Tagging: Flag sensitive entitlements (e.g., privileged: true, tagged for audits) for focused reviews.
Review Process: Automate reviews targeting specific criteria (e.g., source: "Collaboration Tool" AND privileged: true).

Approval Workflows

Balancing automation with human oversight, approvals enforce accountability:

Workflow Design: Configure approval steps in the tenant—managers greenlight standard access while security teams review privileged roles.
Integration: Sync with tools like Slack or Jira to track status.
Escalations: Set timeouts (e.g., 48 hours) to escalate unapproved requests to admins.
Audit Trail: Log all decisions for compliance reporting.

Swift Terminations

Prompt de-provisioning workflows on termination prevents orphaned accounts, especially for sensitive systems:

Trigger: An HRIS system signals termination (e.g., inactive status), kicking off the workflow.
Deprovisioning: The VA revokes access via APIs (e.g., disabling SSO, suspending accounts) or manual tasks for non-API systems.
Validation: Query inactive accounts (e.g., source: "Email Platform" AND status: Inactive) and alert on misses via SIEM.
Edge Cases: For role transitions (e.g., employee to contractor), retain specific access while revoking sensitive privileges.

Certifications for Compliance

Periodic or event-driven certifications (e.g., role changes) reduce privilege creep:

Campaign Setup: Launch quarterly reviews via the tenant.
Review Process: Managers or app owners approve or revoke access via the portal, triggering remediation tasks (e.g., Jira tickets).
Reporting: Track pending actions (e.g., action: Certification AND stage: Executing) with metrics.
Remediation: Automate revocation for denied access, with a manual follow-up tracked externally.

Edge Cases and Trade-Offs

No system is perfect, but here’s how to handle everyday challenges:

Pagination Loops: Misconfigured connectors can overload the system. Mitigate it with pre-processing rules and monitoring, balancing automation with stability.
Role Transitions: Customize workflows to preserve necessary access during shifts (e.g., employee to contractor), trading simplicity for flexibility.
Manual Delays: Set SLAs for non-API updates and alert on stale data, weighing flexibility against speed.
Vendor vs. Open-Source: Pre-built solutions offer speed and reliability but cost more; open-source is free but demands development time. Choose based on urgency and budget.

Permalink

The Cyberhaven Chrome Extension Vulnerability

Shasheen Bandodkar — Mon, 06 Jan 2025 08:00:00 +0000

In late December 2024, Cyberhaven, a data loss prevention company, experienced a security breach involving its Chrome browser extension. The incident was part of a broader campaign targeting multiple Chrome extensions across various organizations.

Incident Overview

On December 24, 2024, a Cyberhaven employee fell victim to a phishing attack that compromised their Google Chrome Web Store access. The attacker exploited this access to publish a malicious version (24.10.4) of Cyberhaven’s Chrome extension. This compromised extension was active from December 25, 1:32 AM UTC, until December 26, 2:50 AM UTC, during which it could exfiltrate sensitive user data, including authenticated sessions and cookies, to a rogue domain (cyberhavenext[.]pro).

The malicious extension contained two altered JavaScript files:

worker.js: This script contacted the command and control (C&C) server at cyberhavenext[.]pro to download a configuration stored in Chrome’s local storage. It also registered listeners to handle events from content.js and execute HTTP requests as directed.
content.js: This script monitored user interactions and DOM changes, focusing on specific websites. It communicated with worker.js to relay information back to the attacker, facilitating the exfiltration of sensitive data.

Some extra details we got from Cyberhaven (only after reaching out to them) cc @tuckner on the config keys below

The extension (version 24.10.6) is currently pending review by Google and will be ready to push in the next few hours
We intend to push the update to the Chrome…
— solst/ICE (@IceSolst) December 26, 2024

CyberHaven malicious extension (24.10.4) details 🧵

A new content script was added to the extension manifest which runs at the start of every webpage pic.twitter.com/ot6fxcXQvP
— tuckner (@tuckner) December 26, 2024

The attack vector involved a phishing email that led the employee to authorize a malicious OAuth application named “Privacy Policy Extension.” This authorization allowed the attacker to upload the compromised extension to the Chrome Web Store. Notably, the employee had Google Advanced Protection and multi-factor authentication (MFA) enabled yet did not receive an MFA prompt during the attack, indicating a sophisticated bypass of security measures.

Post Incident Analysis and Remediation

Scenario 1: Extension Controlled Using Browser Security on Chrome

Challenges in this scenario:

Limited control over the extension behavior.
Dependency on Chrome’s built-in extension management policies for mitigation.
Users may unwittingly install the malicious extension if not preemptively blocked.

Actions Security Teams Should Take

Analyze and Block the Extension

• Audit Installed Extensions: Use tools like Chrome Browser Cloud Management (CBCM) to generate an inventory of extensions across managed endpoints.

• Create an Extension Blocklist: Block the malicious extension by its unique extension ID using Chrome policies:

{
    "ExtensionSettings": {
        "*": {
            "installation_mode": "allowed"
        },
        "malicious_extension_id": {
            "installation_mode": "blocked"
        }
    }
}

Force Removal: Enforce a policy to uninstall the extension from all managed browsers

2. Enhance User Awareness

Notify users about the malicious extension and provide steps to verify its presence and remove it if necessary.
- Rotate user credentials for necessary applications.
Educate users on how to spot potentially malicious extensions and encourage the use of vetted tools.

3. Monitor Browser Activity

DNS and Network Traffic: Monitor for communication to suspicious domains associated with the extension.
Anomaly Detection: Look for unusual browser behaviors, such as excessive CPU usage or unexpected web requests originating from endpoints.

4. Restrict Extension Permissions

Implement strict permissions policies for Chrome extensions, allowing only those necessary for legitimate business purposes.
Use enterprise extension allowlisting to preapprove a set of trusted extensions.

Scenario 2: Extension Controlled via MDM with No Log Visibility

Challenges in this scenario:

Complete control of the extension by the third-party provider means no transparency in its operations.
Logs and telemetry are unavailable for real-time monitoring or incident response.
Mitigating the issue might/will involve third-party coordination.

Actions Security Teams Should Take

Evaluate the Third-Party Vendor

Demand Transparency: Request detailed reports and security assessments from the Vendor, including evidence of a secure software development lifecycle (SDLC).
Review Incident Response Plans: Ensure the Vendor has robust incident handling mechanisms.
Compliance Checks: Verify that the Vendor adheres to relevant security frameworks (e.g., SOC 2, ISO 27001).

2. Control Distribution and Use

Restrict to Necessary Systems: Deploy the extension only on devices, accounts, or browsers that require it.
Apply Usage Policies: Use MDM policies to enforce strict usage controls, such as disabling access during off-hours or limiting access to critical sensitive systems.

3. Monitor Through Alternative Means

Endpoint Behavior Monitoring: Deploy endpoint detection and response (EDR) tools (e.g., CrowdStrike) to flag suspicious activities triggered by the extension.
DNS and Traffic Analysis: Identify unusual traffic patterns to known C2 or malicious domains and block outbound connections.

4. Coordinate with the Vendor

Notify the Vendor of the detected vulnerability immediately and request:
Do root cause analysis.
Updates or patches to the extension.
Specific mitigation steps for customers.

5. Containment and Removal

If the vulnerability poses a severe threat:
- Revoke the extension’s access via MDM policies.
- Implement emergency procedures to uninstall the extension across all endpoints.
- Use MDM to enforce the usage of a secure alternative tool.

Long-Term Recommendations for Both Scenarios

Adopt Browser Management Tools: Use CBCM (Chrome Browser Cloud Management) or similar tools to enforce strict security policies and gain visibility into browser-related risks.
Integrate MDM Logs with SIEM: Leverage third-party integrations or proxy-based monitoring to collect relevant telemetry and add visibility to blind spots.
Vendor Management Program: Regularly review third-party tools for vulnerabilities. Enforce contractual agreements mandating compliance with security best practices and prompt remediation of discovered issues.
Simulate Extension Attacks: Conduct red-team exercises focusing on malicious browser extensions to test organizational response plans.
Alternative Solutions: If the third-party Vendor fails to address concerns, explore secure alternatives vetted through rigorous testing and analysis.

In both scenarios, organizations can significantly mitigate risks associated with third-party browser extensions by combining proactive management, user education, and vendor collaboration.

References:

Permalink

Methods for bypassing Multi-Factor Authentication (MFA)

Shasheen Bandodkar — Mon, 11 Nov 2024 07:59:00 +0000

Multi-factor authentication (MFA) is designed to provide an additional layer of security by requiring multiple verification steps before granting access to sensitive information. However, when organizations experience data breaches, attackers can exploit weaknesses when implementing MFA by accessing publicly visible databases via forums and sites. For instance, if an attacker gains access to user credentials through phishing or database leaks, they may also find ways to bypass or compromise the second authentication factor, mainly if it relies on SMS codes, which can be intercepted or redirected. It accentuates the importance of employing robust MFA methods, such as those utilizing hardware tokens or authenticator apps, to mitigate the risks associated with compromised data.

Phishing Attacks: Phishing is a technique used to deceive individuals into providing sensitive information, such as login credentials or authentication codes. Attackers often create fake login pages or spoof legitimate sites.

Method:

Creation of a Fake Login Page: Attackers replicate the login page of a trusted website. When a user enters their credentials, the attacker collects those details.
Timing of MFA Prompt: After stealing the initial credentials (email & password), the attacker can initiate a login attempt and capture the MFA token sent to the user's device.

Mitigation:

Educate users to verify URLs.
Utilize security features like anti-phishing tools in email clients.

SIM Swapping: Attackers use this technique to convince a mobile service provider to transfer a victim's phone number to a SIM card controlled by the attacker.

Method

Social Engineering: Attackers gather personal information about the target and call the mobile carrier, impersonating the victim to initiate a SIM swap.
Receiving MFA Codes: Once the swap is complete, the attacker can access the victim's MFA codes sent via SMS.

Mitigation

Use carrier-specific options to lock the SIM with additional layers of authentication.
Consider using an authenticator app instead of SMS for MFA.

Man-in-the-Middle Attacks: In a man-in-the-middle (MitM) attack, the attacker intercepts the communication between the user and the application during the authentication process.

Method

Intercepting Traffic: Attackers set up a proxy server that captures the communication. Users may unknowingly connect to these malicious servers.
Capturing MFA Tokens: The attacker gains access to the username, password, and any MFA codes.

Mitigation

Utilize end-to-end encryption and secure connections (HTTPS).
Implement device-level security measures to prevent unauthorized access.

Malware and Spyware: Malware and spyware installed on users machines can capture a user's credentials and MFA codes directly from their devices.

Method

Keyloggers: It is used to record user keystrokes, capturing the password and subsequent MFA inputs.
Remote Access Trojans (RATs): Attackers gain control of devices, allowing them to intercept authentication processes.

Mitigation

Regularly update antivirus software and conduct security scans.
Encourage users to be cautious when downloading unknown software.

Session Hijacking: Session hijacking is when an attacker takes over a user session after the user has logged in, often through exposing session tokens. This means that the attacker can essentially 'hijack' the user's session and gain access to their account without needing to go through the MFA process again.

Method

Capturing Session Tokens: Using techniques such as cross-site scripting (XSS), attackers can steal session tokens after a user has authenticated with MFA.
Using the Compromised Session: Once they have the session token, they may invalidate the need for further MFA checks.

Mitigation

Implement HttpOnly and Secure flags on cookies to make them less accessible to scripts.
Regularly monitor user sessions and employ anomaly detection systems.

Recovery Options Abuse: Many services provide recovery options for accessing accounts when MFA devices are lost or inaccessible. Unfortunately, these mechanisms can be exploited.

Method

Social Engineering: Attackers can impersonate the account owner and request password resets or access through recovery questions.
Abuse of Backup Codes: If backup codes are stored insecurely, they could be accessed by an attacker who can use them to bypass MFA.

Mitigation

Encourage users to secure backup codes and regularly change passwords.
Standardize the methods for verifying identity during recovery processes.

Conclusion

Multi-factor authentication (MFA) is a key layer of defense for securing user accounts. Addressing existing vulnerabilities is equally essential. By pinpointing and addressing these weak points, you can enhance account protection against unauthorized access and take proactive measures to reduce security risk.

Permalink

OAuth 2.0 authentication vulnerabilities and remediations

Shasheen Bandodkar — Mon, 26 Aug 2024 07:00:00 +0000

OAuth 2.0 is a popular authorization framework that allows third-party applications to access a user’s resources without knowing their credentials. While it enhances convenience and security in web applications, its implementation can introduce various vulnerabilities. Understanding these risks is essential for developers and organizations to safeguard sensitive user data and maintain trust. Because OAuth 2.0 is widely used, it becomes an attractive target for attackers, especially since implementation errors can lead to vulnerabilities. These flaws might enable attackers to access sensitive information or even bypass authentication entirely.

Authorization Code Interception

Vulnerability: It occurs when an attacker intercepts the authorization code returned from the authorization server before the client application can use it to receive an access token. If the attacker captures the authorization code, they can use it to request an access token.
Example: In a typical eCommerce site where a user is redirected to PayPal for payment authorization if the redirect URI is not secured (e.g., using HTTP instead of HTTPS), an attacker could intercept the code through man-in-the-middle attacks.
Remediation: Implement proof of authorization using Proof Key for Code Exchange (PKCE). This adds a layer of security by requiring a code challenge and code verifier, reducing the risk of interception.

Implicit Grant Flow Misuse

Vulnerability: The implicit grant flow is designed for client-side applications, where access tokens are returned directly in the redirect URI. If not implemented correctly, it exposes the tokens in URLs, which browsers can log or cache.
Example: An eCommerce application that uses the implicit flow could expose the access token in the browser's address bar or third-party tracking tools, making it accessible to malicious users. This situation compromises secure transactions, especially those with PayPal.
Remediation: Avoid using the implicit grant flow. Instead, switch to the authorization code grant type with PKCE. This reduces token exposure and minimizes the risks of unauthorized token access.

Cross-Site Request Forgery (CSRF)

Vulnerability: CSRF attacks exploit the trust a web application has in the user’s browser. If an attacker tricks a user into clicking on a link that performs actions with their credentials, they could gain unauthorized access.
Example: If a user has already authenticated with PayPal and the eCommerce site does not use CSRF tokens for critical operations, an attacker could send a fraudulent request to initiate a payment, leveraging the already accepted session.
Remediation: Include anti-CSRF tokens in state parameters during the OAuth flow (enable SameSite). This helps prevent malicious requests from being processed and ensures that the requests are legitimate.

Lack of State Parameter Validation

Vulnerability: The state parameter is designed to maintain the state between the authorization request and the callback. If an application does not validate the state parameter, it becomes prone to CSRF attacks and session fixation.
Example: An eCommerce site that fails to validate the state returns from PayPal could allow attackers to redirect users to different sites and execute unauthorized actions, as the application would have no way to verify the authenticity of the request.
Remediation: Ensure the state parameter is included in your OAuth requests and validated on the callback. Implement a mechanism to generate a unique state for each authorization request and store it securely. Upon receiving the callback, compare the returned state with the stored value to mitigate CSRF attacks.

Insufficient Token Expiration and Revocation Policies

Vulnerability: OAuth access tokens should have limited lifetimes, and there should be a way to revoke them if they are compromised. If tokens are long-lived or not revocable, the risk of misuse increases.
Example: If an eCommerce platform using PayPal provides long-lived access tokens, an attacker who gains access to one could indefinitely make fraudulent transactions until the token expires or is manually revoked.
Remediation: Establish clear token expiration policies for access tokens. Set reasonable expiration times depending on the application's requirements. Implement refresh tokens with shorter lifespans and ensure they can only be used in secure contexts. Regularly review and update token lifetimes as necessary. Develop and document a robust token revocation process. This should include end-user interfaces to manually revoke tokens and automated processes to revoke tokens upon user logout or account suspension. Regularly audit active tokens and provide mechanisms to invalidate them as needed.

Scope Misconfiguration

Vulnerability: OAuth allows the specification of scopes that define resource access levels. Inadequate scope definitions can lead to overly broad access to user data or operations.
Example: If the eCommerce site incorrectly requests broad permissions (e.g., access to the user's complete profile) without needing it, an attacker who gains the access token could harm sensitive data or perform unintended actions without user awareness.
Remediation: Review and configure scopes carefully to match the principle of least privilege. Only request and grant access to scopes that are strictly necessary for your application's functionality. Regularly audit scopes and permissions for outdated or unnecessary configurations and refine them to enhance security.

Cross-Site Scripting

Vulnerability: If an application is vulnerable to XSS, an attacker could execute scripts in the context of a user's session, potentially intercepting unnecessary OAuth tokens or redirecting users to malicious sites.
Remediation: A CSP acts as a security measure that helps prevent XSS attacks by defining the sources from which content can be loaded and executed.
- Set Up a CSP Header: The CSP should be configured to specify trusted sources for scripts, styles, and other content. For example:
- Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; object-src 'none';
  In this policy, only scripts from the same origin and from trusted.cdn.com can execute.
- Restrict Inline Scripts: Inline scripts should be avoided. Consider using hash-based or nonce-based CSP to allow specific inline scripts without permitting arbitrary code execution.
- Limit Token Exposure: Use the sandbox directive where appropriate to limit the capabilities of the document in which the OAuth 2.0 flows occur. This can prevent the execution of scripts in unsecured contexts.

Open Redirects

Vulnerability: An open redirect vulnerability can occur if the authorization server allows redirection to untrusted addresses. Attackers can exploit this feature to redirect users to phishing sites.
Example: If the eCommerce site is integrated with PayPal and allows arbitrary redirections in the OAuth flow, an attacker could change the redirect URI to a phishing site, controlling the user’s actions after authentication.
Remediation: Validate redirect URIs meticulously. Only allow redirects to pre-registered URIs and reject any unrecognized or potentially dangerous addresses to mitigate the risk of phishing.

Conclusion

In conclusion, security risks such as token leakage, improper implementation, and phishing attacks can undermine its effectiveness against Oauth. Developers and organizations must understand these weaknesses and adopt best practices to mitigate them. This includes implementing secure storage solutions, short-lived access tokens, and conducting thorough security audits. By staying informed and vigilant, we can enhance the security posture of applications utilizing OAuth 2.0 and better protect user data. Continuously updating and refining security measures will ensure that the OAuth 2.0 framework remains reliable in an ever-evolving threat landscape.

Permalink

Strategies to secure containerized environments

Shasheen Bandodkar — Mon, 12 Aug 2024 07:00:00 +0000

With container security, it’s vital to focus on two main aspects: Container Image Security and Container Runtime Security. Each aspect addresses different stages of the container lifecycle and potential threats.

Container Image Security

Container Image Security focuses on ensuring that the container images that are built and deployed are free from vulnerabilities and constructed securely. The primary goal is to minimize the attack surface and prevent attackers from exploiting weaknesses within the image.

Use Minimal Base Images: Start with minimal base images that include only the necessary components to run the application. This reduces the number of potential vulnerabilities that an attacker could exploit. Tools like ChainGuard provide secure, minimal base images designed specifically for security.
Exclude Unnecessary Components: During the image build process, ensure that the Dockerfile excludes components that are not required for the application to run in production. This not only reduces the image size but also removes potential vulnerabilities.
Utilize Multi-Stage Builds: Multi-stage builds allow components needed only during the build process (such as development tools) to be included but excluded from the final runtime image. This results in a cleaner, more secure production image.
Vulnerability Scanning: Regularly scan the container images for known vulnerabilities using tools like Snyk (which is integrated with Docker) or Trivy (from Aqua Security). These tools can identify and alert for vulnerabilities, allowing one to address them before deploying the image.
Run Containers as Non-Root: Running containers as a non-root user with minimal permissions is a critical security measure. By avoiding root access, attackers can limit the damage they can do if they compromise the container.
Treat Images as Public: Avoid embedding sensitive information (like passwords, API keys, or private certificates) within your container images. Instead, this data can be injected at runtime using environment variables or secrets management tools. This practice ensures that no sensitive information is compromised, even if an image is exposed.
Cryptographic Signing: Signing your container images using cryptographic techniques ensures their integrity and authenticity. This process proves the origin of the image and helps prevent tampering. Docker Content Trust (DCT) is one option that enables image signing and verification.
Pin Base Images to Specific Versions: Pinning your base images to at least the minor version number helps incorporate bug fixes while avoiding unexpected breaking changes. This practice ensures consistency and security across your environments.

Container Runtime Security

Container Runtime Security addresses the security concerns that arise when a container runs. The focus is on minimizing the potential damage an attacker can do if they compromise a running container and preventing lateral movement within your environment.

Enable User Namespace Remap: User namespace remapping in Docker (enabled via the --userns-remap option) isolates container user namespaces from the host system. This separation ensures that a user inside a container cannot interact with or gain access to resources on the host, even if they break out of the container.
Read-Only File System: Configure the file system to be read-only for containers that do not require write access. This restriction significantly reduces the potential for attackers to modify the file system, plant malicious files, or persist changes that could be used in future attacks.
Cap_Drop and Cap_Add: By default, containers run with a set of capabilities that may not all be necessary. Use the --cap-drop option to remove all capabilities, then selectively add back only the required ones using the --cap-add option. This fine-grained control limits the scope of what a compromised container can do.
Resource Limits: Setting CPU and memory limits for your containers is essential to prevent denial-of-service (DoS) attacks. These limits ensure that no single container can consume all the host's resources, which could otherwise disrupt service availability or lead to resource starvation.
Security Profiles: Leverage security profiles like Seccomp (Secure Computing Mode) or AppArmor to enforce additional security layers. Seccomp restricts the system calls that a container can make, while AppArmor profiles define what a container can and cannot do at the kernel level. These profiles help to contain the potential damage from a compromised container.

Permalink

Summary of the Global Crowdstrike-Microsoft Outage

Shasheen Bandodkar — Mon, 22 Jul 2024 07:00:00 +0000

Overview

On July 19, 2024, CrowdStrike and Microsoft experienced a significant global outage that lasted multiple hours and impacted vital services. The disruption, from a configuration error during routine maintenance, affected authentication and data processing systems. The sensor configuration update that caused the system crash was remediated on Friday, July 19, 2024, 05:27 UTC. The impact was felt by customers running Falcon sensor for Windows version 7.11 and above online between Friday, July 19, 2024, 04:09 UTC and Friday, July 19, 2024, 05:27 UTC. Systems running Falcon sensors for Windows 7.11 and above were susceptible to a system crash.

Details

The outage's root cause was identified as a misconfiguration resulting from a system update error. The configuration files mentioned above are referred to as “Channel Files” and are part of the behavioural protection mechanisms used by the Falcon sensor. Updates to Channel Files are a normal part of the sensor’s operation and occur several times daily in response to novel tactics, techniques, and procedures discovered by CrowdStrike.

Analysis

On Windows systems, Channel Files reside in the following directory:

C:\Windows\System32\drivers\CrowdStrike\

It has a file name that starts with “C-”. Each channel file is assigned a number as a unique identifier. The impacted Channel File in this event is 291 and will have a filename that starts with “C-00000291-” and ends with a .sys extension. Although Channel Files end with the SYS extension, they are not kernel drivers.

Triage & Remediation Steps

Per CrowStrike, here are the recommendations for workarounds -

Reboot the host to allow it to download the reverted channel file. We strongly recommend putting the host on a wired network (as opposed to WiFi) before rebooting, as the host will acquire internet connectivity considerably faster via ethernet.
If the host crashes again, then:

Boot Windows into Safe Mode or the Windows Recovery Environment

NOTE: Putting the host on a wired network (as opposed to WiFi) and using Safe Mode with Networking can help remediation.

Navigate to the %WINDIR%\System32\drivers\CrowdStrike directory

Windows Recovery defaults to X:\windows\system32

Navigate to the appropriate partition first (default is C:\), and navigate to the crowd strike directory:

C:
cd windows\system32\drivers\crowdstrike

Note: On WinRE/WinPE, navigate to the Windows\System32\drivers\CrowdStrike directory of the OS volume

Locate the file matching “C-00000291*.sys” and delete it.

Do not delete or change any other files or folders

Cold Boot, the host

Shut down the host.
Start host from the off-state.

Note: Bitlocker-encrypted hosts may require a recovery key

Advanced Search Query for Crowdstrike Affected Hosts

// Get ConfigStateUpdate and SensorHeartbeat events
#event_simpleName=/^(ConfigStateUpdate|SensorHeartbeat)$/ event_platform=Win 
// Narrow search to Channel File 291 and extract version number; accept all SensorHeartbeat events within impact window
| case{
    #event_simpleName=ConfigStateUpdate | regex("\|1,123,(?.*?)\|", field=ConfigStateData, strict=false) | parseInt(CFVersion, radix=16);
    #event_simpleName=SensorHeartbeat | rename([[@timestamp, LastSeen]]);
}


| case{
    #event_simpleName=ConfigStateUpdate | @timestamp>1721362140000 AND @timestamp < 1721366820000 | CSUcounter:=1;
    #event_simpleName=SensorHeartbeat | LastSeen>1721362140000 AND LastSeen<1721366820000 | SHBcounter:=1;
    *;
}
| default(value="0", field=[CSUcounter, SHBcounter])
// Make sure both ConfigState update and SensorHeartbeat have happened
| selfJoinFilter(field=[cid, aid, ComputerName], where=[{ConfigStateUpdate}, {SensorHeartbeat}])
// Aggregate results
| groupBy([cid, aid], function=([{selectFromMax(field="@timestamp", include=[CFVersion])}, {selectFromMax(field="@timestamp", include=[@timestamp]) | rename(field="@timestamp", as="LastSeen")}, max(CSUcounter, as=CSUcounter), max(SHBcounter, as=SHBcounter)]), limit=max)
// Perform check on selfJoinFilter
| CFVersion=* LastSeen=*
// Calculate time between last seen and now
| LastSeenDelta:=now()-LastSeen
// Optional threshold; 3600000 is one hour
| LastSeenDelta>3600000
// Calculate duration between last seen and now
| LastSeenDelta:=formatDuration("LastSeenDelta", precision=2)
// Convert LastSeen time to human-readable format
| LastSeen:=formatTime(format="%F %T", field="LastSeen")
// Enrich aggregation with aid_master details
| aid=~match(file="aid_master_main.csv", column=[aid])
| aid=~match(file="aid_master_details.csv", column=[aid], include=[FalconGroupingTags, SensorGroupingTags])
// Convert FirstSeen time to human-readable format
| FirstSeen:=formatTime(format="%F %T", field="FirstSeen")


// Move ProductType to human-readable format and add formatting
| $falcon/helper:enrich(field=ProductType)
| drop([Time])
| default(value="-", field=[MachineDomain, OU, SiteName, FalconGroupingTags, SensorGroupingTags], replaceEmpty=true)
| case{
    CSUcounter=0 AND SHBcounter=0 | Details:="OK: Endpoint did not receive channel file during impacted window. Endpoint was offline.";
    CSUcounter=0 AND SHBcounter=1 | Details:="OK: Endpoint did not receive channel file during impacted window. Endpoint was online.";
    CSUcounter=1 AND SHBcounter=1 | Details:="CHECK: Endpoint received channel file during impacted window. Endpoint was online. Endpoint has not been seen online in past hour.";

Lessons Learned

This outage underscored the importance of robust contingency planning, rigorous testing of system changes, and transparent customer communication during disruptions. In response, CrowdStrike and Microsoft are enhancing monitoring capabilities and reinforcing change management procedures to reduce the risk of similar incidents.
Watch for malicious actors leveraging the ongoing CrowdStrike-related event to phish organizations. Example → https://www.virustotal.com/gui/domain/crowdstrike-bsod.com

References:

Permalink

How I passed the eWPT exam?

Shasheen Bandodkar — Mon, 27 May 2024 07:00:00 +0000

The eWeb Application Penetration Testing (eWPT) certification exam offered by INE is intended for individuals who want to demonstrate their expertise in identifying security vulnerabilities within web applications and understanding how to secure them effectively. The eWPT exam is a practical, hands-on assessment that evaluates one's ability to conduct thorough penetration tests on web applications. Demonstrating proficiency in various areas, including web application architecture, OWASP Top 10 vulnerabilities, manual web application penetration testing techniques, and reporting.

During the exam, you must identify and exploit security vulnerabilities within a simulated web application environment. It leverages the knowledge of common web application attack vectors, such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF), to successfully compromise the target system. It tests the ability to perform comprehensive security assessments, accurately identify vulnerabilities, and provide actionable recommendations for improving the security posture of web applications. Additionally, it also evaluates the understanding of industry best practices and proficiency in using various penetration testing tools.

My Recommendations:

The exam requires perseverance, thorough enumeration, and the ability to adapt. Practice, manage your time and energy, and focus on your weaknesses. Use multiple tools, search for exploits and vulnerabilities, and try different approaches. Don’t give up; keep trying harder.

Tips for the eWPT. (Applicable for any penetration testing or examination)

📝 Thorough enumeration is crucial for success. It involves exhaustively exploring all options, such as scanning all ports, identifying services and vulnerabilities, and gathering information.
🛠️ Don’t settle for one tool. Try multiple tools for better results.
🚪 Don’t skip easy wins. They can lead to important credentials or sensitive data and confirm results.
🔍 Be specific in web searches for exploits and vulnerabilities. Adding keywords like “exploit,” “vulnerability,” and specific sources like GitHub can help find actual code and proof-of-concepts.
💦 Spray usernames as passwords to gather more information. Creating a separate file for spraying can help differentiate between potential and actual passwords.
🗝️ Always check for default credentials. They can provide access. Many systems and services have default usernames and passwords often left unchanged, providing an easy entry point.
🧩 Be flexible and persistent. Try different approaches if one fails. Trying alternative methods or exploits with the same vulnerability can lead to success if one approach or exploit doesn't work.
👨‍💻 Understand what you’re doing, read documentation and code. Reading documentation, code, and comments can help grasp the inner workings of exploits and vulnerabilities, enabling customization and adaptation to different scenarios.
❌ Don’t run exploits blindly. Understand their functionality. Reading through exploits' code, documentation, and comments is crucial for success.
🔄 If one exploit doesn’t work, try another with the same vulnerability. Multiple exploits are usually available for known vulnerabilities, and exploring different options can lead to success.
- Searchsploit, exploitDB, github, POC’s, etc.
Consult or ask experienced individuals in discord/slack, etc groups for any doubts you come across.

Permalink

Elevating Security Projects to New Heights with the power of Diataxis.

Shasheen Bandodkar — Tue, 02 Jan 2024 07:00:00 +0000

Maintaining robust security is paramount in the modern digital landscape, where cyber threats loom large and technological advancements continue at an unprecedented pace. That's where diataxis comes into play. Diataxis is a systematic and integrated approach to security projects that offers a powerful solution for organizations looking to bridge the gap between various security initiatives.

Understanding Diataxis

Diataxis is a framework that encompasses developing, implementing, and managing security projects, ensuring a cohesive and all-encompassing approach. It acts as a central nervous system, coordinating and aligning organizational security initiatives. Traditionally, security projects are considered disparate entities, leading to inefficiencies in resource allocation, communication gaps, and fragmented outcomes. Diataxis solves these challenges by providing a holistic and interconnected approach to security.

The Benefits of Diataxis

Enhanced Coordination: Diataxis brings various security projects under one umbrella, ensuring seamless coordination between different teams, departments, and stakeholders. This leads to improved synergy, minimized duplication of efforts, and better resource allocation, resulting in unparalleled efficiency.
Comprehensive Risk Management: By promoting collaboration and centralizing security efforts, diataxis addresses the challenge of fragmentary risk assessment. It allows organizations to assess risks holistically and implement comprehensive strategies to counter emerging threats. This cohesive approach minimizes blind spots and enhances overall security posture.
Streamlined Communication: Diataxis fosters effective communication, breaking down silos that often hinder the flow of information. Establishing clear channels and standardized processes makes it easier to disseminate critical security updates, share insights, and respond promptly to potential security incidents.
Scalability and Adaptability: Diataxis enables organizations to navigate the evolving security landscape effectively. With a centralized framework in place, organizations can identify emerging threats, evaluate current security projects, and modify strategies as needed. This adaptability ensures security initiatives stay relevant despite rapidly changing technologies and threat landscapes.

Implementing Diataxis in Security Projects

Assess Current Security Landscape: Begin by conducting a comprehensive assessment of your organization's current security posture, identifying existing security projects, and assessing their effectiveness and alignment with overall objectives.
Identify Key Stakeholders: Identify key organizational stakeholders who will be pivotal in driving diataxis forward. This includes IT, operations, legal, human resources, and executive leadership representatives. Their support and participation are crucial for successful implementation.
Establish a Centralized Security Committee: Create a cross-functional security committee responsible for overseeing and driving diataxis initiatives. This committee should meet regularly to discuss progress, align objectives, and address potential roadblocks.
Develop a Diataxis Plan: Develop a comprehensive diataxis plan that outlines the desired outcomes, assesses resource requirements, and defines metrics for success. Break down silos between different security projects and ensure they are interlinked and aligned with the organization's overall security strategy.
Execute and Continuously Monitor: Implement the diataxis plan, ensuring that ongoing communication, collaboration, and information sharing remain at the core of each security project. Monitor progress, gather feedback, and make adjustments when necessary.

Example

Let's consider a hypothetical scenario in which a company implements a robust security system for its premises. Here's an example of how they could effectively utilize the Diataxis Plan for this current security project:
Step 1: Analyze
Assess the current security infrastructure and identify potential vulnerabilities. Conduct a thorough audit of physical and digital assets, identify entry points, evaluate existing security measures, and determine areas of concern. For instance, in this project, the company realizes they have limited surveillance cameras and no access control system, leaving their premises vulnerable to unauthorized access.
Step 2: Plan
Based on the analysis, create a detailed plan to address identified weaknesses and enhance overall security. This includes determining the required resources, establishing a budget, and setting measurable objectives. In this example, the company decided to install a comprehensive video surveillance system covering all critical areas, implement an access control system with keycard entry, and set up an intrusion detection system.
Step 3: Implement
This stage involves executing the plan developed in the previous step. It includes procuring necessary equipment, hiring additional personnel, and initiating implementation. The company hires a professional security firm to install a CCTV camera network across the premises, ensuring full coverage and optimal visibility. They also partner with an access control solutions provider to install an automated access control system integrated with their existing infrastructure.
Step 4: Monitor
Continuously monitor the security measures to detect potential vulnerabilities and address them proactively. Enforce a robust incident reporting system among employees and conduct routine checks to ensure compliance with security protocols. The company in this example sets up a dedicated security team responsible for 24/7 monitoring of the surveillance cameras and intrusion detection system. They also implement regular security awareness training for employees to promote a culture of vigilance and report any suspicious activities promptly.
Step 5: Adapt
In this final step, regularly review and refine the security measures to align with emerging threats or changing business requirements. Stay up-to-date with the latest security advancements, explore new technologies, and adjust the security plan accordingly. For instance, the company periodically reviews its security protocols, conducts vulnerability assessments, and upgrades its systems to ensure they are prepared against evolving threats.
Each security project is unique, and the Diataxis Plan can be customized to fit specific needs and circumstances.

Conclusion

The implementation of diataxis within security projects has the potential to transform an organization's security posture. By breaking down silos, fostering collaboration, and ensuring a comprehensive approach to risk management, diataxis offers an unparalleled way to bridge the gap between multiple security initiatives. Embracing this integrated framework can lead to enhanced security, improved communication, efficient resource allocation, and ultimately, safeguarded digital assets in an increasingly complex threat landscape. Embrace diataxis and elevate your security projects to new heights. Remember, a secure organization is a resilient organization.

Reference: https://diataxis.fr/reference-explanation/

Permalink

What are Passkeys, and how do they work?

Shasheen Bandodkar — Wed, 01 Nov 2023 07:00:00 +0000

In today's digital age, where data breaches and cyber threats have become an unfortunate reality, safeguarding our online presence has become more crucial than ever. One effective way to enhance our digital security is by implementing passkeys.

Understanding Passkeys

At its core, a passkey is a unique combination of characters or a passphrase that grants a user access to a protected system or resource. Unlike traditional passwords, passkeys offer greater security by relying on longer strings of characters and using a combination of various character types. When it comes to passkeys, encryption serves as a shield against unauthorized access. The encryption process transforms the passkey into an unreadable format using complex algorithms and mathematical computations. This ensures that even if an attacker gains access to the encrypted passkey, they will be unable to decipher its original value. Modern encryption techniques like AES (Advanced Encryption Standard) and RSA (Rivest-Shamir-Adleman) are widely employed, providing robust security for passkeys. By utilizing encryption, we can trust that our passkeys remain well-guarded and keep our digital accounts and information safe from malicious entities.
Passkeys leverage encryption algorithms to convert user-provided information into an unreadable format known as a hash. This hash is then stored on the system, ensuring passwords are never stored in their original form. When a user enters their passkey during login, the system recreates the hash using the same algorithm and compares it to the stored hash. If they match, access is granted; otherwise, access is denied.

Implementing Passkeys

1. Choosing a Strong Passkey

Creating a strong passkey is crucial to protect your digital presence. Ensure that your passkey is at least 12-16 characters long and uses a combination of uppercase and lowercase letters, numbers, and special characters. Avoid easily guessable phrases and personal information, as hackers often exploit these.

2. Implementing Two-Factor Authentication (2FA)

To further enhance the security provided by passkeys, consider enabling two-factor authentication (2FA). This additional layer of security requires users to provide a secondary verification method, such as a fingerprint scan or a unique code sent to a registered mobile device. 2FA significantly reduces the chances of unauthorized access.

3. Using Password Managers

To effectively manage passkeys across multiple platforms, consider using a trusted password manager. Password managers generate strong and unique passkeys for each website or application you use and securely store them, eliminating the need for you to remember them all. Remember to choose a reputable password manager with strong encryption protocols.

4. Regularly Updating Your Passkeys

Periodically changing your passkeys is an essential practice to prevent hackers from gaining prolonged access to your accounts. Aim to update your passkeys every three to six months and avoid reusing passkeys across different platforms.

5. Beware of Phishing Attempts

Even with a strong passkey, falling victim to phishing attempts can compromise your security. Be cautious of suspicious emails or messages asking you to provide your passkey or personal information. Always verify the legitimacy of such requests by directly contacting the organization through official channels.

Stronger Security Ahead

Passkeys serve as a powerful tool in fortifying our digital security. By understanding how they work and following best practices for implementation, we can significantly reduce the risks associated with cyber threats and data breaches. While passkeys offer enhanced protection, staying vigilant and adopting good cybersecurity habits are equally important. With these efforts combined, we can bridge the gap to a safer digital future.

Permalink

What is a Race Condition Vulnerability?

Shasheen Bandodkar — Wed, 04 Oct 2023 07:00:00 +0000

Technology constantly evolves in the vast realm of cybersecurity, unveiling new challenges for developers and organizations worldwide. A race condition is one such vulnerability that has been a cause for concern. With its ability to evade and exploit security measures, understanding this vulnerability is crucial for safeguarding sensitive data and systems.

Defining the Race Condition Vulnerability:
A race condition is a software flaw that arises when multiple processes or threads access shared resources concurrently, leading to unpredictable and unintended consequences. It occurs when the outcome of a program depends on the relative timing of events rather than the individual order in which they are meant to be executed.

Root Causes and Mechanisms:
Several factors contribute to the emergence of race conditions, including poor synchronization techniques, shared resources mismanagement, and the absence of appropriate concurrency controls. A race condition can occur when multiple processes contend for access to shared resources or critical code sections without proper synchronization mechanisms. This can lead to inconsistencies, data corruption, security breaches, or system crashes.

A race condition security vulnerability can occur when multiple processes or threads simultaneously access and alter shared resources. It arises when the program's output depends on the order in which these processes execute, leading to unexpected or malicious behavior. Consider this hypothetical example below:

Vulnerable code snippet

def transferfunds(senderaccount, receiver_account, amount):
if sender_account.balance >= amount:

# Deduct the amount from sender's account
sender_account.balance -= amount

# Simulate some processing time (to highlight the race condition vulnerability)
time.sleep(1)

# Credit the amount to the receiver's account
receiver_account.balance += amount
print("Funds transferred successfully!")
else:
print("Insufficient funds!")

Example usage

Create two bank accounts

account_A = BankAccount(balance=500)
account_B = BankAccount(balance=300)

Create two threads, each simulating a transaction

thread1 = threading.Thread(target=transferfunds, args=(accountA, accountB, 400))
thread2 = threading.Thread(target=transferfunds, args=(accountB, accountA, 200))

Start the threads

thread_1.start()
thread_2.start()

In this scenario, two threads are created to simulate two concurrent bank transactions: transferring funds from account A to account B and then from account B back to account A. The transfer_funds function deducts the specified amount from the sender's account and credits it to the receiver's account.
At first glance, the code seems reasonable. However, a race condition vulnerability exists because both threads may execute concurrently and simultaneously access the shared resources (accountA and accountB). If the execution of thread1 is interrupted after deducting the amount from accountA, but before it credits the amount to accountB, thread2 can get scheduled and deduct funds from accountB even though accountA doesn't have sufficient funds. Consequently, both threads resume their execution and complete, resulting in an overall inconsistent state of the accounts.
This race condition can lead to an unexpected transfer of funds beyond the available balance, compromising data integrity and potentially enabling unauthorized transactions.
To mitigate this vulnerability, we can use synchronization mechanisms like locks or semaphores to ensure that only one thread can access the shared resources at a time. By properly controlling the critical sections, we can prevent race conditions and maintain the consistency of the program's execution.

Implications of Race Condition Vulnerabilities:

Race conditions can have severe consequences, from security breaches to data corruption and financial losses. Some potential outcomes include:
1. Data Integrity Violation: If multiple processes attempt to write to the exact location in memory simultaneously, the data may become corrupt, diminish integrity, or result in inconsistent output.
2. Privilege Escalation: In the presence of a race condition vulnerability, an attacker may exploit it to manipulate the system's behavior, escalate privileges, and execute unauthorized actions.
3. Denial of Service (DoS): When a race condition occurs, resource contention among processes can overwhelm the system, rendering it unresponsive, leading to a DoS condition.
4. Time of Check to Time of Use (TOCTOU) Attack: A TOCTOU attack exploits the gap between security checks and resource utilization, utilizing the fleeting window of opportunity created by race conditions to subvert intended security measures.

Preventive Measures:

Mitigating the risks associated with race conditions requires a multifaceted approach:
1. Synchronization Mechanisms: Applying adequate synchronization techniques, such as locks, semaphores, or monitors, ensures the proper coordination of shared resources and helps avoid race conditions.
2. Thread-Safe Libraries and Frameworks: Utilizing libraries and frameworks with built-in thread-safety mechanisms can significantly reduce the likelihood of race conditions.
3. Code Auditing and Testing: Thorough code reviews and rigorous testing, including stress testing and concurrency testing, help identify potential race conditions before deployment.
4. Concurrency Control Best Practices: Implementing fine-grained locking, lock-free algorithms, or transactional memory can enhance concurrency control and reduce the risk of race conditions.

Race conditions pose significant threats to the security and stability of software systems. Understanding their root causes, mechanisms, and implications is crucial to fortifying defenses against cybersecurity risks. By following best practices, applying robust synchronization techniques, and leveraging thread-safe libraries, we can narrow the window of vulnerability and safeguard systems against this covert threat. Proactive measures, continuous education, and staying informed are essential in maintaining the security of the digital landscape.

Permalink

Security Engineering - HEALTHYBYTE

The Anatomical Evolution of Account Takeover Attacks

B Sides ‘25 Orlando

B Sides ‘25 Chicago

Why CVEs will not help with AI Models

Can RASP be implemented in a Monolithic Architecture?

Confidential Computing for GPU Clusters in the Cloud: Security Attack Vectors and Trusted Execution Environment Exploitation (with NVIDIA Hopper and Blackwell)

Can AI be an actionable communicator for code scanning?

🛡️ Security Alert: SQL Injection Vulnerability Detected

🎯 Vulnerability Analysis

🔧 Recommended Fixes

📊 Team Context

🎯 Action Required

How to Evaluate Your Next Company?

How Should You Prioritize Product Security?

Building Agent-Bando: Learning The Inner Workings with Open-Source LLMs

Building a Vulnerability Disclosure Program

Superman vs Batman - Leadership Styles in Security Engineering

How to build a scalable IGA system?

The Cyberhaven Chrome Extension Vulnerability

Methods for bypassing Multi-Factor Authentication (MFA)

OAuth 2.0 authentication vulnerabilities and remediations

Strategies to secure containerized environments

Summary of the Global Crowdstrike-Microsoft Outage

How I passed the eWPT exam?

Elevating Security Projects to New Heights with the power of Diataxis.

What are Passkeys, and how do they work?

What is a Race Condition Vulnerability?