Cloud Firewall Verification via Timelord HTTP Attack Simulation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing firewall solutions for cloud providers are unreliable in distinguishing between acceptable and unacceptable HTTP requests, often relying on IP address identification which is not effective in all scenarios.

Innovation Solution

A system and method involving a timelord module that generates random tokens, sends HTTP attacks with expected responses to the firewall, and compares the firewall's responses to verify the firewall policies, allowing for incremental testing without relying on IP identification.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If IP address identification is used for firewall policy determination, then the firewall can make simple routing decisions, but the reliability of request filtering deteriorates in scenarios where IP identification is ineffective

Engineering Contradiction:
Improvefirewall decision-making simplicityVSAvoidrequest filtering reliability
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

The patent changes the identification parameter from IP address to request characteristics (headers, parameters, content). The timelord module generates test requests with specific characteristics and verifies that the firewall correctly identifies and blocks unacceptable requests based on these characteristics rather than IP addresses, thereby improving filtering reliability while maintaining operational simplicity

Inventive Principle:
Principle #35Parameter changes

Solution Approach 2:

The patent introduces an intermediary verification mechanism (timelord module) that mediates between the firewall and the external environment. This module generates test requests, sends them through the firewall, and verifies the firewall's responses, providing a reliable method to confirm firewall policy effectiveness without requiring complex manual testing

Inventive Principle:
Principle #24Intermediary (Mediator)

2Reliability

If manual firewall testing is performed to verify policy effectiveness, then comprehensive verification can be achieved, but the time and resources required increase significantly

Engineering Contradiction:
Improvefirewall verification completenessVSAvoidverification time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The timelord module performs self-service verification by automatically generating test requests, sending them through the firewall, and evaluating the responses against expected outcomes. This automated self-verification process eliminates the need for manual testing while maintaining comprehensive verification coverage, significantly reducing both time and resource requirements

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system performs preliminary actions by pre-configuring test request templates and expected response criteria before actual verification occurs. The timelord module has ready-made test cases with defined characteristics and expected outcomes, allowing rapid execution of comprehensive verification without time-consuming setup during the actual testing phase

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS11968177B2Systems and methods for verifying a firewall for a cloud provider
Publication Date: 2024.04.23 SALESFORCE INC
  • US11968177B2 patent drawing
  • US11968177B2 patent drawing
  • US11968177B2 patent drawing

AI summary

Systems and methods for verifying a firewall for a cloud provider. The method includes receiving by a timelord module configured with access to a plurality of HTTP attacks that incorporate random tokens, an updated policy ok signal that was generated by an external element. The timelord module responds by (a) loading a first HTTP attack with a first expected response that is either forbidden or accepted, the first HTTP attack including the random tokens in a form of a header key value parameter; (b) sending the first HTTP attack to the firewall; (c) comparing a response from the firewall to the first HTTP attack with the first expected response; and (d) incrementing the first HTTP attack and repeating (a)-(c) until the plurality of HTTP attacks has been sent; and deleting the random tokens after the plurality of HTTP attacks have been sent.