Beer Mug Logo
IntuneBrewby UgurLabs.com

Legal

Security Information

Learn about the security measures we implement to protect your data and ensure the integrity of the IntuneBrew platform.

Last updated: January 2025

1. Security Overview

Our Security Commitment

At IntuneBrew, security is a fundamental aspect of our platform. We implement industry-standard security practices to protect your data and ensure the reliability of our service. This document provides transparency about our security measures and practices.

Security Principles

  • Defense in Depth - Multiple layers of security controls
  • Least Privilege - Access limited to what is necessary
  • Encryption by Default - Data protected in transit and at rest
  • Transparency - Clear communication about our security practices
  • Continuous Improvement - Regular security assessments and updates

Encrypted Data

TLS 1.3 + AES-256

Secure Auth

Microsoft Entra ID

Audit Logging

Complete audit trail

2. Authentication Security

Microsoft Entra ID Integration

IntuneBrew uses Microsoft Entra ID (formerly Azure Active Directory) for user authentication. This provides enterprise-grade security features:

  • Single Sign-On (SSO) - Seamless authentication with existing Microsoft credentials
  • Multi-Factor Authentication - Support for MFA policies configured in your tenant
  • Conditional Access - Respect for your organization's conditional access policies
  • No Password Storage - We never store your Microsoft password

Token Security

Access tokens are handled with strict security measures:

  • JWT Validation - All tokens are cryptographically verified using Microsoft's public keys
  • Signature Verification - RSA signature validation via JWKS endpoint
  • Expiration Checks - Tokens are validated for expiration with minimal tolerance
  • Audience Validation - Tokens are verified for the correct audience (Microsoft Graph)
  • Issuer Validation - Only tokens from Microsoft's official endpoints are accepted
  • Claims Verification - User identity claims (oid, upn, tid) are validated

Session Management

  • Tokens stored in browser sessionStorage (cleared on tab close)
  • No persistent cookie storage of authentication tokens
  • Automatic token refresh handled by MSAL library
  • Secure logout that clears all session data

3. Data Encryption

Encryption in Transit

All data transmitted between your browser and our servers is encrypted:

  • TLS 1.3 - Latest Transport Layer Security protocol
  • HTTPS Only - HTTP Strict Transport Security (HSTS) enforced
  • Perfect Forward Secrecy - Ephemeral key exchange for each session
  • Strong Cipher Suites - Modern, secure cipher configurations

Encryption at Rest

Data stored in our systems is encrypted using industry-standard methods:

  • Database Encryption - Supabase provides transparent data encryption for stored data
  • Token Encryption - Access tokens queued for processing are encrypted with AES-256-GCM
  • Key Management - Encryption keys are securely managed and rotated

Token Encryption Details

When your Microsoft access token is used for app uploads, it is encrypted before being queued:

Algorithm: AES-256-GCM

IV Length: 16 bytes (random)

Auth Tag: 16 bytes

Key Size: 256 bits

4. Access Controls

Application Access

  • Authentication Required - All protected endpoints require valid authentication
  • User Isolation - Users can only access their own data
  • Tenant Isolation - Data is segregated by Microsoft tenant
  • Permission Validation - API permissions are validated for each request

API Security

  • Token Validation - Every API request is authenticated and authorized
  • Input Validation - All user inputs are validated server-side
  • Output Encoding - Responses are properly encoded to prevent injection
  • CORS Policy - Cross-Origin Resource Sharing restricted to authorized domains

Infrastructure Access

Access to production infrastructure follows the principle of least privilege. Administrative access is limited, protected by multi-factor authentication, and all access is logged.

5. Rate Limiting

Protection Against Abuse

We implement rate limiting to protect against abuse and ensure fair usage:

  • Per-User Limits - Requests are limited per authenticated user
  • Per-IP Limits - Additional limits based on client IP address
  • Endpoint-Specific - Different limits for different API endpoints
  • Gradual Response - Warnings before hard blocks

Rate Limit Headers

API responses include rate limit information:

X-RateLimit-Limit: Maximum requests per window

X-RateLimit-Remaining: Requests remaining

X-RateLimit-Reset: Window reset timestamp

6. Audit Logging

What We Log

Comprehensive audit logging helps us maintain security and troubleshoot issues:

  • Authentication Events - Sign-in attempts, successes, and failures
  • Authorization Events - Permission checks and access decisions
  • Data Operations - App uploads, settings changes, deployments
  • Security Events - Rate limit hits, suspicious activity
  • System Events - Errors, warnings, service health

Log Information

Each log entry includes (where applicable):

  • Timestamp (ISO 8601 format)
  • Event type and description
  • User identifier (anonymized where appropriate)
  • IP address
  • User agent
  • Request path and method
  • Response status

Log Retention

Audit logs are retained in accordance with our data retention policy and applicable legal requirements. Logs are stored securely and access is restricted to authorized personnel.

7. Infrastructure Security

Hosting Provider: Vercel

Our application is hosted on Vercel, which provides:

  • Global edge network with automatic failover
  • DDoS protection and Web Application Firewall
  • Automatic SSL/TLS certificate management
  • SOC 2 Type II compliant infrastructure
  • ISO 27001 certified data centers

Database: Supabase

User data is stored in Supabase, which provides:

  • PostgreSQL database with Row Level Security
  • Encryption at rest and in transit
  • Regular automated backups
  • SOC 2 Type II compliance
  • Point-in-time recovery capabilities

Queue Storage: Azure

Temporary processing queues use Azure Storage with encryption, access controls, and Microsoft's enterprise security infrastructure.

8. Vulnerability Management

Dependency Management

  • Regular updates of all dependencies
  • Automated vulnerability scanning in CI/CD pipeline
  • Security advisory monitoring for used packages
  • Prompt patching of identified vulnerabilities

Secure Development

  • Security-focused code review for all changes
  • OWASP guidelines for secure coding practices
  • Input validation and output encoding
  • Protection against common vulnerabilities (XSS, CSRF, injection)

Responsible Disclosure

We welcome security researchers to report vulnerabilities responsibly. If you discover a security issue, please email support@ugurlabs.com with details. We will acknowledge your report within 48 hours and work with you to address the issue.

9. Incident Response

Incident Response Process

We maintain documented incident response procedures that include:

  1. Detection - Monitoring systems alert on potential security events
  2. Containment - Immediate action to limit impact
  3. Investigation - Thorough analysis of the incident
  4. Remediation - Fixing the root cause
  5. Communication - Notifying affected parties as required
  6. Post-Incident Review - Learning and improving from the incident

Breach Notification

In the event of a data breach affecting your personal data, we will notify you and relevant supervisory authorities as required by GDPR and other applicable laws. See our Data Processing Agreement for detailed notification procedures.

10. Security Contact

Report Security Issues

If you have security concerns or want to report a vulnerability, please contact us:

Security ContactEmail: support@ugurlabs.com

For urgent security matters, please include "SECURITY" in the subject line.

Related Documents