Security Standards & Protocols: Frameworks, TLS, SSH, IPSec, Cloud & IoT

Core Concepts: What Are Security Standards and Protocols?

1. Definitions and Purpose

Security standards are formalized guidelines (e.g., ISO/IEC 27001, NIST SP 800-53) that define best practices for protecting systems. They ensure interoperability, compliance, and risk mitigation across organizations. Security protocols are rule-based procedures (e.g., TLS, SSH, IPSec) that enforce security measures during data transmission or access control.

Why do they matter?

• Consistency: Uniform security across systems (e.g., banks use PCI-DSS for payment security).
• Trust: Certifications (e.g., ISO 27001) signal reliability to customers (e.g., Daraz’s secure checkout).
• Legality: Compliance avoids fines (e.g., GDPR for EU data protection).

2. Key Security Standards

In the Real World

1. eSewa/Khalti Transactions

   • Protocol Used: TLS 1.3 (for encrypting payment data between your phone and the bank).
   • Standard Applied: PCI-DSS (ensures card details are never stored unencrypted).
   • Risk Mitigated: Man-in-the-middle attacks (e.g., intercepting your OTP during transfer).

2. Ncell’s 4G Network Security

   • Protocol Used: IPSec (secures VPN tunnels for remote workers).
   • Standard Applied: ISO 27001 (protects subscriber data from breaches).
   • Real Example: When you use Ncell’s "Secure WiFi" at hotels, IPSec encrypts your traffic even if the hotel’s network is compromised.

3. Pathao Driver App

   • Protocol Used: SSH (for secure remote login to Pathao’s backend servers).
   • Standard Applied: NIST Guidelines (for secure API authentication between app and servers).
   • Risk Mitigated: Unauthorized access to driver locations or fare data.

3. Core Security Protocols

A. Transport Layer Security (TLS)

How TLS Works: The Handshake Process

sequenceDiagram
    Client->>Server: ClientHello (supports TLS 1.3, cipher suites)
    Server->>Client: ServerHello, Certificate, ServerKeyExchange
    Client->>Server: ClientKeyExchange, Finished (encrypted)
    Server->>Client: Finished (encrypted)
    Note over Client,Server: Symmetric key established for session

Key Features

• Confidentiality: Symmetric encryption (AES) after handshake.
• Integrity: HMAC-SHA256 ensures no tampering.
• Authentication: Server (and optionally client) certificates verify identity.

TLS vs. SSL

Worked Example: Securing a Bank Transfer (e.g., NMB Bank)

1. You enter your credentials on the bank’s website → TLS 1.3 handshake occurs.
2. Your browser verifies the bank’s certificate (issued by a trusted CA like DigiCert).
3. All data (account number, OTP) is encrypted with AES-256.
4. The bank’s server signs responses with HMAC to prevent replay attacks.

Step-by-step packet exchange in TLS 1.3 (Image: Halub3, CC BY-SA 4.0, via Wikimedia Commons)

B. Secure Shell (SSH)

SSH Connection Modes

1. Local Forwarding: Redirects a local port to a remote service (e.g., ssh -L 8080:localhost:80 user@server → access server’s port 80 via local 8080).
2. Remote Forwarding: Exposes a remote port to your local machine (e.g., ssh -R 8080:localhost:80 user@server → others can access your local port 80 via the server’s 8080).

SSH Protocol Layers

classDiagram
    class Transport {
        +Encryption: AES, ChaCha20
        +Compression: zlib
    }
    class UserAuth {
        +Methods: Password, Public Key, Kerberos
    }
    class Connection {
        +Channels: Session, X11, Port Forwarding
    }
    Transport --> UserAuth : Uses
    UserAuth --> Connection : Manages

Real Example: Securing a Remote Database (e.g., Daraz’s Inventory System)

• Daraz’s DevOps team uses SSH to remotely manage database servers.
• Local Forwarding: ssh -L 5432:localhost:5432 db-admin@daraz-server → developers access PostgreSQL via their local port 5432, encrypted over SSH.

C. Internet Protocol Security (IPSec)

IPSec Modes

Security Association (SA) Parameters

Worked Example: NTC’s VPN for Remote Offices

• NTC uses IPSec in Tunnel Mode to connect regional offices to the central network.
• AH ensures no one alters routing headers.
• ESP encrypts all traffic between offices, preventing eavesdropping.

4. Cloud Security: Models and Risks

Cloud Service Models

mindmap
  root((Cloud Security Models))
    SaaS
      +Provider manages apps/data (e.g., Google Workspace).
      +Customer controls: User access, data.
    PaaS
      +Provider manages OS/runtime (e.g., Heroku).
      +Customer controls: Apps, data.
    IaaS
      +Provider manages hardware (e.g., AWS EC2).
      +Customer controls: OS, apps, data.

Security Risks and Countermeasures

Real Example: eSewa’s Cloud Security

• Uses SaaS model (eSewa handles all infrastructure).
• Countermeasures:
  • TLS 1.3 for all API calls.
  • IAM policies to restrict admin access.
  • Regular audits via ISO 27001.

5. IoT Security Challenges

Key Vulnerabilities

1. Weak Default Credentials: Many IoT devices ship with admin:admin.
2. Lack of Encryption: Unencrypted Zigbee/Z-Wave signals in smart homes.
3. Firmware Updates: Rare or unpatched (e.g., vulnerable cameras in hotels).

Security Protocols for IoT

Real Example: Kathmandu Traffic Management

• Problem: Traffic lights use unencrypted radio signals → hackers could cause gridlock.
• Solution: Deploy DTLS to encrypt commands between traffic controllers and central servers.

Exam Tip

1. For Standards (ISO, PCI-DSS, NIST):

   • Memorize 1 key requirement per standard (e.g., PCI-DSS = "encrypt card data").
   • Link to real-world examples (e.g., "Khalti uses PCI-DSS for payments").

2. For Protocols (TLS, SSH, IPSec):

   • Draw diagrams: TLS handshake, SSH forwarding, IPSec modes.
   • Compare: TLS vs SSL, AH vs ESP in IPSec.
   • Worked examples: Always tie to a Nepali context (e.g., "How does Ncell secure its VPN?").

3. For Cloud/IoT:

   • Mindmaps for service models (SaaS/PaaS/IaaS).
   • Risk tables: Match risks to countermeasures (e.g., "DDoS → Cloudflare").

4. Common Pitfalls:

   • Don’t confuse TLS session (reused keys) vs. connection (new handshake).
   • IPSec AH only authenticates, ESP encrypts + authenticates.
   • SSH local forwarding ≠ remote forwarding (exam loves this distinction).