Holistic monitoring system for web resources

Abstract

The present disclosure provides a system for monitoring network resources associated with a computer implemented services session, comprising a dependency discovery engine (121- DDE), configured to receive a uniform resource locator (URL) associated with a network service, and responsively identify network requests and responses associated with the network service, associate each network request with respective responses, perform network request filtering using the "content-type" header to identify responses critical to functionality and security, and extract response URLs to create dependency objects by content type. The system further comprises a monitoring engine (121-ME), configured to monitor relevant data associated with discovered object dependencies, and an alerting engine (121-AE), configured to analyze monitored data across multiple layers to identify root causes and intermediate causes of events.

Description

[0001] Princeton - 105476

[0002] HOLISTIC MONITORING SYSTEM FOR WEB RESOURCES

[0003] CROSS-REFERENCE TO RELATED APPLICATIONS

[0004] This application claims priority to U.S. Provisional Application No. 63 / 725,095, titled “Holistic Monitoring System for Web Resources”, filed November 26, 2024, which is hereby incorporated by reference in its entirety.

[0005] TECHNICAL FIELD

[0006] The present disclosure relates to network monitoring systems, and more particularly to a holistic monitoring system that automatically discovers and monitors all network resource dependencies across multiple layers of the network stack to detect cyber-attacks and identify root causes of outages or performance issues.

[0007] BACKGROUND

[0008] As web resources and applications have grown in complexify, so too have the cyberattacks and availability issues that threaten them. Modem web applications rely on numerous external dependencies, including third-party Application Programming Interfaces (APIs), JavaScript files loaded from external sources, and various other network resources distributed across multiple layers of the network stack. This distributed architecture creates a complex web of interdependencies that can affect both the security and availability of web services.

[0009] Traditional network monitoring systems typically focus on monitoring individual resources for uptime and stability at various layers of the network stack. These systems often employ a straightforward approach of checking specific resources on a loop and generating alerts when requests fail. While this methodology can be extended beyond simple website monitoring to include ports, network topologies, and other network elements, it generally lacks a comprehensive understanding of the complete dependency structure underlying modem web resources.

[0010] Current monitoring approaches face several limitations in addressing the complexities of contemporary web applications. Many monitoring services primarily focus on first-party controlled target webpages while overlooking the numerous third-party dependencies that can significantly impact user experience and system security. This narrow focus can leave substantial portions of a web application's attack surface unmonitored, potentially allowing security threats to go undetected. Princeton - 105476

[0011] The interconnected nature of modem web infrastructure means that a failure or compromise in one component can cascade through multiple layers of dependencies, affecting seemingly unrelated services. Understanding these relationships and their potential impact on overall system performance and security presents ongoing challenges for network administrators and security professionals.

[0012] Additionally, the detection and analysis of sophisticated cyber-attacks often requires correlation of events across multiple network layers and resources. Attacks may manifest as seemingly benign individual events that, when viewed in isolation, do not trigger alerts but collectively indicate the presence of a coordinated security threat. The ability to identify and analyze such patterns across complex dependency structures remains an area where improvements in monitoring technology would be beneficial.

[0013] SUMMARY

[0014] This summary' is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0015] According to an aspect of the present disclosure, a system for monitoring network resources associated with a computer implemented services session is provided. The system comprises a dependency discovery engine, configured to receive a uniform resource locator (URL) associated with a network service, and responsively perform the steps of identifying substantially all network requests and responses associated with the network service. The dependency discovery engine associates with each identified network request any respective responses, performs network request filtering using the "content-type" header of respective network responses to identity' thereby responses of types critical to the functionality and security' of the services session, and for each response critical content ty pe, extracts from the respective identified responses respective response URLs to create thereby a set of dependencyobjects by content type. The system further comprises at least one monitoring engine, configured to monitor relevant data associated with each of the discovered object dependencies, and an alerting engine, configured to analysis monitor relevant data across multiple layers to identity' thereby root causes of events and / or intermediate causes of events. This comprehensive approach enables automatic discovery- of all network dependencies that could affect system security or availability, providing superior threat detection capabilities compared to traditional monitoring systems that focus on individual resources. Princeton - 105476

[0016] According to other aspects of the present disclosure, the system may include one or more of the following features. The network resources being monitored and / or discovered may be associated with a mobile application, application programming interface (API) call, or other mechanism configured to retrieve resources and / or data from the network. This flexibility allows the system to monitor diverse types of network interactions beyond traditional web browsing sessions.

[0017] The services session may be instantiated at a web browser at a client device. This configuration enables monitoring of user-facing web applications and their complete dependency chains from the client perspective.

[0018] The services session may be instantiated at an intermediate network node configured to monitor network traffic passing therethrough. This deployment option provides network-level visibility for monitoring traffic flows across enterprise infrastructure.

[0019] The services session may be instantiated at an edge router associated with an enterprise network and configured to monitor network traffic passing therethrough. This positioning allows comprehensive monitoring of all network traffic entering or leaving an enterprise environment.

[0020] The services session may be configured to provide network services and data to at least one blockchain oracle. This capability addresses the growing need for secure monitoring of blockchain infrastructure and oracle data feeds.

[0021] Additionally, the services session may be configured to provide network services and data to at least one Artificial Intelligence Agent system (Agentic Al). This capability addresses the growing need for secure monitoring of Al infrastructure and Model Context Protocol (MCP) Servers.

[0022] The alerting engine may provide alerts designed for the use in blockchain smart contracts. This feature enables integration with blockchain-based systems for automated security responses.

[0023] The system may further comprise a graph construction engine, configured to process the set of dependency objects to generate thereby a structured dependency graph depicting relationships between at least some of the dependency objects and optionally including dependency object descriptions. This graph-based representation enables sophisticated analysis of complex interdependencies across multiple network layers.

[0024] The structured dependency graph may represent the relationship between at least some of the dependencies discovered by the dependency discovery engine. This selective representation allows for focused analysis of the most relevant dependencies. Princeton - 105476

[0025] The structured dependency graph may represent the relationship between all dependencies discovered by the dependency discovery engine. This comprehensive representation provides complete visibility into the entire dependency structure.

[0026] The system may further comprise a visualization engine, configured for visualizing the dependency graph and the active alerts via an annotated, color coded, and icon-based view of the dependency graph with organizational structures designed to help operators clearly see what is going on. This visual interface significantly improves operator efficiency in understanding complex network relationships and identifying security threats.

[0027] The system may further comprise enterprise services applications, configured for managing the discovering and identifying type of enterprise resources associated with network request and responses, the generating of a structured dependency graph depicting relationships between enterprise dependency objects and including enterprise dependency object descriptions, and the monitoring of relevant data associated with each of the enterprise object dependencies within the dependency graph. This enterprise integration capability enables seamless deployment within existing corporate IT infrastructure.

[0028] The system may further comprise a commercial monitoring tool configured for managing the discovering and identifying type of at least a subset of resources associated with network request and responses, the generating of a structured dependency graph depicting relationships between the subset of dependency objects and including dependency object descriptions, and the monitoring of relevant data associated with at least the subset of dependency objects. This modular approach allows integration with existing monitoring solutions while extending their capabilities.

[0029] The commercial monitoring tool may be configured as a Software as a Service (SaaS) tool. This deployment model provides scalable, cloud-based monitoring capabilities without requiring on-premises infrastructure.

[0030] The dependency discovery engine may be configured to ignore those content types selected as not posing a significant security or availability7risk. This filtering capability7reduces monitoring overhead by focusing on the most relevant resources.

[0031] The content types may include images and / or fonts. This specific filtering helps eliminate low-risk resources that typically do not affect system security or functionality.

[0032] The dependency discovery7engine may be implemented via a web-browser automation framework. This implementation approach leverages existing browser technologies for realistic dependency discovery. Princeton - 105476

[0033] The web-browser automation framework may comprise a Selenium framework instantiated within a browser program. This specific implementation provides robust and widely-supported browser automation capabilities.

[0034] The dependency discovery engine may be implemented in response to user interaction with a web service in a browser being monitored by the dependency discovery engine. This interactive monitoring capability captures real-world usage patterns and their associated dependencies.

[0035] The dependency discovery engine may be further configured to package all dependency URLs and the full-graph domain name system (DNS) lookups of the domains in these URLs into a JavaScript Object Notation (JSON) dependency object that represents the attack surface for the target web service. This structured data format enables efficient processing and analysis of complex dependency relationships.

[0036] The monitoring engine may be further configured to raise alerts or record discrepancies that could lead to an alert based on monitored relevant data. This proactive alerting capability enables rapid response to potential security threats or availability issues.

[0037] Each of a plurality of monitoring engines may be configured to monitor a respective type of dependency object, each dependency object being monitored using one or more monitoring techniques associated with that ty pe of dependency object. This specialized monitoring approach optimizes detection capabilities for different types of network resources.

[0038] Each of a plurality of monitoring engines may be located in a respective geographic region of the network. This distributed monitoring architecture provides global visibility and reduces the impact of regional network issues on monitoring effectiveness.

[0039] According to another aspect of the present disclosure, a computer implemented method for monitoring network resources associated with a web browser session is provided. The method comprises receiving a uniform resource locator (URL) associated with a network service, and iteratively performing the following steps until substantially all network resources associated with the network service have been processed: identifying substantially all network requests and responses associated with the netyvork service, associating with each identified network request any respective responses, performing netyvork request filtering using the "content-type" header of respective network responses to identify thereby responses of types critical to the functionality and security of the yveb browser session, and for each response critical content type, extracting from the respective identified responses respective response URLs to create thereby a set of dependency objects by content fype. The method further comprises monitoring relevant data associated with each of the discovered object Princeton - 105476 dependencies, and analyzing monitored relevant data across multiple layers to identify thereby root causes of events and / or intermediate causes of events. This methodical approach ensures comprehensive coverage of all network dependencies while providing actionable intelligence for security and availability management.

[0040] According to other aspects of the present disclosure, the method may include one or more of the following features. The method may further comprise processing the set of dependency objects to generate thereby a structured dependency graph depicting relationships between the dependency objects and dependency object descriptions for monitoring. This graph generation capability enables sophisticated analysis of complex network relationships.

[0041] The structured dependency graph may represent the relationship between at least some of the dependencies discovered by the dependency discovery engine. This selective representation allows for focused analysis of the most relevant dependencies.

[0042] The structured dependency graph may represent the relationship between all dependencies discovered by the dependency discovery engine. This comprehensive representation provides complete visibility’ into the entire dependency structure.

[0043] The method may further comprise visualizing the dependency graph and the active alerts via an annotated, color coded, and icon-based view of the dependency graph with organizational structures designed to help operators clearly see what is going on. This visualization capability significantly improves operator efficiency in understanding and responding to security threats.

[0044] The method may be implemented by one or more enterprise services applications configured for managing the discovering and identifying type of enterprise resources associated with network request and responses, the generating of a structured dependency graph depicting relationships between enterprise dependency objects and including enterprise dependency object descriptions, and the monitoring of relevant data associated with each of the enterprise object dependencies within the dependency graph. This enterprise integration enables seamless deployment within existing corporate environments.

[0045] The method may be implemented as a commercial monitoring tool configured for managing the discovering and identifying type of at least a subset of resources associated with network request and responses, the generating of a structured dependency graph depicting relationships between the subset of dependency objects and including dependency object descriptions, and the monitoring of relevant data associated with at least the subset of dependency objects. This commercial implementation provides flexible deployment options for various organizational needs. Princeton - 105476

[0046] The identifying may be configured to ignore those content types selected as not posing a significant security or availability risk. This filtering capability optimizes monitoring efficiency by focusing on the most relevant resources.

[0047] The content types may include images and / or fonts. This specific filtering helps eliminate low-risk resources that do not typically affect system security or functionality.

[0048] The method may be implemented via a web-browser automation framework. This implementation approach leverages proven browser technologies for realistic dependency discovery.

[0049] The web-browser automation framework may comprise a Selenium framework instantiated within a browser program. This specific implementation provides robust and widely-supported automation capabilities.

[0050] The method may be implemented in response to user interaction with a web service in a browser being monitored by the dependency discovery engine. This interactive approach captures real-world usage patterns and their associated dependencies.

[0051] The method may further comprise packaging all dependency URLs and the full-graph DNS lookups of the domains in these URLs into a JSON dependency object that represents the attack surface for the target web service. This structured packaging enables efficient processing and analysis of complex dependency data.

[0052] The method may further comprise raising alerts or recording discrepancies that could lead to an alert based on monitored relevant data. This proactive alerting capability enables rapid response to potential threats or issues.

[0053] Each of a plurality of monitoring engines may be configured to monitor a respective type of dependency object, each dependency object being monitored using one or more monitoring techniques associated with that type of dependency object. This specialized approach optimizes monitoring effectiveness for different resource types.

[0054] Each of the plurality of monitoring engines may be located in a respective geographic region of the network. This distributed architecture provides comprehensive global monitoring coverage.

[0055] According to another aspect of the present disclosure, a computer implemented method for discovering within a network one or more Domain Name System (DNS) servers associated with a network resource identified by a uniform resource locator (URL) is provided. The method comprises recursively resolving and querying the names of nameservers associated with a DNS resolution of the network resource identified by a uniform resource locator (URL) to determine thereby all dependency URLs and the full-graph DNS lookups of the domains in Princeton - 105476 these URLs. This comprehensive DNS discovery approach provides complete visibility^ into the DNS infrastructure that could affect network resource availability and security.

[0056] According to another aspect of the present disclosure, a computer implemented method for discovering within a network one or more Domain Name System (DNS) servers associated with a network resource identified by a uniform resource locator (URL) is provided. The method comprises recursively resolving and querying the names of nameservers associated with a DNS resolution of the network resource identified by a uniform resource locator (URL) to determine thereby nameservers responsible for resolving the names of nameservers that are associated with a DNS resolution, any multiple levels of the resolved nameservers, and nameserver resolution along canonical name (CNAME) and / or delegation name (DNAME) chains. This thorough DNS analysis capability enables detection of sophisticated attacks that target DNS infrastructure at multiple levels of the resolution hierarchy.

[0057] The foregoing general description of the illustrative embodiments and the following detailed description thereof are merely exemplary' aspects of the teachings of this disclosure and are not restrictive.

[0058] BRIEF DESCRIPTION OF FIGURES

[0059] Non-limiting and non-exhaustive examples are described with reference to the following figures.

[0060] FIG. 1 illustrates a block diagram of a system for monitoring network resources.

[0061] FIG. 2 illustrates an example dependency graph, where all resources shown are monitored by Layer? monitoring; a traditional monitoring system that only monitors webpages, web servers, and DNS records would only monitor the resources shown in gray.

[0062] DETAILED DESCRIPTION

[0063] The following description sets forth exemplary aspects of the present disclosure. It should be recognized, however, that such description is not intended as a limitation on the scope of the present disclosure. Rather, the description also encompasses combinations and modifications to those exemplary aspects described herein.

[0064] Referring to FIG. 1, a system 100 for monitoring network resources associated with a computer implemented services session may be provided. The system 100 may comprise computing resources 105 that include various components configured to perform holistic monitoring of network dependencies and resources. The computing resources may include one or more data processing elements, computing devices, network elements, and the like, Princeton - 105476 cooperating as described herein to implement various techniques. Not all of the described data processing elements (such as one or more processing units), computing devices, network elements, and the like are necessary to implement each embodiment.

[0065] As used herein, the term "processing unit" may refer to a computational component configured to execute instructions and perform data processing operations. A processing unit may include various types of processors such as central processing units (CPUs), graphics processing units (GPUs), digital signal processors (DSPs), microprocessors, microcontrollers, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or other specialized processing circuits. The processing unit may be implemented as a single core or multi-core architecture and may operate independently or in coordination with other processing units within a computing system. In some cases, a processing unit may include associated memory, cache, and input / output interfaces that enable the processing unit to access data and communicate with other system components.

[0066] The systems may be implemented via, e.g., one or more servers, workstations, and / or other computer and memory -providing devices operating in accordance with the various embodiments. The system may be implemented, e.g., within the context of one or more data centers having instantiated thereof computed and memory / storage resources configured as disclosed herein.

[0067] The computing resources 105 may include a system manager 110 and compute (e.g., processing) and storage (e.g., memory) resources 120. where the system manager 110 may control and coordinate operations of the various monitoring components within the system 100.

[0068] The compute and storage resources 120 may include several specialized engines configured to perform different aspects of network resource monitoring. A dependency discovery’ engine 121 -DDE may be configured to receive a uniform resource locator (URL) associated with a network sendee and responsively perform various steps to identify network dependencies. The dependency discovery engine 121-DDE may identify substantially all network requests and responses associated with the network service by monitoring network traffic and browser interactions. In some cases, the dependency discovery’ engine 121-DDE may associate with each identified network request any respective responses to create complete request-response pairs for analysis.

[0069] The dependency discovery' engine 121-DDE may perform network request filtering using the "content-type" header of respective network responses to identify responses of types that may be considered relevant to the functionality and security of the services session. For each response with content types determined to be relevant, the dependency discovery engine Princeton - 105476

[0070] 121-DDE may extract from the respective identified responses respective response URLs to create a set of dependency objects by content type. In some cases, the dependency discovery engine 121-DDE may filter out content t pes such as images or fonts that may not pose significant security or availability risks, while focusing on content types such as HTML, JavaScript, and other resources that may be more relevant to system security and functionality.

[0071] At least one monitoring engine 121 -ME may be configured to monitor relevant data associated with each of the discovered object dependencies. The monitoring engine 121 -ME may track various aspects of the identified dependencies across multiple layers of the network stack, including application layer resources, DNS infrastructure, and network routing information. In some cases, multiple monitoring engines 121 -ME may be deployed, where each monitoring engine 121 -ME may be configured to monitor a respective type of dependency object using monitoring techniques associated with that particular type of dependency object.

[0072] An alerting engine 121 -AE may be configured to analyze monitored relevant data across multiple layers to identify root causes of events and intermediate causes of events. The alerting engine 121-AE may process alerts and monitoring data from various sources to correlate events across different network layers and dependency relationships. In some cases, the alerting engine 121-AE may utilize dependency relationship information to prioritize alerts and identity7causal relationships between events occurring at different layers of the network infrastructure.

[0073] As shown in FIG. 2. the system 100 may monitor complex dependency relationships between various network resources. The dependency relationships may span multiple layers of network infrastructure, from application-level resources such as web pages dow n through DNS resolution systems and network routing protocols. The system 100 may track dependencies between domain resources, web servers, DNS records, and BGP routing information to provide comprehensive monitoring coverage of the complete attack surface associated with a target network service.

[0074] With continued reference to FIG. 1, the system 100 may be configured to monitor network resources associated with various types of applications and services beyond traditional web browser sessions. In some cases, the network resources being monitored and discovered by the dependency discovery engine 121-DDE may be associated with a mobile application, application programming interface (API) call, or other mechanism configured to retrieve resources and data from the network. The dependency discovery engine 121-DDE may analyze network traffic generated by mobile applications to identify dependencies on external services, Princeton - 105476 third-party libraries, and backend APIs that may affect the security and availability of the mobile application.

[0075] The system 100 may be deployed in various configurations to accommodate different monitoring requirements and network architectures. In some cases, the services session may be instantiated at a web browser at a client device, where the dependency discovery engine 121-DDE may monitor browser interactions and network requests directly from the client perspective. The system 100 may utilize presentation devices 102 and input devices 103 connected through input / output resources 130 to enable user interaction with monitored services and to display monitoring results and alerts to operators.

[0076] In alternative deployment configurations, the services session may be instantiated at an intermediate network node configured to monitor network traffic passing therethrough. The intermediate network node may be positioned within access and core networks 108 to capture and analyze network traffic flows between clients and servers. The communication resources 140 may facilitate connectivity between the computing resources 105 and the access and core networks 108 to enable monitoring of network traffic at strategic points within the network infrastructure.

[0077] The services session may also be instantiated at an edge router associated with an enterprise network and configured to monitor network traffic passing therethrough. In such deployments, the edge router may be positioned at the boundary of an enterprise network to monitor all incoming and outgoing network communications. A network admin 104 may interact with the system 100 through the access and core networks 108 to configure monitoring parameters and review alerts generated by the alerting engine 121-AE.

[0078] The monitoring engine 121-ME may be configured to operate across these various deployment scenarios, adapting monitoring techniques based on the specific network position and available data sources. In some cases, multiple monitoring engines 121-ME may be distributed across different geographic regions of the network to provide comprehensive coverage and to detect localized network issues or attacks that may not be visible from a single monitoring location.

[0079] The system may be configured to provide specialized monitoring capabilities for blockchain-based applications and decentralized systems. In some cases, the services session may be configured to provide network services and data to at least one blockchain oracle. Blockchain oracles may serve as intermediaries that retrieve off-chain information and provide such information for on-chain usage in smart contracts and other blockchain applications. The dependency discovery engine may analyze network requests and responses generated by Princeton - 105476 blockchain oracles when accessing external data sources, identifying dependencies on web services, APIs, and other network resources that may affect the reliability’ and security of data provided to blockchain systems.

[0080] The monitoring capabilities may extend to tracking the complete network infrastructure supporting blockchain oracle operations. The dependency discovery engine may identify web services contacted by blockchain oracles, including price feeds, data APIs, and authentication services that may be targeted by attackers seeking to compromise blockchain applications. The monitoring engine may track the availability and integrity of these external data sources, detecting changes in network routing, DNS resolution, or certificate issuance that may indicate potential attacks on the oracle data supply chain.

[0081] The alerting engine may provide alerts designed for use in blockchain smart contracts. These alerts may be formatted and structured specifically for consumption by smart contract code, enabling automated responses to detected security threats or availability issues. The alerts may include information about the security status of monitored network resources, detected attacks on dependencies, and assessments of data source reliability that may be used by smart contracts to make informed decisions about whether to proceed with transactions or operations.

[0082] In some cases, the alerting engine may provide on-chain alert provision via blockchain oracles to validate data authenticity retrieved by other oracles. The system may operate a specialized blockchain oracle that publishes monitoring results and security assessments directly to blockchain networks. Smart contracts may query this monitoring oracle to obtain information about the security status of external data sources before accepting data from other oracles. This approach may enable smart contracts to implement additional validation layers, rejecting data from sources that the monitoring system has identified as potentially compromised or under attack.

[0083] The monitoring system may detect various types of attacks that could affect blockchain oracle operations, including BGP hijacks targeting data source servers, certificate mis-issuance for oracle data endpoints, and DNS manipulation attacks designed to redirect oracle queries to malicious servers. The alerting engine may correlate these network-level attacks with blockchain oracle activity, providing alerts that enable smart contracts to temporarily suspend operations or seek alternative data sources when primary sources may be compromised.

[0084] The monitoring capabilities may extend to tracking the network infrastructure supporting Artificial Intelligence (Al) systems and monitor the infrastructure dependencies of these systems. In addition to monitoring of the API endpoints used by Al systems (e.g., to access Large Language Models or LLMs), Model Context Protocol (MCP) provides data and Princeton - 105476 extends the capabilities of Al Agents (a.k.a. Agentic Al). As used herein, “Agentic Al” and “Agentic Al system” generally refers to an Al-driven control architecture that, given an objective and operational constraints, determines and carries out a sequence of actions — potentially including tool invocations — while adapting the sequence based on intermediate results, without requiring a user to specify each action. Such Agentic Al is well understood in the art. The monitoring system may detect various types of attacks that could affect MCP. These attacks include BGP and DNS attacks on MCP end points as well as interception of communication to MCP endpoints via malicious TLS certificates. The monitoring system can be used to correlate changes in MCP endpoint behavior with events in the underlying network resources that host those MCP endpoints. This allows the monitoring system to deliver effective and timely alerts on attacks affecting MCP endpoints and assess the integrity of MCP endpoints in real time. Data on the integrity of MCP endpoints can be delivered to Al systems allowing the Al systems to temporarily suspend communication with affected MCP endpoints or exercise appropriate protective measures.

[0085] With continued reference to FIG. 1, a graph construction engine 121 -GCE may be configured to process the set of dependency objects to generate a structured dependency graph depicting relationships between at least some of the dependency objects and optionally including dependency object descriptions. The graph construction engine 121-GCE may receive dependency objects from the dependency discovery engine 121-DDE and transform these objects into a comprehensive graph structure that represents the interconnections and dependencies between various network resources across multiple layers of the network stack.

[0086] The graph construction engine 121-GCE may build the structured dependency graph with a central node representing the primary monitoring target, such as a target URL or web service. The graph construction engine 121-GCE may then add URL dependencies, such as JavaScript files and HTML resources discovered by the dependency discovery engine 121- DDE, as nodes connected via edges to the primary monitoring target. Domain nodes associated with the URL dependencies may be added to the structured dependency graph, followed by IP addresses and DNS resolution results associated with those domains.

[0087] As shown in FIG. 2, the structured dependency graph may represent complex relationships between various network resources spanning multiple layers of network infrastructure. The structured dependency graph may include domain elements, web server components, DNS records, and BGP routing information, where directed edges may represent dependency relationships between these resources. The graph construction engine 121-GCE Princeton - 105476 may create these directed edges to show how one resource depends on the operation of another resource within the network infrastructure.

[0088] The graph construction engine 121-GCE may expand some dependencies into multiple nodes because these dependencies may exist at multiple layers of the network stack. In some cases, the graph construction engine 121-GCE may represent a host IP address that runs either a webserver or nameserver at both dataplane and control plane layers. The graph construction engine 121-GCE may express host IP addresses at two distinct layers: once at a dataplane layer that may be monitored via traceroute and ping operations, and once at a BGP layer that may be used for BGP monitoring. The graph construction engine 121-GCE may add an edge between the dataplane layer and the BGP layer to represent that dataplane connectivity depends on BGP connectivity.

[0089] The structured dependency graph may represent the relationship between at least some of the dependencies discovered by the dependency discovery engine 121 -DDE. In some cases, the structured dependency graph may represent the relationship between all dependencies discovered by the dependency discovery engine 121 -DDE, providing comprehensive coverage of the complete attack surface associated with the monitored network service. The graph construction engine 121-GCE may label nodes within the structured dependency graph with type properties that indicate what ty pe of resource each node represents, such as a host, domain, or JavaScript file, enabling the monitoring engine 121-ME to determine which types of monitoring techniques may be applied to each node.

[0090] The graph construction engine 121 -GCE may include additional information about why each node was included in the structured dependency graph, such as whether the node was discovered through a JavaScript dependency or a DNS dependency. This labeling may facilitate filtering operations and enable operators to focus on specific types of dependencies when analyzing the structured dependency graph. The graph construction engine 121-GCE may store the structured dependency graph in a format that may be accessed by other components of the system 100, including the monitoring engine 121-ME and the alerting engine 121-AE, to enable coordinated monitoring and analysis operations across the complete dependency structure.

[0091] With continued reference to FIG. 1, a visualization engine 121 -VE may be configured for visualizing the dependency graph and the active alerts via an annotated, color coded, and icon-based view of the dependency graph with organizational structures designed to help operators clearly see what is going on. The visualization engine 121-VE may receive the structured dependency graph from the graph construction engine 121-GCE and alert information from the alerting engine 121-AE to create comprehensive visual representations Princeton - 105476 that enable network administrators and operators to understand complex dependency relationships and monitoring status.

[0092] The visualization engine 121 -VE may render the structured dependency graph using various visual elements to distinguish between different types of network resources and their relationships. In some cases, the visualization engine 121-VE may assign unique icons to different node types within the structured dependency graph, such as distinct icons for web servers, DNS servers, domain names, and JavaScript files. The visualization engine 121-VE may apply color coding to nodes based on their dependency type, resource category, or current monitoring status, enabling operators to quickly identify different classes of resources within the complex network infrastructure.

[0093] As shown in FIG. 2. the visualization engine 121-VE may display dependency relationships between various network components using directional connections that illustrate how resources depend on one another across multiple network layers. The visualization engine 121-VE may annotate these connections with descriptive information about the nature of each dependency relationship, such as whether a dependency represents a DNS resolution requirement, a content loading relationship, or a network routing dependency.

[0094] The visualization engine 121-VE may incorporate active alert information into the visual representation of the structured dependency graph. In some cases, the visualization engine 121-VE may modify the color and appearance of nodes that have active alerts, using distinct colors or visual indicators to draw attention to resources experiencing issues or security concerns. The visualization engine 121 -VE may apply different visual treatments to distinguish between different types of alerts, such as availability issues, security threats, or performance degradation.

[0095] The visualization engine 121-VE may implement node clustering capabilities to reduce graph complexity and improve human interpretability. The visualization engine 121-VE may identify' nodes of the same type that have the same set of dependencies and cluster these nodes together into simplified visual representations. In some cases, the visualization engine 121-VE may cluster multiple JavaScript files that are all hosted by the same domain and used by the same downstream dependency, presenting them as a single clustered node rather than individual nodes to reduce visual complexity.

[0096] The visualization engine 121-VE may provide filtering capabilities that enable operators to focus on specific aspects of the structured dependency graph. The visualization engine 121-VE may utilize tags added by the graph construction engine 121-GCE to enable filtering operations that remove resources associated with particular dependency types from Princeton - 105476 the visual display. In some cases, operators may use filtering capabilities to remove JavaScript dependencies from the visualization when investigating HTML page behavior independently of loaded JavaScript resources, thereby simplifying the graph structure for focused analysis.

[0097] The visualization engine 121-VE may generate timeseries plots and historical data visualizations based on monitoring data collected by the monitoring engine 121-ME. These visualizations may enable operators to observe trends and patterns in resource behavior over time, identifying gradual changes or recurring issues that may not be apparent from instantaneous alert information alone. The visualization engine 121-VE may correlate these temporal visualizations with the structured dependency graph to show how changes in one resource may affect dependent resources over time.

[0098] The visualization engine 121-VE may provide interactive capabilities that enable operators to explore the structured dependency graph in detail. Operators may interact with the visualization through the presentation devices 102 and input devices 103 connected via the input / output resources 130 to access detailed information about specific nodes, view alert details, and navigate through different levels of the dependency hierarchy. The visualization engine 121-VE may enable operators to expand clustered nodes to view individual resources or to collapse complex sections of the graph to focus on higher-level dependency relationships.

[0099] With continued reference to FIG. 1, the system 100 may further comprise enterprise services applications 121 -ESA configured for managing specialized monitoring operations within enterprise network environments. The enterprise services applications 121-ESA may be configured for managing the discovering and identifying type of enterprise resources associated with network request and responses. In some cases, the enterprise sendees applications 121- ESA may focus on enterprise-specific resources such as internal web applications, corporate authentication systems, and proprietary’ APIs that may be used within enterprise network infrastructures.

[0100] The enterprise services applications 121-ESA may be configured for generating a structured dependency graph depicting relationships between enterprise dependency objects and including enterprise dependency object descriptions. The enterprise services applications 121-ESA may work in coordination with the graph construction engine 121-GCE to create specialized dependency graphs that account for enterprise-specific network architectures and security' requirements. In some cases, the enterprise services applications 121-ESA may identify' dependencies on internal directory services, enterprise single sign-on systems, and corporate network infrastructure components that may not be visible to external monitoring systems. Princeton - 105476

[0101] The enterprise services applications 121-ESA may be configured for monitoring relevant data associated with each of the enterprise object dependencies within the dependency graph. The enterprise services applications 121-ESA may implement monitoring techniques specifically adapted for enterprise environments, such as monitoring of internal DNS servers, corporate certificate authorities, and enterprise application servers. The enterprise services applications 121-ESA may coordinate with the monitoring engine 121 -ME to provide comprehensive coverage of both internal enterprise resources and external dependencies that may affect enterprise service availability and security.

[0102] The enterprise services applications 121-ESA may interface with existing enterprise management systems and security tools to integrate monitoring data with corporate security information and event management (SIEM) systems. In some cases, the enterprise services applications 121-ESA may provide alerts and monitoring data to enterprise security teams through the presentation devices 102 and may receive configuration updates from the network admin 104 through the input / output resources 130.

[0103] The system 100 may further comprise commercial monitoring tools 121-S / CMT configured for managing the discovering and identifying type of at least a subset of resources associated with network request and responses. The commercial monitoring tools 121-S / CMT may provide integration capabilities with third-party monitoring services and external security7platforms. In some cases, the commercial monitoring tools 121-S / CMT may focus on specific categories of network resources or may provide specialized monitoring capabilities for particular types of applications or services.

[0104] The commercial monitoring tools 121-S / CMT may be configured for generating a structured dependency graph depicting relationships between the subset of dependency objects and including dependency object descriptions. The commercial monitoring tools 121-S / CMT may work in conjunction with the graph construction engine 121 -GCE to create focused dependency graphs that represent specific subsets of the complete network infrastructure. The commercial monitoring tools 121-S / CMT may enable selective monitoring of particular resource types or network layers based on specific monitoring requirements or licensing constraints.

[0105] The commercial monitoring tools 121-S / CMT may be configured for monitoring relevant data associated with at least the subset of dependency objects. The commercial monitoring tools 121-S / CMT may implement specialized monitoring techniques provided by third-party vendors or may integrate with existing commercial monitoring platforms to extend the capabilities of the system 100. In some cases, the commercial monitoring tools 121-S / CMT Princeton - 105476 may provide access to proprietary threat intelligence feeds, specialized attack detection algorithms, or commercial databases of network security information.

[0106] In some cases, the commercial monitoring tools 121-S / CMT may be configured as a Software as a Service tool. The Software as a Service configuration may enable the commercial monitoring tools 121-S / CMT to operate as cloud-based sendees that may be accessed through the communication resources 140 and the access and core networks 108. The Software as a Service configuration may provide scalable monitoring capabilities without requiring local installation of monitoring software or maintenance of monitoring infrastructure.

[0107] The commercial monitoring tools 121-S / CMT configured as Software as a Service tools may provide subscription-based access to specialized monitoring capabilities, threat intelligence databases, and commercial security services. The Software as a Service configuration may enable automatic updates to monitoring algorithms and threat detection capabilities without requiring manual software updates or system maintenance. In some cases, the Software as a Service configuration may provide access to geographically distributed monitoring infrastructure that may complement the monitoring capabilities provided by the monitoring engine 121 -ME.

[0108] The enterprise services applications 121 -ESA and the commercial monitoring tools 121-S / CMT may coordinate with other components of the system 100 to provide comprehensive monitoring coverage. The alerting engine 121-AE may receive alert data from both the enterprise services applications 121 -ESA and the commercial monitoring tools 121- S / CMT to enable correlation of events across enterprise-specific resources and commercial monitoring platforms. The visualization engine 121-VE may incorporate monitoring data from these specialized components to provide unified visualizations that include both enterprise resources and commercially monitored dependencies within the structured dependency graph.

[0109] The dependency discovery engine may implement content type filtering mechanisms to focus monitoring efforts on network resources that may pose security or availability risks to the monitored services session. The dependency discovery engine may be configured to ignore those content types selected as not posing a significant security or availability risk. This filtering approach may enable the dependency discovery engine to prioritize monitoring resources while reducing computational overhead and alert noise that may result from monitoring less relevant network resources.

[0110] The content type filtering process may analyze the "content-type" header of network responses received during the monitoring of network requests and responses associated with the network service. The dependency discovery engine may evaluate each response header to Princeton - 105476 determine whether the associated content type may be relevant to the functionality and security of the services session. In some cases, the dependency discovery engine may maintain a list or database of content types that may be considered low-risk for security and availability purposes.

[0111] The content ty pes that may be ignored by the dependency discover}' engine may include images and fonts. Image content types such as JPEG, PNG, GIF. and other graphical formats may be filtered out because these resources may not typically execute code or affect the functional behavior of web applications in ways that could compromise security. Similarly, font files such as TrueType fonts, Web Open Font Format files, and other typography resources may be excluded from monitoring because these resources may primarily affect visual presentation rather than application functionality or security.

[0112] The dependency discovery engine may focus monitoring efforts on content types that may be considered performance and security sensitive for the services session. These content types may include HTML documents, JavaScript files, Cascading Sty le Sheets that may contain executable content, XML configuration files. JSON data files, and other resources that may affect application behavior or contain executable code. The dependency discovery engine may prioritize these content types because they may have the potential to alter application functionality7, execute malicious code, or affect the security' posture of the monitored service.

[0113] The filtering process may be configurable to accommodate different monitoring requirements and security policies. In some cases, the dependency discovery engine may allow administrators to modify the list of ignored content types based on specific application requirements or security concerns. The dependency discover ' engine may also provide options to include typically ignored content types in monitoring operations when comprehensive coverage may be desired for particular applications or security assessments.

[0114] The content type filtering may operate in conjunction with other filtering mechanisms implemented by the dependency discover}' engine. The dependency discover}' engine may combine content ty pe filtering with URL pattern filtering, domain-based filtering, and other criteria to create comprehensive filtering rules that focus monitoring efforts on the most relevant network resources. This multi-layered filtering approach may enable the dependency discover}' engine to create focused sets of dependency objects that represent the most security and performance-relevant aspects of the monitored network service.

[0115] The dependency discovery engine may be implemented via a web-browser automation framework to enable comprehensive monitoring of network requests and responses during browser sessions. The web-browser automation framework may provide programmatic control Princeton - 105476 over browser operations, enabling the dependency discovery engine to capture detailed network activity data that may not be accessible through other monitoring approaches. The web-browser automation framework implementation may enable the dependency discovery engine to observe all network requests generated during the loading and interaction with web services, including requests for HTML documents, JavaScript fdes, stylesheets, and other resources that may be loaded dynamically during browser operation.

[0116] The web-browser automation framework may comprise a Selenium framework instantiated within a browser program. The Selenium framework may provide a standardized interface for controlling web browsers programmatically, enabling the dependency discovery engine to automate browser interactions while capturing comprehensive network activity data. The Selenium framework may support multiple browser types and may provide consistent APIs for browser control across different browser implementations, enabling the dependency discovery' engine to operate with various browser configurations.

[0117] The browser program used with the Selenium framework may comprise a Chrome web browser that may be instrumented to provide detailed network logging capabilities. The Chrome web browser instrumentation may enable the dependency discovery engine to access debug network logs that contain comprehensive information about all network requests and responses generated during browser sessions. The Chrome web browser may provide detailed logging of network activity through its DevTools protocol, which may be accessed by the Selenium framework to extract network request and response data for analysis by the dependency discovery engine.

[0118] The Selenium framework instantiated within the Chrome browser program may enable the dependency discovery' engine to open target URLs automatically and monitor all associated network activity. The Selenium framework may control the Chrome browser to navigate to specified URLs, execute JavaScript code, and interact with web page elements while the dependency discovery' engine captures all resulting network requests and responses. The Chrome browser instrumentation may provide access to detailed timing information, request headers, response headers, and content type information that may be used by the dependency discovery' engine to perform content type filtering and dependency analysis.

[0119] The dependency discovery engine may be implemented in response to user interaction with a web service in a browser being monitored by the dependency discovery' engine. This implementation approach may enable the dependency discovery' engine to monitor entire web browsing sessions that involve manual user interactions rather than limiting monitoring to automated URL processing. The dependency discovery engine may monitor a browser session Princeton - 105476 where a user manually navigates through web applications, logs into services, and performs various interactions with web-based systems.

[0120] The manual user interaction monitoring capability may enable the dependency discovery engine to capture dependencies that may only be discovered through interactive use of web sendees. In some cases, web applications may load different resources or contact different services based on user actions such as login procedures, form submissions, or navigation through different sections of an application. The dependency discovery engine may monitor these interactive sessions to identify dependencies on authentication services, userspecific content delivery’ networks, and dynamic resource loading that may not be apparent from simple automated URL fetching.

[0121] The dependency discovery engine may extract debug network logs from the monitored browser session regardless of whether the session involves automated navigation through the Selenium framework or manual user interaction. The Chrome browser instrumentation may provide consistent network logging capabilities for both automated and manual browsing sessions, enabling the dependency discovery engine to apply the same network request filtering and dependency extraction processes to both types of sessions.

[0122] The manual session monitoring capability may enable the dependency discovery engine to discover dependencies associated with complex web transactions that may involve multiple steps or user authentication. In some cases, enterprise web applications may require users to log into employee accounts, navigate through human resources self-service websites, or interact with third-party authentication providers such as two-factor authentication services. The dependency discovery7engine may monitor these complete transaction flows to identify7all network resources and services that may be contacted during the user interaction, including external authentication APIs and third-party service providers that may affect the security and availability of the overall web service.

[0123] The browser session monitoring may capture network requests generated by JavaScript code execution, AJAX requests, WebSocket connections, and other dynamic network activity that may occur during user interaction with web services. The dependency discovery engine may analyze these dynamic network requests using the same content type filtering and URL extraction processes applied to initial page load requests, enabling comprehensive discovery of all network dependencies regardless of when or how they may be generated during the browser session.

[0124] The dependency discovery engine may be further configured to package all dependency URLs and the full-graph DNS lookups of the domains in these URLs into a JSON dependency Princeton - 105476 object that represents the attack surface for the target web service. The JSON dependency object may serve as a comprehensive data structure that encapsulates all discovered network dependencies and their associated DNS infrastructure information in a format that may be processed by other components of the system 100. The JSON formatting may provide a standardized and machine-readable representation of the complete attack surface that may be easily transmitted between different engines within the system 100 and stored in persistent storage systems.

[0125] The dependency discovery engine may implement full-graph DNS resolution that recursively discovers all nameservers associated with the domains identified in the dependency URLs. The full-graph DNS resolution process may extend beyond simple domain name lookups to comprehensively map the complete DNS infrastructure that supports each discovered domain. The dependency discovery engine may recursively resolve domain names and record the IP addresses of all nameservers involved in the DNS lookup process, including both authoritative nameservers and intermediate nameservers that may be contacted during the resolution process.

[0126] The full-graph DNS resolution may include discovery of glued namesen’ er IP addresses that may be included in the "Additional" section of DNS responses. Glued nameserver records may provide IP addresses for nameservers within the same domain zone, enabling the dependency discovery engine to identify nameserver infrastructure that may be directly included in DNS response packets. The dependency discovery engine may extract these glued nameserver IP addresses and include them in the comprehensive mapping of DNS infrastructure dependencies.

[0127] The full-graph DNS resolution may also discover glueless nameserver IP addresses that may require separate DNS queries to resolve. Glueless nameservers may be referenced by name in DNS responses but may not include corresponding IP addresses in the response packet, requiring the dependency discovery engine to perform additional DNS lookups to determine the IP addresses of these nameservers. The dependency discovery engine may recursively query these glueless nameserver names to obtain their IP addresses and may continue this recursive process to identify the IP addresses of nameservers involved in resolving the glueless nameserver names themselves.

[0128] The dependency discovery7engine may perform nameserver resolution along CNAME and DNAME chains to identify' all DNS infrastructure involved in canonical name resolution. When domain names are configured with CNAME records that redirect to other domain names, the dependency discovery engine may follow these redirection chains to identify all Princeton - 105476 intermediate domains and their associated nameserver infrastructure. The dependency discovery’ engine may recursively resolve each domain in the CNAME chain to map the complete DNS dependency structure that may be involved in resolving the original domain name to its final IP address.

[0129] The JSON dependency object created by the dependency discovery’ engine may include comprehensive information about all discovered dependency URLs organized by content ty pe, along with the complete full-graph DNS lookup results for each domain associated with these URLs. The JSON structure may organize this information in a hierarchical format that represents the relationships between different ty pes of dependencies and their associated DNS infrastructure. The JSON dependency object may include metadata about each discovered resource, such as the content type that led to its inclusion, the discovery method used to identify the resource, and the complete chain of DNS nameservers that may be involved in resolving the resource's domain name.

[0130] The system 100 may store and process data using a PostgreSQL persistent storage system that interconnects all engines within the compute and storage resources 120. The PostgreSQL storage system may provide a centralized database infrastructure that enables coordination and data sharing between the dependency discovery engine 121-DDE, the graph construction engine 121-GCE, the monitoring engine 121 -ME, the alerting engine 121-AE, and other components of the system 100. The PostgreSQL database may store the JSON dependency objects created by the dependency discovery engine 121-DDE, making this dependency information available to other engines for further processing and analysis.

[0131] Other processing and storage 121-OPS may provide additional computational and data storage capabilities that support the PostgreSQL persistent storage system and enable coordination between the various engines. The other processing and storage 121-OPS may handle database management operations, data backup and recovery processes, and storage optimization tasks that support the overall operation of the system 100. The other processing and storage 121-OPS may also provide temporary storage and processing capabilities for intermediate data generated during dependency discovery, graph construction, and monitoring operations.

[0132] The monitoring engine 121 -ME may be further configured to raise alerts or record discrepancies that could lead to an alert based on monitored relevant data. The monitoring engine 121-ME may continuously analyze the network resources identified in the dependency objects stored in the PostgreSQL database to detect changes, anomalies, or security threats that may affect the monitored network service. The monitoring engine 121-ME may compare Princeton - 105476 current monitoring data against baseline measurements, expected values, or historical patterns to identify discrepancies that may indicate potential issues with monitored resources.

[0133] The monitoring engine 121 -ME may record discrepancies in the PostgreSQL persistent storage system when detected changes or anomalies may not immediately warrant alert generation but may contribute to pattern analysis or trend identification. These recorded discrepancies may be stored with timestamp information, resource identification data, and details about the nature of the detected change or anomaly. The monitoring engine 121-ME may accumulate these discrepancy records over time to enable the alerting engine 121-AE to perform correlation analysis and identify’ patterns that may indicate developing security threats or availability issues.

[0134] The monitoring engine 121-ME may raise alerts when detected discrepancies exceed predefined thresholds or match patterns associated with known security threats or availability issues. The alert generation process may involve updating alert records in the PostgreSQL database with detailed information about the detected issue, affected resources, and potential impact on the monitored network service. The monitoring engine 121-ME may trigger notifications to the alerting engine 121-AE when new alerts are generated, enabling coordinated analysis of alerts across multiple network layers and dependency relationships.

[0135] The PostgreSQL persistent storage system may enable the monitoring engine 121-ME to maintain historical monitoring data that supports trend analysis and pattern recognition capabilities. The monitoring engine 121-ME may store time-series data about resource availability, performance metrics, certificate changes, DNS resolution results, and other monitored parameters in the PostgreSQL database. This historical data may enable the monitoring engine 121-ME to establish baseline behavior patterns for monitored resources and to detect gradual changes or recurring issues that may not be apparent from individual monitoring measurements.

[0136] The system 100 may be configured with a plurality of monitoring engines where each monitoring engine may be configured to monitor a respective type of dependency object. Each dependency object may be monitored using one or more monitoring techniques associated with that type of dependency object. This specialized monitoring approach may enable the system 100 to apply appropriate monitoring methodologies based on the specific characteristics and requirements of different types of network resources identified within the structured dependency graph.

[0137] The plurality of monitoring engines may implement different monitoring techniques tailored to specific resource categories within the network infrastructure. A monitoring engine Princeton - 105476 configured to monitor HTML and JavaScript file dependencies may implement file contents monitoring to detect changes in resource content that may indicate tampering or malicious modification. The same monitoring engine may also implement availability monitoring to verify that file resources remain accessible and load time monitoring to detect performance degradation that may affect user experience or indicate network issues.

[0138] A monitoring engine configured to monitor TLS domain dependencies may implement Certificate Transparency monitoring to detect newly issued certificates for monitored domains. Certificate Transparency monitoring may involve querying Certificate Transparency logs to identify certificate issuance events that may indicate legitimate certificate renewals or potentially malicious certificate mis-issuance attempts. The TLS domain monitoring engine may also implement served certificate monitoring to track changes in the certificates actually presented by monitored services and TLS handshake monitoring to verify that TLS connections may be established successfully and to detect changes in TLS configuration or certificate presentation.

[0139] A monitoring engine configured to monitor DNS record dependencies may implement record availability monitoring to verify that DNS queries for monitored domains return successful responses. The DNS monitoring engine may implement record contents monitoring to detect changes in DNS record values such as A records, AAAA records, MX records, and other DNS resource records that may affect service availability or indicate potential DNS manipulation attacks. The DNS monitoring engine may also implement latency monitoring to detect performance issues with DNS resolution and DNSSEC status monitoring to verify the integrity of DNS security extensions where applicable.

[0140] A monitoring engine configured to monitor host dependencies may implement ping monitoring to verify basic network connectivity to monitored hosts. The host monitoring engine may implement TCP handshake monitoring to verify that specific network services remain accessible on monitored hosts and to detect changes in sen-ice availability or network filtering. The host monitoring engine may also implement traceroute monitoring to analyze network routing paths to monitored hosts and to detect changes in network topology that may indicate routing attacks or network infrastructure modifications.

[0141] A monitoring engine configured to monitor BGP prefix dependencies may implement BGP origin change monitoring to detect unauthorized changes in the autonomous system that announces monitored IP prefixes. BGP monitoring may involve tracking BGP announcements received from multiple vantage points across the Internet to identify prefix hijacking attempts or routing misconfigurations. The BGP monitoring engine may implement BGP prefix length Princeton - 105476 monitoring to detect sub-prefix announcements that may indicate more specific route announcements designed to hijack traffic. The BGP monitoring engine may also implement BGP path change monitoring to detect unusual changes in AS-path information that may indicate route manipulation attacks and RPKI monitoring to verify the validity of route announcements against Resource Public Key Infrastructure records.

[0142] Each of the plurality of monitoring engines may be located in a respective geographic region of the network to provide comprehensive monitoring coverage and to detect localized effects that may not be visible from a single monitoring location. Geographic distribution of monitoring engines may enable the system 100 to identify network issues, attacks, or performance problems that may affect only specific regions or network paths. The geographic distribution may also provide redundancy in monitoring operations, ensuring that monitoring continues even if monitoring infrastructure in one region becomes unavailable.

[0143] A monitoring engine located in a first geographic region may detect network routing changes, DNS resolution issues, or service availability problems that affect users or network infrastructure within that region. A monitoring engine located in a second geographic region may simultaneously monitor the same network resources from a different network perspective, potentially detecting different issues or confirming that detected problems affect multiple regions. The geographic distribution may enable the system 100 to distinguish between localized network issues and global problems affecting monitored network services.

[0144] The geographically distributed monitoring engines may coordinate through the persistent storage system to share monitoring data and alert information across different regions. Each monitoring engine may store monitoring results and detected discrepancies in the shared database, enabling the alerting engine to perform correlation analysis across monitoring data collected from multiple geographic locations. This coordination may enable the alerting engine to identify patterns in monitonng data that may indicate coordinated attacks affecting multiple regions or to distinguish between legitimate regional variations in network behavior and potential security threats.

[0145] The geographic distribution of monitoring engines may enable detection of regionspecific attacks such as localized BGP hijacking attempts that may only affect routing within specific geographic areas or autonomous systems. DNS manipulation attacks that target specific DNS resolvers or regional DNS infrastructure may be detected by monitoring engines operating within the affected regions while remaining invisible to monitoring engines in other geographic locations. The distributed monitoring approach may also enable detection of Princeton - 105476 content delivery network issues, regional service outages, or network performance problems that may affect user experience in specific geographic areas.

[0146] Each geographically distributed monitoring engine may implement the same monitoring techniques for each type of dependency object while operating from different network vantage points. The consistency in monitoring techniques across geographic regions may enable meaningful comparison of monitoring results and may facilitate identification of regional variations in network behavior or service performance. The distnbuted monitoring engines may apply identical content type filtering, dependency analysis, and alert generation criteria to ensure consistent monitoring coverage across all monitored geographic regions.

[0147] A computer implemented method for monitoring network resources associated with a web browser session may be provided to enable comprehensive analysis of network dependencies and security threats across multiple layers of network infrastructure. The computer implemented method may begin by receiving a uniform resource locator (URL) associated with a network service that may serve as the target for dependency discovery7and monitoring operations. The received URL may represent a web service, web application, or other network-accessible resource that may be analyzed to identify all associated network dependencies and potential security vulnerabilities.

[0148] The computer implemented method may iteratively perform a series of steps until substantially all network resources associated with the network service have been processed and analyzed. This iterative approach may ensure comprehensive coverage of all network dependencies that may affect the security and availability of the target network service. The iterative processing may continue until no additional network resources or dependencies are discovered, indicating that the complete attack surface associated with the target URL has been mapped and analyzed.

[0149] The computer implemented method may involve identifying substantially all network requests and responses associated with the network service during the iterative processing. The identification process may capture all netw ork communications generated when accessing the target URL, including initial page load requests, dynamically generated requests triggered by JavaScript execution, and any additional network activity that may occur during interaction with the network service. The identification may encompass network requests for HTML documents, JavaScript files, stylesheets, images, fonts, API calls, and other resources that may be loaded or accessed during the w eb browser session.

[0150] The computer implemented method may involve associating with each identified network request any respective responses to create complete request-response pairs for Princeton - 105476 analysis. The association process may match network requests with their corresponding responses based on request identifiers, timing information, or other correlation mechanisms that enable pairing of related network communications. The association may enable comprehensive analysis of both the requests generated by the web browser session and the responses received from various network services and resources.

[0151] The computer implemented method may perform network request filtering using the "content-type" header of respective network responses to identify responses of types that may be considered relevant to the functionality and security of the web browser session. The filtering process may analyze the content-type header information included in each network response to determine whether the associated resource may pose security or availability risks to the monitored web browser session. The filtering may prioritize content types such as HTML documents, JavaScript files, and other executable or functional resources while potentially excluding content types such as images or fonts that may not significantly impact security or functionality.

[0152] The computer implemented method may extract from the respective identified responses respective response URLs for each response with content types determined to be relevant to create a set of dependency objects by content type. The extraction process may parse network responses to identify7URLs of resources that may be loaded or referenced by the target network service. The dependency objects may be organized by content type to enable appropriate monitoring techniques to be applied based on the specific characteristics of each type of network resource.

[0153] The computer implemented method may involve monitoring relevant data associated with each of the discovered object dependencies across multiple layers of the network infrastructure. The monitoring may track various aspects of the identified dependencies, including availability status, content integrity, certificate validity, DNS resolution behavior, and network routing information. The monitoring may operate continuously or at regular intervals to detect changes or anomalies in the monitored network resources that may indicate security threats or availability issues.

[0154] The computer implemented method may involve analyzing monitored relevant data across multiple layers to identify7root causes of events and intermediate causes of events. The analysis may correlate monitoring data from different network layers and dependency relationships to understand causal relationships between detected events and issues. The analysis may enable identification of the underlying causes of network outages, security Princeton - 105476 incidents, or performance problems by examining how events at one network layer may affect resources at other layers within the dependency structure.

[0155] The computer implemented method may further comprise processing the set of dependency objects to generate a structured dependency graph depicting relationships between the dependency objects and dependency object descriptions for monitoring. The structured dependency graph generation may transform the discovered dependency objects into a comprehensive graph structure that represents the interconnections and dependencies between various network resources. The structured dependency graph may enable visualization and analysis of complex dependency relationships that span multiple layers of network infrastructure.

[0156] The structured dependency graph may represent the relationship between at least some of the dependencies discovered during the iterative processing steps. In some cases, the structured dependency graph may represent the relationship between all dependencies discovered during the dependency identification process, providing comprehensive coverage of the complete network infrastructure supporting the target network service. The graph structure may enable correlation analysis and root cause identification by showing how different network resources depend on one another across multiple network layers.

[0157] The computer implemented method may further comprise visualizing the dependency graph and the active alerts via an annotated, color coded, and icon-based view of the dependency graph with organizational structures designed to help operators clearly see what is going on. The visualization may provide intuitive graphical representations of complex network dependency relationships and may highlight active alerts or issues within the context of the overall dependency structure. The visualization may enable network administrators and security analysts to quickly understand the scope and impact of detected issues.

[0158] The computer implemented method may be implemented by one or more enterprise services applications configured for managing the discovering and identifying type of enterprise resources associated with network request and responses. The enterprise services applications may provide specialized capabilities for monitoring enterprise-specific network infrastructure and may integrate with existing enterprise security and management systems. The enterprise implementation may focus on internal corporate resources and may provide enhanced security monitoring for enterprise network environments.

[0159] The computer implemented method may be implemented as a commercial monitoring tool configured for managing the discovering and identifying type of at least a subset of resources associated with network request and responses. The commercial monitoring tool Princeton - 105476 implementation may provide subscription-based monitoring services and may integrate with third-party security platforms and threat intelligence services. The commercial implementation may offer scalable monitoring capabilities that may be deployed across multiple organizations or network environments.

[0160] The identifying step of the computer implemented method may be configured to ignore those content types selected as not posing a significant security or availability risk. The content type filtering may focus monitoring efforts on network resources that may have the greatest potential impact on security and functionality while reducing computational overhead and alert noise. The content types that may be ignored may include images and fonts that may primarily affect visual presentation rather than application security or functionality.

[0161] The computer implemented method may be implemented via a web-browser automation framework that enables programmatic control of web browser operations during the monitoring process. The web-browser automation framework may comprise a Selenium framework instantiated within a browser program that provides standardized interfaces for browser control and network activity monitoring. The automation framework may enable consistent and repeatable monitoring operations across different web services and network environments.

[0162] The computer implemented method may be implemented in response to user interaction with a web service in a browser being monitored during the dependency discovery process. The user interaction implementation may enable monitoring of complex web transactions that involve manual user authentication, form submissions, and navigation through multi-step processes. The user interaction monitoring may capture dependencies that may only be discovered through interactive use of web services rather than simple automated URL processing.

[0163] The computer implemented method may further comprise packaging all dependency URLs and the full-graph DNS lookups of the domains in these URLs into a JSON dependency object that represents the attack surface for the target web service. The JSON packaging may- pro vide a standardized data format for representing the complete network dependency structure and may enable integration with other security tools and analysis systems. The JSON dependency object may include comprehensive DNS infrastructure information discovered through recursive nameserver resolution processes.

[0164] The computer implemented method may further comprise raising alerts or recording discrepancies that could lead to an alert based on monitored relevant data. The alert generation may provide notifications when detected changes or anomalies exceed predefined thresholds Princeton - 105476 or match patterns associated with known security threats. The discrepancy recording may maintain historical information about detected changes that may contribute to pattern analysis and trend identification over time.

[0165] The computer implemented method may involve configuring each of a plurality of monitoring processes to monitor a respective type of dependency object, where each dependency object may be monitored using one or more monitoring techniques associated with that type of dependency object. The specialized monitoring approach may enable application of appropriate monitoring methodologies based on the specific characteristics of different types of network resources. Each of the plurality of monitoring processes may be located in a respective geographic region of the network to provide comprehensive monitoring coverage and to detect localized effects that may not be visible from a single monitoring location.

[0166] The computer implemented method may further comprise processing the set of dependency objects to generate thereby a structured dependency graph depicting relationships between the dependency objects and dependency object descriptions for monitoring. The processing of dependency objects may involve analyzing the discovered network resources and their interconnections to create a comprehensive graph structure that represents how different network components depend on one another across multiple layers of network infrastructure. The structured dependency graph generation may transform the raw dependency object data into an organized representation that enables systematic monitoring and analysis of network resource relationships.

[0167] The processing may begin by establishing a central node w ithin the structured dependency graph that represents the primary' monitoring target, such as the original URL or web service that initiated the dependency discovery process. The processing may then systematically add nodes to the structured dependency graph for each dependency object identified during the network request and response analysis. Each node within the structured dependency graph may represent a specific netw ork resource, such as a JavaScript file, HTML document, domain name, IP address, DNS server, or BGP routing prefix.

[0168] The processing may create directed edges between nodes within the structured dependency graph to represent dependency relationships where one network resource relies on the proper functioning of another network resource. The directed edges may indicate the direction of dependency, showing which resources depend on other resources within the network infrastructure. The processing may analyze the discovered dependency objects to determine these relationships based on how resources are loaded, referenced, or accessed during the web browser session monitoring. Princeton - 105476

[0169] The processing may expand certain dependency objects into multiple nodes within the structured dependency graph when these dependencies exist at multiple layers of the network stack. A single network resource such as a web server IP address may be represented as separate nodes for dataplane connectivity monitoring and BGP routing layer monitoring. The processing may create edges between these related nodes to show that dataplane connectivity7depends on proper BGP routing functionality7.

[0170] The dependency object descriptions for monitoring may include metadata about each network resource that enables appropriate monitoring techniques to be selected and applied. The descriptions may specify the resource type, such as whether a node represents a domain name, IP address, JavaScript file, or DNS server. The descriptions may also include information about the discovery method used to identify each resource and the content type or network layer associated with each dependency object.

[0171] The processing may organize dependency objects by their network layer characteristics to enable layer-specific monitoring approaches. Application layer dependencies such as HTML files and JavaScript resources may be grouped together for content monitoring techniques, while network layer dependencies such as IP addresses and routing information may be organized for connectivify and routing monitoring approaches. DNS layer dependencies may be grouped for DNS resolution monitoring and certificate monitoring techniques.

[0172] The structured dependency graph may represent the relationship between at least some of the dependencies discovered during the network resource identification process. The selective representation approach may focus on the most security and availability -relevant dependencies while potentially excluding dependencies that may not significantly impact the monitored network service. The processing may apply filtering criteria to determine which discovered dependencies should be included in the structured dependency graph based on their potential impact on service security and availability.

[0173] The filtering for selective representation may consider factors such as the content type of discovered resources, the network layer at which dependencies operate, and the potential security7implications of each dependency. Dependencies involving executable content such as JavaScript files may be prioritized for inclusion in the structured dependency graph due to their potential security7impact. Dependencies involving network infrastructure components such as DNS servers and routing systems may also be prioritized due to their potential impact on service availability.

[0174] The structured dependency7graph may represent the relationship between all dependencies discovered during the dependency identification and analysis process. The Princeton - 105476 comprehensive representation approach may provide complete coverage of the entire attack surface associated with the monitored network service. The processing may include every discovered dependency object in the structured dependency graph regardless of the perceived security or availability impact, ensuring that no potential attack vectors or failure points are overlooked during monitoring operations.

[0175] The comprehensive representation may include dependencies that might initially appear to have minimal security impact but could become relevant in complex attack scenarios or cascading failure situations. Image files, font resources, and other content types that may be filtered out in selective representation approaches may be included in the comprehensive structured dependency graph to provide complete visibility into all network resources accessed during the web browser session.

[0176] The processing may implement different levels of detail within the structured dependency graph based on the representation approach selected. Selective representation may focus on high-level dependency relationships between major network components, while comprehensive representation may include detailed relationships between all discovered network resources. The level of detail may affect the complexity of the resulting graph structure and the computational resources required for monitoring and analysis operations.

[0177] The structured dependency graph generation may create hierarchical relationships within the graph structure to represent how dependencies at different network layers relate to one another. Application layer resources may depend on network layer resources, which may in turn depend on routing layer resources. The processing may create these hierarchical relationships by analyzing how resources at higher network layers require the proper functioning of resources at low er network layers.

[0178] The processing may assign priority levels or importance ratings to different nodes and edges within the structured dependency graph based on their potential impact on the monitored network service. Resources that serve as single points of failure or that support multiple dependent resources may be assigned higher priority levels. The priority assignments may be used during monitoring operations to focus attention on the most impactful network resources and to prioritize alert generation for issues affecting high-priority dependencies.

[0179] The structured dependency graph may be stored in a format that enables efficient query ing and analysis by monitoring and alerting systems. The processing may generate graph data structures that support rapid traversal operations for root cause analysis and correlation of events across multiple network layers. The storage format may enable persistent storage of the Princeton - 105476 graph structure while supporting dynamic updates as new dependencies are discovered or existing dependencies change over time.

[0180] The dependency object descriptions may include temporal information about when each dependency was discovered and how frequently each resource is accessed during typical operation of the monitored network service. This temporal information may enable monitoring systems to establish baseline behavior patterns and to detect unusual changes in dependency access patterns that may indicate security threats or operational issues.

[0181] The processing may validate the completeness and accuracy of the structured dependency graph by analyzing the logical consistency of dependency relationships and identifying potential gaps in the discovered dependency structure. The validation may involve checking that all referenced resources have corresponding nodes in the graph and that dependency relationships are logically consistent across different network layers.

[0182] The computer implemented method may further comprise visualizing the dependency graph and the active alerts via an annotated, color coded, and icon-based view of the dependency graph with organizational structures designed to help operators clearly see what is going on. The visualization process may transform the structured dependency graph into intuitive graphical representations that enable network administrators and security analysts to comprehend complex dependency relationships and monitoring status information. The visualization may provide visual clarity for dependency structures that may span multiple network layers and involve numerous interconnected resources.

[0183] The annotated view of the dependency graph may include descriptive labels and textual information that identify specific network resources and explain their roles within the overall dependency structure. The annotations may provide human-readable names for network resources, explanatory text about dependency relationships, and contextual information that helps operators understand the significance of different components within the monitored network infrastructure. The annotations may include details about resource types, discovery methods, and potential security implications associated with specific dependencies.

[0184] The color coded view may apply distinct colors to different categories of network resources and dependency relationships within the structured dependency graph. The color coding may enable rapid visual identification of resource types, network layers, and monitoring status information. Different colors may be assigned to application layer resources, network infrastructure components, DNS-related dependencies, and routing layer elements to provide immediate visual distinction between different categories of network resources. Princeton - 105476

[0185] The color coding may also indicate the current monitoring status and alert conditions associated with different nodes within the dependency graph. Resources experiencing active alerts or security issues may be displayed using warning colors such as red or orange, while properly functioning resources may be displayed using normal colors such as blue or green. The color coding may provide immediate visual feedback about the overall health and security status of the monitored network infrastructure.

[0186] The icon-based view may assign unique graphical symbols to different types of network resources within the structured dependency graph. The icons may provide immediate visual recognition of resource categories such as web servers, DNS servers, domain names, JavaScript files, and routing components. The icon-based representation may enable operators to quickly identify specific types of resources within complex dependency graphs without requiring detailed examination of textual labels or annotations.

[0187] The organizational structures designed to help operators clearly see what is going on may include hierarchical grouping of related resources, clustering of similar dependency types, and filtering capabilities that enable focused analysis of specific aspects of the dependency graph. The organizational structures may reduce visual complexify by grouping related resources together and may provide expandable sections that enable operators to drill down into detailed dependency relationships when needed.

[0188] The visualization may implement node clustering capabilities that group multiple resources of the same type that share similar dependency relationships. The clustering may reduce the visual complexify of large dependency graphs by representing multiple similar resources as single clustered nodes that may be expanded to show individual resources when detailed analysis is required. The clustering may be particularly useful for managing large numbers of JavaScript files, image resources, or other content types that may be hosted by the same domain or content delivery network.

[0189] The organizational structures may provide filtering mechanisms that enable operators to focus on specific subsets of the dependency graph based on resource type, network layer, or security relevance. The filtering may enable operators to temporarily hide certain categories of dependencies to simplify the visual representation and focus attention on specific aspects of the network infrastructure. The filtering capabilities may support investigation workflows where operators need to analyze particular types of dependencies or network layers in isolation.

[0190] The visualization may provide interactive capabilities that enable operators to explore the dependency graph structure and access detailed information about specific resources and dependency relationships. The interactive features may include clickable nodes that display Princeton - 105476 detailed resource information, expandable sections that reveal additional dependency details, and navigation tools that enable operators to traverse complex dependency hierarchies efficiently.

[0191] The computer implemented method may be implemented by one or more enterprise services applications configured for managing the discovering and identifying type of enterprise resources associated with network request and responses. The enterprise services applications implementation may provide specialized capabilities tailored to enterprise network environments and corporate security requirements. The enterprise services applications may focus on discovering and monitoring enterprise-specific resources such as internal web applications, corporate authentication systems, directory services, and proprietary APIs that may be used within corporate network infrastructures.

[0192] The enterprise services applications may be configured for generating a structured dependency graph depicting relationships between enterprise dependency objects and including enterprise dependency object descriptions. The enterprise dependency objects may include internal corporate resources that may not be visible to external monitoring systems, such as internal DNS servers, corporate certificate authorities, enterprise single sign-on systems, and internal application servers. The enterprise services applications may create specialized dependency graphs that account for enterprise network architectures and internal security policies.

[0193] The enterprise services applications may be configured for monitoring relevant data associated with each of the enterprise object dependencies within the dependency graph. The monitoring capabilities may be adapted for enterprise environments and may include integration with existing corporate security information and event management systems, enterprise network monitoring tools, and internal threat intelligence platforms. The enterprise services applications may implement monitoring techniques specifically designed for internal corporate resources and may provide alerts and reporting formats that align with enterprise security workflows.

[0194] The enterprise services applications may provide enhanced security monitoring capabilities for enterprise-specific attack vectors and threat scenarios. The monitoring may focus on insider threats, corporate network infrastructure vulnerabilities, and attacks targeting enterprise authentication systems or internal applications. The enterprise sendees applications may implement specialized detection algorithms for enterprise-specific attack patterns and may provide integration with corporate incident response procedures. Princeton - 105476

[0195] The enterprise sen-ices applications may implement role-based access controls and security’ policies that restrict access to monitoring data and configuration capabilities based on corporate security requirements. The access controls may ensure that sensitive information about internal network infrastructure is only accessible to authorized personnel and may provide audit trails for monitoring system access and configuration changes.

[0196] The computer implemented method may be implemented as a commercial monitoring tool configured for managing the discovering and identifying type of at least a subset of resources associated with network request and responses. The commercial monitoring tool implementation may provide subscription-based monitoring services that may be deployed across multiple organizations and network environments. The commercial monitoring tool may offer standardized monitoring capabilities that may be customized for different customer requirements and use cases.

[0197] The commercial monitoring tool may be configured for generating a structured dependency graph depicting relationships between the subset of dependency objects and including dependency object descriptions. The subset approach may enable the commercial monitoring tool to focus on specific categories of network resources or to provide different levels of monitoring coverage based on subscription tiers or service agreements. The commercial monitoring tool may offer selective monitoring capabilities that balance comprehensive coverage with cost considerations and performance requirements.

[0198] The commercial monitoring tool may be configured for monitoring relevant data associated with at least the subset of dependency objects. The monitoring capabilities may include integration with third-party threat intelligence services, commercial security databases, and external monitoring platforms that provide specialized detection capabilities or global threat visibility. The commercial monitoring tool may offer access to proprietary threat intelligence feeds and commercial security services that may not be available to internal enterprise monitoring systems.

[0199] The commercial monitoring tool may provide scalable monitoring infrastructure that may accommodate varying customer requirements and network sizes. The scalability may enable the commercial monitoring tool to monitor small web applications with limited dependencies as well as large enterprise environments with complex network infrastructures. The commercial monitoring tool may offer flexible deployment options that may be adapted to different customer network architectures and security requirements.

[0200] The commercial monitoring tool may be configured as a Software as a Service tool that provides cloud-based monitoring capabilities accessible through web interfaces or APIs. The Princeton - 105476

[0201] Software as a Service configuration may eliminate the need for customers to install and maintain monitoring infrastructure locally and may provide automatic updates to monitoring algorithms and threat detection capabilities. The Software as a Service approach may enable rapid deployment of monitoring capabilities and may provide access to geographically distributed monitoring infrastructure.

[0202] The Software as a Service configuration may provide subscription-based access to monitoring capabilities with different service tiers that offer varying levels of monitoring coverage, alert frequency, and feature availability. The subscription model may enable customers to select monitoring capabilities that align with their specific requirements and budget constraints. The Software as a Service approach may provide centralized management of monitoring infrastructure while enabling customers to access monitoring data and configuration capabilities through standardized web interfaces.

[0203] The Software as a Service tool may implement multi-tenant architecture that enables secure isolation of customer data and monitoring configurations while sharing underlying monitoring infrastructure across multiple customers. The multi-tenant approach may provide cost efficiencies and scalability benefits while maintaining security and privacy requirements for each customer's monitoring data and network information.

[0204] The commercial monitoring tool configured as a Software as a Service tool may provide integration capabilities with customer security systems and may offer APIs that enable automated consumption of monitoring data and alerts by customer security information and event management systems. The integration capabilities may enable customers to incorporate commercial monitoring data into existing security workflows and incident response procedures without requiring significant changes to established security operations.

[0205] The computer implemented method for monitoring network resources may implement content type filtering mechanisms that focus monitoring efforts on network resources that may pose security’ or availability' risks while excluding content types that may not significantly impact the monitored web browser session. The identifying step of the computer implemented method may be configured to ignore those content types selected as not posing a significant security or availability risk. This selective filtering approach may enable the method to prioritize computational resources and monitoring attention on network resources that may have the greatest potential impact on service security and functionality.

[0206] The content type filtering process may analyze the "content-type" header information included in network responses to determine whether each discovered resource should be included in the dependency analysis and monitoring operations. The method may maintain Princeton - 105476 predefined lists or databases of content types that may be considered low-risk for security and availability purposes. The filtering process may compare the content-type header of each network response against these predefined lists to determine whether the associated resource should be excluded from further analysis and monitoring.

[0207] The content types that may be ignored by the computer implemented method may include images and fonts that primarily affect visual presentation rather than application functionality or security. Image content types such as JPEG, PNG, GIF, SVG, and other graphical formats may be filtered out because these resources may not ty pically execute code or affect the functional behavior of web applications in ways that could compromise security. The method may recognize various image format content types including "image / jpeg", "image / png". "image / gif. "image / svg+xml", and other standard image MIME types for exclusion from dependency monitoring.

[0208] Font resources may also be excluded from monitoring because these resources may primarily affect typography and visual presentation rather than application security or functionality. The method may filter out font content types such as TrueType fonts, Web Open Font Format files. Embedded OpenType fonts, and other typography resources. Font content ty pes that may be ignored may include "font / ttf "font / woff "font / woff2", "application / font- wofif", and other standard font MIME types that may be encountered during web browser sessions.

[0209] The computer implemented method may focus monitoring efforts on content types that may be considered performance and security sensitive for the web browser session. The method may prioritize HTML documents, JavaScript files, Cascading Style Sheets that may contain executable content, XML configuration files, JSON data files, and other resources that may affect application behavior or contain executable code. These prioritized content types may include "text / html", "application / javascript", "text / javascript", "text / css", "application / json", "application / xml", and other MIME types associated with functional or executable content.

[0210] The content type filtering may be configurable to accommodate different monitoring requirements and security policies for various web browser sessions. The method may allow administrators or automated systems to modify the lists of ignored content types based on specific application requirements or security concerns. The method may also provide options to include typically ignored content types in monitoring operations when comprehensive coverage may be desired for particular applications or security' assessments.

[0211] The computer implemented method may be implemented via a web-browser automation framework that provides programmatic control over browser operations during the Princeton - 105476 network resource identification and monitoring process. The web-browser automation framework implementation may enable systematic and repeatable monitoring operations across different web services and network environments. The automation framework may provide standardized interfaces for controlling web browser behavior while capturing comprehensive network activity7data that may not be accessible through other monitoring approaches.

[0212] The web-browser automation framework may enable the method to load target URLs automatically7, execute JavaScript code within web pages, and interact with web page elements while monitoring all resulting network requests and responses. The automation framework may provide access to detailed browser instrumentation capabilities that enable capture of network timing information, request headers, response headers, and content ty pe information that may be used for dependency analysis and content type filtering operations.

[0213] The web-browser automation framework may comprise a Selenium framework instantiated within a browser program that provides standardized APIs for browser control and network activity monitoring. The Selenium framework may support multiple browser types and may provide consistent interfaces for browser automation across different browser implementations. The Selenium framework implementation may enable the method to operate with various browser configurations while maintaining consistent monitoring capabilities and data collection procedures.

[0214] The browser program used with the Selenium framework may comprise a Chrome web browser, Firefox browser, Safari browser, or other web browser implementations that provide detailed network logging capabilities. The browser program may be instrumented to provide access to debug network logs that contain comprehensive information about all network requests and responses generated during automated browser sessions. The browser instrumentation may enable the method to capture detailed network activity data through browser developer tools protocols or other browser-specific logging mechanisms.

[0215] The Selenium framework instantiated within the browser program may enable the method to navigate to specified URLs automatically7, execute predefined interaction sequences, and capture all resulting network activity for analysis. The Selenium framework may provide programmatic control over browser navigation, form submission, button clicking, and other user interface interactions that may trigger additional network requests and dependency loading. The automation capabilities may enable consistent and repeatable monitoring operations that may be executed on regular schedules or in response to specific monitoring triggers. Princeton - 105476

[0216] The computer implemented method may be implemented in response to user interaction with a web service in a browser being monitored by the dependency discovery process. This user interaction implementation may enable the method to monitor entire web browsing sessions that involve manual user interactions rather than limiting monitoring to automated URL processing. The method may monitor browser sessions where users manually navigate through web applications, authenticate with services, and perform various interactions with web-based systems.

[0217] The user interaction monitoring capability may enable the method to capture dependencies that may only be discovered through interactive use of web services. Web applications may load different resources or contact different services based on user actions such as login procedures, form submissions, navigation through different application sections, or activation of specific application features. The method may monitor these interactive sessions to identify dependencies on authentication services, user-specific content delivery networks, dynamic resource loading, and other network resources that may not be apparent from simple automated URL fetching.

[0218] The method implemented in response to user interaction may capture network requests generated by user-triggered JavaScript execution, AJAX requests initiated by user actions, WebSocket connections established during user sessions, and other dynamic network activity7that may occur during manual interaction with web services. The method may apply the same content type filtering and dependency extraction processes to these user-generated network requests, enabling comprehensive discovery of all network dependencies regardless of whether they are generated during initial page loading or subsequent user interactions.

[0219] The user interaction implementation may enable the method to monitor complex web transactions that may involve multiple steps, user authentication, and interaction with third- party services. Enterprise web applications may require users to log into employee accounts, navigate through human resources self-service websites, interact with third-party authentication providers such as two-factor authentication services, or access specialized corporate applications that may not be accessible through automated browsing. The method may monitor these complete transaction flows to identify all network resources and services that may be contacted during user interaction.

[0220] The method may distinguish between network requests generated during initial automated page loading and network requests generated in response to user interactions while applying consistent content type filtering and dependency analysis to both categories of network activity. The user interaction monitoring may capture the complete network Princeton - 105476 dependency footprint associated with realistic usage patterns of monitored web services, providing more comprehensive dependency discovery than automated approaches that may not trigger all application functionality.

[0221] The user interaction implementation may enable the method to adapt to different user workflows and interaction patterns while maintaining consistent monitoring coverage. Different users may navigate through web applications using different paths or may access different features and functionality that generate distinct sets of network dependencies. The method may accommodate these variations in user behavior while ensuring that all discovered network dependencies are subject to appropriate content type fdtering and monitoring operations.

[0222] The computer implemented method may further comprise packaging all dependency URLs and the full-graph DNS lookups of the domains in these URLs into a JSON dependency object that represents the attack surface for the target web service. The packaging process may transform the discovered network dependencies and their associated DNS infrastructure information into a standardized data format that enables systematic analysis and processing by other monitoring and security systems. The JSON dependency object may serve as a comprehensive representation of the complete network attack surface associated with the monitored web sen ice.

[0223] The packaging process may organize the dependency URLs by content type categories to enable appropriate processing and monitoring techniques to be applied based on the specific characteristics of each type of network resource. The JSON dependency object may include separate sections for HTML documents, JavaScript files, CSS stylesheets, API endpoints, and other content types that were identified during the network request filtering process. Each content type section may contain arrays of URLs that were discovered during the iterative monitoring process along with metadata about how each URL was discovered and its relationship to the target web service.

[0224] The full-graph DNS lookups included in the JSON dependency object may provide comprehensive information about all nameservers and DNS infrastructure components that may be involved in resolving the domains associated with the discovered dependency URLs. The full -graph DNS information may include authoritative nameservers, intermediate nameservers, glued nameserver IP addresses, glueless nameserver IP addresses, and nameserver resolution chains that may be traversed during DNS resolution processes. The JSON structure may organize this DNS information in a hierarchical format that represents the complete DNS dependency tree for each monitored domain. Princeton - 105476

[0225] The JSON dependency object may include detailed information about CNAME and DNAME resolution chains that may be involved in resolving domain names to their final IP addresses. The packaging process may trace these canonical name resolution chains recursively to identify all intermediate domains and their associated nameserver infrastructure that may affect the resolution of the original domain names. The JSON structure may represent these resolution chains as ordered arrays that show the complete sequence of DNS lookups that may be required to resolve each dependency URL to its final destination.

[0226] The attack surface representation provided by the JSON dependency object may enable security analysis tools and monitoring systems to understand the complete scope of network infrastructure that could potentially be targeted by attackers seeking to compromise the monitored web service. The JSON structure may include risk assessment information that identifies single points of failure, shared infrastructure components, and network resources that support multiple dependencies within the monitored service. The attack surface representation may enable prioritization of monitoring efforts based on the potential impact of compromising different network resources.

[0227] The JSON dependency object may include temporal information about when each dependency was discovered and how frequently each resource is accessed during typical operation of the monitored web service. The temporal data may enable monitoring systems to establish baseline behavior patterns and to detect unusual changes in dependency access patterns that may indicate security threats or operational issues. The JSON structure may include timestamps, access frequency metrics, and historical trend information that supports pattern analysis and anomaly detection capabilities.

[0228] The packaging process may validate the completeness and consistency of the dependency information before creating the final JSON dependency object. The validation may involve checking that all discovered dependency URLs have corresponding DNS lookup information and that the DNS resolution chains are complete and logically consistent. The validation process may identify potential gaps in the dependency discovery7process and mayflag incomplete or inconsistent dependency information for additional analysis.

[0229] The JSON dependency object may be structured to support efficient querying and analysis operations by monitoring systems and security tools. The JSON format may include indexing information, cross-reference tables, and hierarchical organization that enables rapid lookup of specific dependencies or DNS infrastructure components. The structure may support both human-readable presentation of dependency information and machine-readable processing by automated analysis systems. Princeton - 105476

[0230] The computer implemented method may further comprise raising alerts or recording discrepancies that could lead to an alert based on monitored relevant data. The alert generation and discrepancy recording capabilities may provide mechanisms for detecting and responding to changes, anomalies, or security threats that may affect the monitored network resources identified during the dependency discovery process. The method may implement thresholdbased detection algorithms that compare current monitoring measurements against baseline values or expected ranges to identify conditions that warrant alert generation.

[0231] The raising of alerts may involve generating immediate notifications when detected changes or anomalies exceed predefined severity thresholds or match patterns associated with known security threats or availability issues. The alert generation process may analyze monitoring data collected from multiple network layers and dependency relationships to identify' conditions that may indicate active attacks, service outages, or performance degradation. The alerts may include detailed information about the affected network resources, the nature of the detected issue, and the potential impact on the monitored web service.

[0232] The alert generation may implement correlation algorithms that analyze relationships between monitoring events across different network resources within the structured dependency graph. The method may identify' patterns where multiple related network resources experience simultaneous issues or where changes in upstream dependencies may be causing dow nstream effects. The correlation analysis may enable the method to generate high-priority alerts for coordinated attacks or cascading failures that affect multiple components of the monitored network infrastructure.

[0233] The recording of discrepancies may involve storing information about detected changes or anomalies that may not immediately warrant alert generation but could contribute to pattern analysis or trend identification over time. The discrepancy recording process may maintain historical records of monitoring measurements, detected variations from baseline behavior, and gradual changes in network resource characteristics that may indicate developing issues or long-term trends.

[0234] The discrepancy records may include detailed metadata about the monitoring conditions, measurement techniques, and network context associated with each detected variation. The method may store timestamp information, measurement values, comparison baselines, and contextual information about network conditions at the time each discrepancy was detected. The discrepancy records may enable retrospective analysis of netw ork behavior patterns and may support forensic investigation of security incidents or service outages. Princeton - 105476

[0235] The method may implement different severity' levels for both alerts and discrepancy records based on the potential impact of detected issues on the monitored web service. High- severity' alerts may be generated for conditions that pose immediate threats to service availability or security, while lower-severity discrepancies may be recorded for minor variations or gradual changes that may not require immediate attention. The severity classification may enable appropriate prioritization of response efforts and may support escalation procedures for different types of detected issues.

[0236] The alert generation and discrepancy recording may operate continuously during the monitoring process, analyzing new monitoring data as it becomes available and comparing current measurements against historical

[0237] The computer implemented method may involve configuring each of a plurality of monitoring processes to monitor a respective type of dependency object, where each dependency object may be monitored using one or more monitoring techniques associated with that ty pe of dependency object. This specialized monitoring approach may enable the method to apply appropriate monitoring methodologies based on the specific characteristics and requirements of different types of network resources identified within the structured dependency graph. The plurality' of monitoring processes may operate concurrently to provide comprehensive coverage of all discovered network dependencies while applying monitoring techniques that may be optimized for each specific resource category.

[0238] A monitoring process configured to monitor HTML file dependency objects may implement file contents monitoring techniques that detect changes in HTML document content that may indicate tampering, malicious modification, or unauthorized updates to web page resources. The HTML file monitoring process may calculate cryptographic hashes of HTML document content and may compare these hashes against baseline values to detect any modifications to the monitored HTML resources. The HTML file monitoring may also implement availability' monitoring techniques that verily HTML documents remain accessible and may measure response times to detect performance degradation that could affect user experience or indicate network infrastructure issues.

[0239] A monitoring process configured to monitor JavaScript file dependency objects may implement specialized monitoring techniques adapted to the security -sensitive nature of executable JavaScript content. The JavaScript file monitoring process may perform content integrity monitoring that detects any changes to JavaScript file content that could indicate supply chain attacks or malicious code injection. The JavaScript monitoring may implement Princeton - 105476 syntax analysis techniques that verify JavaScript files contain valid code structures and may detect obfuscated or suspicious code patterns that could indicate malicious modifications.

[0240] The JavaScript file monitoring process may also implement behavioral analysis techniques that monitor the network requests generated by JavaScript code execution to detect unusual or suspicious network activity. The JavaScript monitoring may track external API calls, third-party service connections, and data transmission patterns generated by JavaScript execution to identify potential data exfiltration attempts or unauthorized network communications that could indicate compromised JavaScript resources.

[0241] A monitoring process configured to monitor TLS domain dependency objects may implement Certificate Transparency monitoring techniques that track newly issued certificates for monitored domains by querying Certificate Transparency logs maintained by certificate authorities and independent log operators. The TLS domain monitoring process may detect certificate issuance events that may indicate legitimate certificate renewals or potentially malicious certificate mis-issuance attempts that could enable man-in-the-middle attacks or domain impersonation.

[0242] The TLS domain monitoring process may implement served certificate monitoring techniques that track changes in the certificates actually presented by monitored sendees during TLS handshake operations. The served certificate monitoring may detect certificate replacements, certificate authority changes, or certificate validity period modifications that could indicate security incidents or infrastructure changes affecting the monitored domains. The TLS domain monitoring may also implement TLS handshake monitoring techniques that verify' TLS connections may be established successfully and may detect changes in TLS configuration, cipher suite selection, or protocol version support.

[0243] A monitoring process configured to monitor DNS record dependency objects may implement record availability monitoring techniques that verify DNS queries for monitored domains return successful responses within expected timeframes. The DNS record monitoring process may perform queries from multiple network locations to detect DNS resolution failures or performance issues that could affect service availability. The DNS monitoring may implement record contents monitoring techniques that detect changes in DNS record values such as A records, AAAA records, MX records, CNAME records, and other DNS resource records that could indicate DNS manipulation attacks or infrastructure modifications.

[0244] The DNS record monitoring process may implement latency monitoring techniques that measure DNS resolution response times to detect performance degradation or network connectivity issues affecting DNS infrastructure. The DNS monitoring may also implement Princeton - 105476

[0245] DNSSEC status monitoring techniques that verify the integrity of DNS Security Extensions where applicable and may detect changes in DNSSEC validation status that could indicate DNS security compromises or configuration issues.

[0246] A monitoring process configured to monitor host dependency objects may implement ping monitoring techniques that verify basic network connectivity to monitored hosts by sending ICMP echo requests and measuring response times and packet loss rates. The host monitoring process may implement TCP handshake monitoring techniques that verify specific network services remain accessible on monitored hosts by attempting to establish TCP connections to relevant service ports and measuring connection establishment success rates and response times.

[0247] The host monitoring process may implement traceroute monitoring techniques that analyze network routing paths to monitored hosts to detect changes in network topology that could indicate routing attacks, network infrastructure modifications, or connectivity issues. The traceroute monitoring may track the sequence of network hops traversed when reaching monitored hosts and may detect unusual routing changes or path modifications that could indicate BGP hijacking attempts or network misconfigurations.

[0248] A monitoring process configured to monitor BGP prefix dependency objects may implement BGP origin change monitoring techniques that detect unauthorized changes in the autonomous system that announces monitored IP prefixes. The BGP monitoring process may track BGP announcements received from multiple vantage points across the Internet to identify prefix hijacking attempts, route leaks, or routing misconfigurations that could affect traffic delivery to monitored network resources. The BGP monitoring may maintain databases of legitimate BGP announcement patterns and may detect deviations from expected routing behavior.

[0249] The BGP monitoring process may implement BGP prefix length monitoring techniques that detect sub-prefix announcements that may indicate more specific route announcements designed to hijack traffic destined for monitored IP prefixes. The BGP monitoring may analyze prefix length changes and may detect suspicious announcements of more specific prefixes that could redirect network traffic to unauthorized destinations. The BGP monitoring may also implement BGP path change monitoring techniques that detect unusual changes in AS-path information that may indicate route manipulation attacks or significant changes in Internet routing topology.

[0250] The BGP monitoring process may implement RPKI monitoring techniques that verify the validity of route announcements against Resource Public Key Infrastructure records Princeton - 105476 maintained by regional Internet registries. The RPKI monitoring may detect invalid route announcements that fail RPKI validation and may identify potentially malicious or misconfigured BGP announcements that could affect the security and availability of monitored network resources.

[0251] Each of the plurality7of monitoring processes may operate independently while sharing monitoring results and alert information through centralized data storage systems that enable coordination and correlation of monitonng data across different resource types. The monitoring processes may store monitoring measurements, detected anomalies, and alert information in shared databases that enable cross-correlation analysis and root cause identification across multiple network layers and dependency relationships.

[0252] The monitoring processes may implement different monitoring frequencies and measurement intervals based on the characteristics and requirements of each dependency object type. Time-sensitive resources such as DNS records and BGP routing information may be monitored more frequently than static content resources such as HTML files or JavaScript libraries. The monitoring frequency may be adjusted based on the criticality of each resource type and the likelihood of changes that could affect sen ice security or availability.

[0253] Each of the plurality of monitoring processes may be located in a respective geographic region of the network to provide comprehensive monitoring coverage and to detect localized effects that may not be visible from a single monitoring location. The geographic distribution of monitoring processes may enable the computer implemented method to identify network issues, attacks, or performance problems that may affect only specific regions, network paths, or autonomous systems. The distributed monitoring approach may provide multiple perspectives on network resource behavior and may enable detection of region-specific attacks or infrastructure issues.

[0254] A monitoring process located in a first geographic region may detect network routing changes, DNS resolution issues, or service availability problems that affect users or network infrastructure within that specific region. The first geographic region monitoring process may observe network behavior from the perspective of local Internet service providers, regional network infrastructure, and geographic-specific network paths that may not be representative of global network conditions. The regional monitoring may detect localized BGP hijacking attempts, regional DNS server issues, or content delivery network problems that affect only users within the specific geographic area.

[0255] A monitoring process located in a second geographic region may simultaneously monitor the same network resources from a different network perspective, potentially detecting Princeton - 105476 different issues or confirming that detected problems affect multiple regions. The second geographic region monitoring process may provide independent verification of network issues detected by monitoring processes in other regions and may help distinguish between localized network problems and global issues affecting monitored network services. The multi-region monitoring may enable identification of attack campaigns that target multiple geographic regions or network infrastructure issues that have widespread impact.

[0256] The geographic distribution may enable the computer implemented method to distinguish between legitimate regional variations in network behavior and potential security threats or infrastructure problems. Different geographic regions may exhibit different baseline network performance characteristics, routing patterns, or service availability metrics due to variations in local network infrastructure, Internet service provider configurations, or regional network policies. The distributed monitoring processes may establish region-specific baseline measurements that account for these legitimate variations while detecting anomalous behavior that may indicate security threats or operational issues.

[0257] The geographically distributed monitoring processes may coordinate through shared data storage and communication systems to enable correlation analysis across monitoring data collected from multiple geographic locations. Each monitoring process may store monitoring results, detected discrepancies, and alert information in centralized databases that enable analysis of patterns and trends across different geographic regions. The coordination may enable identification of attack patterns that affect multiple regions, infrastructure changes that have global impact, or performance issues that exhibit geographic correlation patterns.

[0258] The distributed monitoring approach may enable detection of sophisticated attacks that attempt to evade detection by targeting specific geographic regions or network paths. Attackers may implement region-specific BGP hijacking attempts that only affect routing within certain autonomous systems or geographic areas while leaving routing in other regions unaffected. DNS manipulation attacks may target specific DNS resolvers or regional DNS infrastructure while remaining invisible to monitoring systems operating in other geographic locations. The distributed monitoring processes may detect these targeted attacks by comparing monitoring results across multiple geographic regions and identifying discrepancies that may indicate region-specific attack activity.

[0259] The geographic distribution may provide redundancy in monitoring operations, ensuring that monitoring continues even if monitoring infrastructure in one region becomes unavailable due to network outages, infrastructure failures, or targeted attacks against monitoring systems. The distributed monitoring processes may implement failover Princeton - 105476 mechanisms that enable monitoring coverage to continue from other geographic regions when individual monitoring locations experience connectivity issues or system failures.

[0260] Each geographically distributed monitoring process may implement the same monitoring techniques for each type of dependency object while operating from different network vantage points and regional network infrastructure. The consistency in monitoring techniques across geographic regions may enable meaningful comparison of monitoring results and may facilitate identification of regional variations in network behavior or sen ice performance. The distributed monitoring processes may apply identical content type filtering, dependency analysis, and alert generation criteria to ensure consistent monitoring coverage across all monitored geographic regions.

[0261] The monitoring processes may implement region-specific configuration parameters that account for local network characteristics, regulatory requirements, or operational constraints while maintaining consistent monitoring methodologies across all geographic regions. The regional configuration may include adjustments for local network latency characteristics, regional Internet service provider configurations, or geographic-specific security policies that may affect monitoring operations without compromising the consistency of monitoring techniques applied to each dependency object type.

[0262] The geographically distributed monitoring processes may provide enhanced detection capabilities for attacks that exploit regional network infrastructure vulnerabilities or target specific geographic user populations. The distributed monitoring may detect content delivery network attacks that affect specific geographic regions, regional DNS poisoning attempts, or targeted BGP hijacking campaigns that focus on particular countries or network regions. The multi-region monitoring approach may enable comprehensive threat detection that accounts for the global nature of Internet infrastructure while providing detailed visibility into regionspecific network security issues.

[0263] A computer implemented method for discovering within a network one or more Domain Name System (DNS) servers associated with a network resource identified by a uniform resource locator (URL) may be provided to enable comprehensive mapping of DNS infrastructure dependencies that may affect the security and availability of monitored network resources. The computer implemented method may focus specifically on DNS server discovery and may provide detailed analysis of the complete DNS resolution infrastructure that supports network resources accessed through URL-based addressing schemes.

[0264] The computer implemented method may comprise recursively resolving and querying the names of nameservers associated with a DNS resolution of the network resource identified Princeton - 105476 by a uniform resource locator (URL) to determine thereby all dependency URLs and the fullgraph DNS lookups of the domains in these URLs. The recursive resolution process may extend beyond simple domain name lookups to comprehensively map the complete DNS infrastructure that supports each domain associated with the target network resource. The method may systematically discover all nameservers that may be involved in the DNS resolution process, including both direct nameservers and indirect nameservers that may be required to resolve the names of other nameservers within the resolution chain.

[0265] The recursive resolution process may begin by extracting domain names from the uniform resource locator provided as input to the method. The URL parsing may identify the primary domain name associated with the network resource as well as any subdomain components that may require separate DNS resolution processes. The method may analyze the URL structure to identify all domain name components that may require DNS resolution to access the target network resource, including the primary domain, any subdomain prefixes, and domain names that may be referenced within the URL path or query parameters.

[0266] The method may initiate DNS resolution queries for each identified domain name to determine the authoritative nameservers responsible for providing DNS records for those domains. The initial DNS queries may request NS (Name Server) records that identify the authoritative nameservers for each domain. The method may perform these initial queries using recursive DNS resolution techniques that may involve querying root nameservers, top-level domain nameservers, and authoritative nameservers in sequence to obtain complete nameserver information for each domain.

[0267] The recursive querying process may analyze the nameserver records returned by the initial DNS queries to identify' nameserver names that require additional resolution to determine their IP addresses. Many nameserver records may contain fully qualified domain names rather than IP addresses, requiring the method to perform additional DNS queries to resolve these nameserver names to their corresponding IP addresses. The method may recursively query' each nameserver name to obtain A records and AAAA records that provide IPv4 and IPv6 addresses for the nameservers.

[0268] The method may continue the recursive resolution process by querying the names of nameservers that are discovered during the nameserver name resolution process. When resolving nameserver names to IP addresses, the method may discover additional nameservers that are responsible for resolving the nameserver names themselves. The method may recursively query these additional nameservers to map the complete hierarchy of DNS Princeton - 105476 infrastructure that may be involved in resolving the original domain names associated with the target network resource.

[0269] The recursive nameserver querying may include analysis of glued nameserver records that may be included in the "Additional" section of DNS responses. Glued nameserver records may provide IP addresses for nameservers within the same domain zone, enabling the method to identify nameserver infrastructure that may be directly accessible without requiring additional DNS queries. The method may extract glued nameserver IP addresses from DNS response packets and may include these addresses in the comprehensive mapping of DNS infrastructure dependencies.

[0270] The method may also identify and resolve glueless nameserver records that may be referenced by name in DNS responses but may not include corresponding IP addresses in the response packet. Glueless nameservers may require the method to perform separate DNS queries to determine the IP addresses of these nameservers. The method may recursively query these glueless nameserver names to obtain their IP addresses and may continue this recursive process to identify any additional nameservers that may be involved in resolving the glueless nameserver names.

[0271] The recursive resolution process may include analysis of CNAME and DNAME record chains that may redirect domain name resolution to alternative domain names. When domain names are configured with CNAME records that redirect to other domain names, the method may follow these redirection chains to identify all intermediate domains and their associated nameserver infrastructure. The method may recursively resolve each domain in the CNAME chain to map the complete DNS dependency structure that may be involved in resolving the original domain name to its final IP address.

[0272] The method may track DNAME records that provide domain name redirection at the zone level and may recursively resolve the target domains specified in DNAME records. DNAME records may redirect entire subtrees of domain names to alternative domain hierarchies, requiring the method to analyze the target domain hierarchy and recursively resolve all nameservers associated with the redirected domain structure. The DNAME resolution process may identify additional DNS infrastructure dependencies that may not be apparent from analysis of the original domain names alone.

[0273] The recursive querying process may implement loop detection mechanisms to prevent infinite recursion when nameserver resolution chains contain circular references or when nameserver names reference themselves or other nameservers within the same resolution chain. The method may maintain records of previously queried nameserver names and may detect Princeton - 105476 when the recursive resolution process encounters nameserver names that have already been processed. The loop detection may enable the method to terminate recursive resolution chains appropriately while ensuring that all legitimate nameserver dependencies are discovered and mapped.

[0274] The method may determine all dependency URLs by analyzing the complete set of nameserver IP addresses and domain names discovered during the recursive resolution process. The dependency URLs may include references to all nameservers that may be contacted during DNS resolution of the target network resource, formatted as URLs that may be used for monitoring and analysis purposes. The method may construct dependency URLs that reference each discovered nameserver using appropriate URL schemes and addressing formats that enable subsequent monitoring systems to access and analyze the nameserver infrastructure.

[0275] The full-graph DNS lookups of the domains in the dependency URLs may provide comprehensive information about all DNS infrastructure components that may be involved in resolving the domains associated with the discovered nameservers. The method may perform complete DNS resolution analysis for each domain name associated with the discovered nameservers, recursively applying the same nameserver discovery techniques to map the DNS infrastructure that supports the nameserver domains themselves. This recursive analysis may reveal additional layers of DNS dependencies that may affect the overall security and availability of the target network resource.

[0276] The method may organize the discovered DNS infrastructure information in hierarchical data structures that represent the relationships between different levels of nameservers and the domains they serve. The hierarchical organization may show how root nameservers, top-level domain nameservers, authoritative nameservers, and recursive nameservers may be interconnected within the DNS resolution process. The data structures may include information about nameserver roles, resolution dependencies, and the sequence of DNS queries that may be required to resolve the target network resource.

[0277] The full-graph DNS lookup results may include detailed information about each discovered nameserver, including IP addresses, domain names, geographic locations, autonomous system numbers, and organizational ownership information. The method may uery additional databases and information sources to obtain metadata about each discovered nameserver that may be relevant for security analysis and monitoring purposes. The metadata may include information about nameserver software versions, security configurations, and historical behavior patterns that may affect the reliability’ and security’ of DNS resolution processes. Princeton - 105476

[0278] The method may validate the completeness and accuracy of the recursive resolution results by performing verification queries and cross-referencing discovered nameserver information against multiple DNS resolution paths. The validation process may involve querying the same domain names from multiple network locations and comparing the nameserver discovery results to ensure consistency and completeness. The method may identify discrepancies in nameserver discovery results that may indicate DNS configuration issues, security problems, or incomplete resolution processes.

[0279] The recursive resolution and querying process may be performed from multiple network vantage points to account for regional variations in DNS infrastructure and to detect nameserver configurations that may vary' based on the geographic location or network path of DNS queries. Different network locations may observe different nameserver configurations due to anycast routing, geographic load balancing, or regional DNS infrastructure variations. The method may aggregate nameserver discovery' results from multiple network locations to create comprehensive mappings of all possible DNS infrastructure dependencies.

[0280] The method may implement caching mechanisms that store previously discovered nameserver information to improve the efficiency of recursive resolution processes when analyzing multiple network resources that may share common domain names or DNS infrastructure. The caching may reduce the number of DNS queries required for subsequent nameserver discovery operations while ensuring that cached information remains current and accurate. The method may implement cache invalidation policies that refresh stored nameserver information at appropriate intervals to account for changes in DNS infrastructure configurations.

[0281] The recursive nameserver discovery process may be integrated with monitoring systems that track changes in DNS infrastructure over time to detect modifications in nameserver configurations that may indicate security threats or operational issues. The method may provide baseline nameserver discovery7results that may be compared against subsequent discovery7operations to identify changes in DNS infrastructure that may affect the security7and availability of monitored network resources. The change detection capabilities may enable identification of DNS hijacking attempts, nameserver compromises, or infrastructure modifications that could impact network resource accessibility.

[0282] A computer implemented method for discovering within a network one or more Domain Name System (DNS) servers associated with a network resource identified by a uniform resource locator (URL) may be provided to enable comprehensive analysis of DNS infrastructure hierarchies and nameserver dependencies that extend beyond simple domain Princeton - 105476 resolution processes. The computer implemented method may comprise recursively resolving and querying the names of nameservers associated with a DNS resolution of the network resource identified by a uniform resource locator (URL) to determine thereby nameservers responsible for resolving the names of nameservers that are associated with a DNS resolution, any multiple levels of the resolved nameservers, and nameserver resolution along CNAME / DNAME chains.

[0283] The recursive resolution and querying process may begin by identifying nameservers responsible for resolving the names of nameservers that are associated with a DNS resolution of the target network resource. When initial DNS queries return nameserver records that contain fully qualified domain names rather than IP addresses, the method may identify these nameserver names as requiring additional resolution to determine their corresponding IP addresses. The method may analyze each nameserver name to determine which additional nameservers may be responsible for resolving these nameserver names to their IP addresses.

[0284] The method may query' the nameservers responsible for resolving nameserver names by performing DNS lookups for the domain zones that contain the nameserver names. When a nameserver name such as "nsl.example.com" is discovered during initial DNS resolution, the method may identify that nameservers responsible for the "example.com" domain zone may be required to resolve this nameserver name to its IP address. The method may recursively query' these responsible nameservers to obtain A and AAAA records that provide IPv4 and IPv6 addresses for the original nameserver names.

[0285] The recursive querying process may continue by identifying nameservers that may be responsible for resolving the names of the nameservers that were discovered during the nameserver name resolution process. When resolving nameserver names to IP addresses, the method may discover that the nameservers responsible for these resolutions may themselves have names that require additional DNS resolution. The method may recursively identify and query' the nameservers responsible for resolving these additional nameserver names, creating multiple levels of nameserver resolution dependencies.

[0286] The method may determine any multiple levels of the resolved nameservers by systematically tracking the hierarchical relationships between nameservers at different levels of the DNS resolution process. The multiple levels may include root nameservers that provide referrals to top-level domain nameservers, top-level domain nameservers that provide referrals to authoritative nameservers for specific domains, authoritative nameservers that provide DNS records for target domains, and additional levels of nameservers that may be required to resolve the names of nameservers at each level of the hierarchy. Princeton - 105476

[0287] The recursive resolution process may identify first-level nameservers that are directly responsible for providing DNS records for the target domain associated with the network resource URL. The method may then identify second-level nameservers that may be responsible for resolving the names of the first-level nameservers when these nameserver names require additional DNS resolution. The method may continue this process to identify third-level nameservers that may be responsible for resolving the names of the second-level nameservers, and may continue recursively to identify additional levels of nameservers as required by the DNS resolution dependencies.

[0288] Each level of resolved nameservers may include multiple nameserver instances that provide redundancy and load distribution for DNS resolution processes. The method may identify’ all nameservers at each level of the resolution hierarchy, including primary nameservers, secondary nameservers, and backup nameservers that may be configured to provide DNS resolution services for each domain zone. The multiple levels of resolved nameservers may create complex dependency trees where nameservers at higher levels depend on the proper functioning of nameservers at lower levels within the resolution hierarchy.

[0289] The method may track the relationships between nameservers at different levels by maintaining hierarchical data structures that represent the dependencies between nameserver levels. The data structures may indicate which nameservers at each level depend on nameservers at other levels for successful DNS resolution. The method may identify critical nameservers that support multiple levels of the resolution hierarchy and may represent single points of failure that could affect DNS resolution for the target network resource.

[0290] The recursive resolution process may implement nameserver resolution along CNAME / DNAME chains by following canonical name redirections and domain name redirections that may alter the DNS resolution path for the target network resource. When DNS queries encounter CNAME records that redirect domain names to alternative domain names, the method may recursively resolve the target domain names specified in the CNAME records. The CNAME resolution process may require identification and query ing of additional nameservers that may be responsible for the redirected domain names.

[0291] The method may analyze CNAME chains that may involve multiple levels of redirection where one CNAME record points to another domain name that may itself be configured with additional CNAME records. The recursive CNAME resolution may follow these redirection chains to their final destination while identifying all nameservers that may be involved in resolving each domain name within the CNAME chain. The nameserver resolution Princeton - 105476 along CNAME chains may reveal additional DNS infrastructure dependencies that may not be apparent from analysis of the original domain name alone.

[0292] The DNAME record resolution process may involve analysis of domain name redirections that affect entire subtrees of domain names rather than individual domain names. When DNS queries encounter DNAME records, the method may identify the target domain hierarchy specified in the DNAME record and may recursively resolve all nameservers associated with the redirected domain structure. The DNAME resolution may require analysis of the nameserver infrastructure that supports the target domain hierarchy, including all levels of nameservers that may be involved in resolving domain names within the redirected domain subtree.

[0293] The method may handle complex CNAME / DNAME resolution scenarios where canonical name redirections and domain name redirections may be combined within the same DNS resolution process. The recursive resolution may follow both CNAME and DNAME redirections while tracking the nameservers responsible for each step of the redirection process. The combined CNAME / DNAME resolution may create complex dependency chains where nameservers at multiple levels and in multiple domain hierarchies may be required for successful DNS resolution of the target network resource.

[0294] The nameserver resolution along CNAME / DNAME chains may include validation of redirection limits and loop detection to prevent infinite recursion when redirection chains contain circular references. The method may implement maximum redirection depth limits that prevent excessive recursion while ensuring that legitimate redirection chains are followed to completion. The loop detection mechanisms may identify when CNAME or DNAME redirections create circular references and may terminate the recursive resolution process appropriately.

[0295] The recursive querying process may maintain comprehensive records of all nameservers discovered at each level of the resolution hierarchy and along each CNAME / DNAME redirection path. The method may create detailed mappings that show the complete DNS infrastructure required to resolve the target network resource, including all nameservers responsible for resolving nameserver names, all multiple levels of resolved nameservers, and all nameservers involved in CNAME / DNAME chain resolution.

[0296] The method may organize the discovered nameserver information in structured data formats that represent the hierarchical relationships and dependencies between nameservers at different levels and along different resolution paths. The structured representation may enable analysis of the complete DNS attack surface associated with the target network resource and Princeton - 105476 may support identification of critical nameserver dependencies that could affect DNS resolution reliability and security.

[0297] The recursive resolution and querying process may be performed using multiple DNS query techniques and protocols to ensure comprehensive discovery of nameserver dependencies. The method may utilize both recursive and iterative DNS query' approaches to obtain complete nameserver information from different perspectives within the DNS infrastructure. The method may query multiple types of DNS records, including NS records, A records, AAAA records, CNAME records, and DNAME records, to build comprehensive mappings of nameserver relationships and dependencies.

[0298] The method may implement error handling and retry mechanisms that account for temporary DNS resolution failures or network connectivity’ issues that may occur during the recursive querying process. The error handling may enable the method to continue nameserver discovery' operations even when individual DNS queries fail or when specific nameservers become temporarily unavailable. The retry mechanisms may ensure that transient network issues do not prevent complete discovery of nameserver dependencies.

[0299] The recursive nameserver discovery' process may include analysis of DNS response timing and performance characteristics to identify nameservers that may experience performance issues or connectivity' problems. The method may measure DNS query' response times and success rates for each discovered nameserver to provide performance information that may be relevant for monitoring and analysis purposes. The performance analysis may help identify nameserver dependencies that may be more likely to experience availability or performance issues.

[0300] The method may validate the accuracy and completeness of the recursive nameserver discovery’ results by performing verification queries from multiple network locations and comparing the discovered nameserver information for consistency. The validation process may identity' discrepancies in nameserver discovery' results that may indicate DNS configuration issues, regional variations in DNS infrastructure, or potential security problems affecting DNS resolution processes.

[0301] To address gaps in conventional approaches, this example presents an embodiment of the disclosed technique, referred to herein as Layer? monitoring (named after the top layer of the OSI model), which takes a novel approach to monitoring. Layer? monitoring analyzes the status of all resources required to deliver a network sendee and processes alerts on these Princeton - 105476 resources in a holistic manner. This allows Layer? monitoring to fully understand how these alerts relate to the security and availability a monitored service and go beyond the limited and piecewise approach of other monitoring.

[0302] System Overview.

[0303] At the core of Layer? monitoring is the concept of a dependency graph which spans across multiple layers of the network stack and shows all the dependencies related to a monitored service as well as how these dependencies relate to each other. Layer? monitoring first builds the dependency graph from web browser logs, automatically begins monitoring on all relevant resources in the dependency graph, and then analyzes changes in resources in light of the dependency graph to provide accurate alerts, root cause analysis, and issue mitigation.

[0304] Understanding Dependencies. Layer? monitoring takes a distinct approach to monitoring by monitoring the complete set of dependencies associated with a web sendee instead of a incomplete and inadequate subset. For a particular target webpage, many monitoring services primarily run commands on a loop to fetch the given webpage and confirm it is up as well as record performance metrics. Some more advanced monitoring services will also monitor some of the resources associated with this webpage at different layers of the network stack. This can include monitoring the Border Gateway Protocol (BGP) for updates related to the IP addresses that serve this webpage or performing checks in the Domain Name Service (DNS) servers that resolve the relevant domain name to an IP address. However, the simplistic ways that existing monitoring sendees (even the most reputable offerings) discover dependencies leave a massive number of dependencies that affect a webpage's performance and security unmonitored.

[0305] Unlike other systems, when pointed to a target resource, Layer 7 monitoring begins by loading the resource in a real web browser and observing all network requests that occur when loading or interacting with that resource. Network requests are then filtered to identify performance and security sensitive requests (e.g., Javascript file loads which can be used to take over the entire webpage). This is vastly superior to the strategy used by other monitoring services which assume the only resources related to a webpage load are hosted by main domain hosting that webpage. FIG. 2 shows a simple webpage and the resources discovered by Layer? monitoring compared with the resources that would be been monitored using a more simplistic monitoring system. Princeton - 105476

[0306] Another advantage of this approach is that entire interactions with a web service can be monitored. While the input to traditional monitoring is a webpage URL, Layer? monitoring can dynamically record all the dependencies involved in an entire web transaction. While some monitoring services claim to monitor web transactions through webpage automation (using frameworks like Selenium or Playwright), this is not a cross-layer approach and is more like an advanced webpage status check. Other monitoring services interact with a webpage following a fixed transaction pattern and ensure certain properties are met (e.g., the user is redirected to / profile after logging in successfully). However, in the event of a Man-in-the- Middle attack, such checks are unlikely to trigger an alert as accurately mimicking the benign behavior of the w ebpage is actually the adversary's goal with this attack. Layer? monitoring's approach to webpage interactions is significantly different. In addition to these basic checks, Layer? monitoring can record all resources that are touched during this transaction (e.g., third- party login APIs like Duo Security or external Central Authentication Service login) and then automatically begin monitoring all of these resources.

[0307] Building a Dependency Graph. Having extracted the dependencies of a web service from real browser network requests, Layer? monitoring builds a crosslayer dependency graph. This directed graph spans across all network layers and nodes represent individual dependencies while directed edges represent one resource that is dependent on the operation of another resource. This graph has several unique properties that allow it to power Layer? monitoring's advanced threat intelligence insights as well as provide timely and accurate root cause analysis.

[0308] An important feature of this graph is that it is inherently cross-layer. Prior work on dependency graphs has focused on a single layer of the network stack (particularly DNS

[0010] ) and not explored dependency graphs in a monitoring context. The edges of this graph represent cross-layer dependencies. For example (shown in FIG. 2), a webpage, say example.com / home.html, depends on the proper functioning of the domain name example.com. This means the web page has an edge towards the domain example.com in the dependency graph. This domain is dependent on two resources: the hosts that serve the domain (i.e., the hosts pointed to by A and AAAA records) and the DNS records that allow for the resolution of that domain. Each of these are connected to the webpage using more edges. These DNS records are in tem served by more hosts that are responsible for operating authoritative DNS servers. Finally, every host is dependent on the BGP announcements that provide routing connectivity to that host. Princeton - 105476

[0309] Using the Dependency Graph for Monitoring. The reason this particular realization of a cross-layer dependency graph is so crucial in a monitoring context is because this graph allows for root-cause analysis and allows benign events to be differentiated from malicious attacks. Upon discovering the dependency graph, Layer? monitoring begins monitoring on all resources identified in the dependency graph. For each resource, several monitoring techniques are employed depending on what layer that resource lies at. For example, a domain is monitored in Certificate Transparency (CT) logs as well as through connections to determine the health of the server software that serves that domain name. Hosts are monitored for up-time and open ports. These are just a few of the ways various resources are monitored. This framework is inherently extensible allowing for the monitoring of each resource in many different ways.

[0310] Monitoring signals from these different sources can be extrapolated across the dependency graph to gain deeper insights into events. Let us take an outage for example. Traditionally, an outage in a web service would trigger manual investigation into the cause of the outage which would eventually lead to remediation. However, incident response time is critical so reducing the need to manually investigate outages vastly improves an organizations ability to serve customers and maintain Service Level Agreements (SLAs). Furthermore, automatic root-cause analysis can be used to trigger automatic remediation which ultimately leads to significantly more resilient systems. By analyzing the dependency graph. Layer 7 monitoring can identify the root cause of this incident. If for instance the outage was caused by a misconfigured DNS server, Layer? monitoring would notice a series of alerts including an abnormal response from the DNS server in question as well as failures of all resources that depended on that DNS server (e g., the domain and any content hosted at that domain). Thus, Layer? monitoring can analyze all of these anomalies in light of the dependency graph to identify that the DNS server configuration change is the root cause of the outages at dependent downstream resources (e.g., the webpage in question). The dependency graph makes root cause analysis simple: the root cause of an event is the earliest dependency that noticed a correlated alert during the event. In this case, the earliest dependency noticing an alert is the DNS response required to serve the domain in question. This can lead teams directly to the core of the issue or enable automatic remediation.

[0311] In addition to root-cause analysis, monitoring signals from resources at different layers can reduce false positives. Again, consider the DNS server misconfiguration discussed before. While a DNS misconfiguration has a disastrous effect on system availability, benign DNS changes are commonplace. Furthermore, if DNS servers are managed by third-party providers Princeton - 105476

[0312] (or are even related to a 3rd- party resource like an external JavaScript file), enterprise monitoring teams may not even have knowledge as to how or when these DNS changes occur. If all DNS record changes produce equal priority alerts, a monitoring team may be flooded with completely benign DNS record change alerts. If these alerts are dropped altogether, the monitoring teams ability to quickly identify the root cause of an outage like the one previously- discussed is significantly hindered. Thus, the dependency graph employed by Layer? monitoring allows for the strategic prioritization of alerts at critical times based on the presence of downstream alerts. Typically, a DNS change does not need to be a high priority alert. However, if this change is correlated with the outage of a critical web service and the web service was dependent on the DNS records in question, this allows Layer? monitoring to give this alert the priority it needs and highlight it as the root cause of the downstream event.

[0313] A ttack Example.

[0314] Layer? monitoring outperforms the state of the art in detecting numerous real-world attacks. In this section we provide an analysis of how Layer? monitoring would have detected the KLAYSwap BGP attack that stole $2 million dollars in cryptocurrency.

[0315] The KLAYSwap attack involved attackers targeting a JavaScript file that was loaded on to the KLAYSwap platform. The attacks launched a BGP hijack against the host that was serving this file. Using this BGP hijack, the attackers obtained a malicious certificate for the domain that was hosting this JavaScript. Finally, the attacks served malicious JavaScript that compromised the KLAYSwap platform and redirected cyrptocurrency transfers to an attack- controlled account.

[0316] It is important to realize that if existing monitoring systems were told to monitor the KLAYSwap website, they would not have caught this attack at all. This is because existing monitoring does not perform dependency discovery or monitor any JavaScript dependencies. Existing monitoring systems only focus on monitoring of a small portion of the dependency graph, the HTML page itself and the immediate DNS servers and hosts needed to serve that page. Other dependencies (like additional DNS servers or JavaScript files used by the webpage) are ignored. In the KLAYSwap attack the primary HTML page was unmodified and the malicious JavaScript operated invisibly to channel funds in the background and not change the user experience. Layer? monitoring takes a distinct approach: monitoring all dependencies which lets it catch software supply chain attacks like the one that compromised the KLAYSwap platform. Princeton - 105476

[0317] Had KLAYS wap's webpage been the target of Layer? monitoring, several alerts including high-priority cross-layer alerts would have been triggered. Using automated dependency discovery. Layer? monitoring would have known about the JavaScript file and the hosts that were serving it. The BGP prefixes these hosts ran on would be monitored in BGP. Thus, as soon as the adversary 's BGP attack was active an alert would have been triggered detecting the suspicious prefix length change, origin, and path. Then, when the adversary obtained its malicious certificate, Layer? monitoring would have detected this in Certificate Transparency logs and noticed the served certificate for the domains hosting the JavaScript was updated. Finally, Layer? monitoring would notice that correlated with all of these changes was a JavaScript file contents change. These changes all in related parts of the dependency graph would have generated a high-priority alert that could have alerted the KLAYSwap operators to the attack, so they could have mitigated the damage.

[0318] Implementation.

[0319] This example implementation consists of several engines: (1) the dependency discovery engine; (2) the graph construction engine; (3) the monitoring engines; (4) the alerting engine; and (5) the visualization engine. Each of these engines interconnect using a persistent storage system (implemented in PostgreSQL). Each of these engines handle a part of the Layer? monitoring process.

[0320] Dependency Discovery Engine. The first step required for monitoring is the discovery of the dependencies associated with a network service. The dependency discovery engine handles this by instrumenting the Chrome web browser. Given a target webpage URL, the dependency discovery engine opens the URL in Chrome using the web-browser automation framework Selenium. Alternatively, dependencies associated with an entire web browsing session can be discovered by a user manually interacting with a web service in a browser that is being monitored by the dependency discovery' engine.

[0321] Given a browser session (either managed by Selenium automation or by manual user interaction), the dependency discovery engine extracts the debug network logs associated with that browser session. The engine finds all network requests and responses and joins the requests with the responses (which are logged as separate entries). Then, network request filtering is performed based on the "content-type" header of the network responses. Some content types (e.g., images or fonts) do not pose a significant security or availability risk (these can be optionally monitored in addition). These are filtered out to give priority to HTML, JavaScript Princeton - 105476 and other responses critical to the functionality' and security of the web browser session. Once the proper responses are identified based on content-type headers, the URLs associated with these responses are extracted to create a set of dependency URLs by content type.

[0322] For each dependency URL, the relevant domain name is extracted, and a full-graph DNS lookup is performed. The full-graph DNS resolver is similar to the system used by Cimaszewski et al. Full-graph DNS resolution is a much more rigorous approach to DNS dependencies than the straw man solution sometimes employed by other monitoring services of looking up the domain name in NS and only monitoring the IP address of these nameservers found which actually represent a fraction of the DNS attack surface. The full-graph DNS resolver recursively resolves the domain name and records the IP addresses of all nameservers involved in the DNS lookup (as well as all A and AAAA records found for the domain). This includes "glued" nameserver IP addresses (which are included in the "Additional" section of DNS responses), "glueless" or "unglued" nameserver IP addresses (i.e., the IP addresses of nameservers that need to be looked up in a separate DNS query as they are not included in the "Additional" section of DNS responses), the IP addresses of nameservers involved in the lookup of "glueless" nameservers, and the IP addresses of nameservers involved in the resolution of CNAME chains. This methodology7extensively covers the DNS attack surface and produces a list of IP addresses which could be used to target the given domain. Furthermore, nameservers that benefit from security protections like DNSSEC are noted in the response allowing for consideration of these security protections in other parts of the monitoring infrastructure.

[0323] All dependency URLs and the full-graph DNS lookups of the domains in these URLs are packaged into a JSON dependency object that represents the attack surface for the target web service. This dependency object is passed to the graph construction engine.

[0324] Graph Construction Engine. The graph construction engine needs to turn a dependency object into a structured dependency graph that properly shows how each of these dependencies relate to each other and contains more information about each of these dependencies in various layers of the network stack. The dependency graph is built outwork with the central node being the primary' monitoring target. Then URL dependencies (e.g., JavaScript and HTML files) that were discovered by the Dependency Discovery Engine are added as nodes and connected via edges to the primary monitoring target. After these, domains associated with those URLs are added. Then IP addresses and DNS results associated with those domains are added. Princeton - 105476

[0325] In addition to adding nodes for all of the different fields in the dependencies object, the Graph Construction Engine expands some dependencies into multiple nodes because these dependencies exist at multiple layers of the network stack. For example, a host IP address that runs either a webserver or nameserver requires both data plane and control plane connectivity. Thus, host IP addresses are expressed at two layers: once at the data plane layer (which can be monitored via traceroute and ping) and once at the BGP layer that is used in BGP monitoring. An edge is added between the data plane layer and the BGP layer as data-plane connectivity is dependent on BGP connectivity.

[0326] In addition to building the dependency graph, the graph construction engine labels the graph in a way that is conducive to further use. The "type" property indicates what type of resource is represented by that node (e.g., a host, domain, JavaScript file) and this is used later by the monitoring engine to determine which types of monitoring need to be initiated. Additional information about why the node was included in the final graph (e.g., through a JavaScript dependency, or a DNS dependency) is also included to facilitate easy filtering.

[0327] Monitoring Engines. With the dependency graph built, monitoring is initiated on the various dependencies. Each monitoring technique is implemented in a different monitoring engine. Monitoring engines load the graph created by the graph construction engine from a database and then select nodes of the appropriate type to begin monitoring. The methods used to actually perform monitoring are extensible and a single resource type can be monitored via many different methods. Some monitoring types by resource include:

[0328] 1. Resource: HTML / JavaScript Files, such as (a) File contents monitoring, (b) Availability' monitoring, and / or (c) Load time monitoring.

[0329] 2. Resource: TLS Domains, such as (a) Certificate Transparency (CT) monitoring, (b) Served certificate monitoring, and / or (c) TLS handshake monitoring.

[0330] 3. Resource: DNS records, such as (a) Record availability monitoring, (b) Record contents monitoring, (c) Latency monitoring, and / or (d) DNS SEC status monitoring

[0331] 4. Resource: Hosts, such as (a) Ping monitoring, (b) TCP handshake monitoring, and / or (c) Traceroute monitoring.

[0332] 5. Resource: BGP prefixes, such as (a) BGP origin change monitoring, (b) BGP prefix length monitoring, (c) BGP path change monitoring, and / or (d) RPKI monitoring.

[0333] In addition to monitoring different resource ty pes at these different layers, the monitoring engines are geographically distributed to provide monitoring in each geographic region around the globe. This allows for localized effects to be noted. Princeton - 105476

[0334] Alerting Engine. Monitoring engines can raise alerts or record discrepancies that could lead to an alert. However, ultimately the most valuable cross layer alerts, which identify the root cause of events by performing analysis across multiple layers, need to be generated by a separate engine that has a view of what is happening at all layers of the dependency graph. This is handled by the alerting engine.

[0335] When a monitoring engine notices a change in the resource it is monitoring it updates the monitoring database with the relevant change. It then triggers a graph analysis by the alerting engine. The primary methodology deployed by the alerting engine is graph transversal over the dependency graph. The alerting engine loads the dependency graph and any alerts that have been raised by the monitoring engines on various resources in the dependency graph. The job of the alerting engine is to see how various active alerts interact with each other. This is done by iterating through active alerts and then climbing up the directed dependency graph towards the root node (i.e., the monitored resource) to see if this alert is downstream from any other active alerts.

[0336] Identifying alerts that are topologically related to each other is crucial as it allows the priority of these alerts to be elevated (and generate a more significant cross-layer alert) and allows for root-cause analysis.

[0337] For example, imagine a webpage that loads a single external JavaScript file. The root node of this dependency graph would be the single monitored webpage load. There would be two dependent file nodes for this page: the HTML file that comprised the webpage itself and the external JavaScript dependency file. Each of these files are hosted by separate webservers which would be dependencies below each file. For this example, call these Whtmland Wjs. Imagine the HTML page is monitored, and it fails to load. This would cause an alert by the file monitoring engine. Furthermore, the Whtmlstops responding to pings and TCP handshakes when it previously did. There would also be an alert at Whtmt. The alerting engine would process these alerts and realize that Whtmiwas a dependency of the HTML file resource. Thus, it can generate a cross-layer alert showing that the outage at the webserver host Whtmithat was serving the HTML file was the root cause of the outage of the HTML file.

[0338] This ability to analyze the topological placement of alerts in the dependency graph significantly improve the accuracy of this system. For example, a naive algorithm could be generated where alerts at different layers always triggered a cross-layer alert. However, this would flag false positives in cases where for instance the server hosting the JavaScript file W.s Princeton - 105476 had a status change contemporaneously with the HTML file becoming unavailable. Based on the dependency analysis, the alerting engine can realize that these two events cannot have a causal relationship based on their position in the dependency graph. This would eliminate this as a potential root cause.

[0339] In this manner, cross-layer alerts provide high-priority7notifications to operators with information about root causes which can quickly allow operators to identify what is happening.

[0340] Visualization Engine. The dependency graph and the active alerts need to be visualized in a way that operators can understand how the system works and what needs their attention. This is handled by the visualization engine. The visualization engine produces an annotated, color coded, and icon-based view of the dependency graph with organizational structures designed to help operators clearly see what is going on.

[0341] The visualization engine begins by rendering a simple view of the dependency graph. However, this is not particularly human-interpretable given the large number of different types of nodes. A first step is assigning unique icons and coloring the nodes by dependency type. Furthermore, certain properties of the nodes can be annotated with different icons. For example, some BGP prefixes are protected with RPKI, and this is shown with an additional icon on those nodes. The visualization engine also adds descriptive labels to nodes and more human-readable names.

[0342] Another role of the visualization engine is to reduce the number of nodes shown in order to make the graph simpler to interpret. This is done by clustering nodes of the same type that have the same set of dependencies (e.g., if the same domain hosts five files that are all used in the same downstream dependency these files can be clustered) and filtering. Filters utilize tags added by the graph construction engine to remove all resources that are associated with particular dependency types (e.g., JavaScript dependencies). This way if a network operator is trying to investigate the behavior of an HTML page independent of loaded JavaScript dependencies, the graph becomes simpler to interpret.

[0343] The visualization engine also interacts with the alerting engine to show alerts on the graph visualization. This is indicated by color and label changes to quickly show which resources have an active alert. Cross-layer alerts are also shown with additional colors to draw attention to more critical alerts. Alert details can be viewed by clicking on the nodes with the active alerts or in the alert list.

[0344] In addition to graph visualization, the visualization engine produces timeseries plots based on data from the monitoring engine each resource. Princeton - 105476

[0345] Example Use Cases of Layer? Monitoring.

[0346] The ability to monitor network services is crucial and has several different diverse use cases. Furthermore, the ability to automatically discover dependencies and properly prioritize alerts makes Layer? monitoring superior to traditional monitoring for 3rd-party websites and services. Thus, Layer? monitoring has a broad set of use cases beyond just standard enterprise service monitoring.

[0347] Enterprise Service Monitoring. Large enterprises operate critical sendees relied upon by millions of people. Layer? can provide insight into the security and availability of services used by large enterprises.

[0348] Monitoring of the Services Relied Upon by Blockchain Oracles. Oracles retrieve off- chain information (e.g., the price of a commodity) and provide it for on-chain usage like in Etherium smart contracts. Many oracles rely on HTTPS connections to obtain off-chain info. Existing solutions focus on oracle integrity and ensure that oracles properly implement the TLS protocol, validate certificates received, and can produce attestations for the data provided from a TLS endpoint. However, these measures do not mitigate the risk of attacks like the KLAYSwap attack where an adversary obtains a fraudulent certificate. Both DECO and Town Crier used by the popular oracle service Chain Link can be fooled by an adversary’ that has access to a malicious certificate because in this scenario the oracles are actually behaving properly.

[0349] This motivates the need for network monitoring of the sen-ices contacted by oracles. Layer? monitoring can be used in this setting to vouch for the security status of a service (e.g., an HTTPS endpoint that is providing bitcoin price information) that is being contacted by an oracle. In the event Layer? monitoring detects an attack on the service, it can raise an alarm letting oracles and smart contracts know the data source is potentially untrusted. Furthermore, this information can be brought on-chain by a special Layer? monitoring oracle that vouches for the status of HTTPS endpoints which are being relied on in smart contracts. This data can be used to make more robust smart contracts that cannot be fooled by certificate miss-issuance. A simple example is a contract that checks the price of a currency using an oracle and checks Layer? monitoring's oracle to determine the health of the HTTPS endpoint that was used to fetch this price. The contract would then only proceed should Layer? monitoring report the resource was not under attack. Princeton - 105476

[0350] Monitoring ofMCP Endpoints. Model Context Protocol or MCP utilizes the HTTPS transport to deliver messages between an MCP client and MCP server. This communication enables Al agents to gain access to information, tooling, and resources offered by the MCP server. If communication with an MCP server is intercepted and or manipulated by the adversary', the Al agent could become compromised and leak sensitive information to the adversary’, or take malicious actions on the adversary's behalf. The security’ of the streamable HTTP transport layer defined in the MCP specification can be implemented using HTTPS which is vulnerable to the interception attacks Layer? monitoring is designed to prevent. If an adversary’ is able to obtain a malicious certificate for the HTTS endpoint used by MCP (e.g., through a network attack), the adversary can impersonate the legitimate MCP server and send malicious responses to the Al systems that were using that server. Layer? monitoring can monitor the resources used to host the HTTPS endpoint used by MCP. Layer? monitoring can detect attacks on these resources and correlate these attacks across layers to identify attack patterns that are affecting the integrity of the HTTPS endpoint used by MCP. Layer? monitoring can also track the behavior of the MCP server over time and correlate suspicious behavior changes with attacks on underlying network resources to produce high-priority alerts indicating MCP compromise. Layer? monitoring can be integrated into Al systems that rely on MCP servers to inform these systems of MCP server compromises, allowing the systems to take appropriate precautions (e.g., temporarily disabling the connection to that particular MCP server).

[0351] The disclosed approach provides for the analysis of web browser logs to discover resources for monitoring purposes, including (a) filtering of browser logs to identify performance, availability’, and / or security-critical resources for monitoring purposes, and (b) analysis of identifiers found in browser logs to identify dependencies related to those identifiers including but not limited to full-graph DNS lookups of domain names found.

[0352] The disclosed approach also provides for construction of a resource dependency graph for the purpose of monitoring, including (a) the construction of such a graph that contains resources which are at different layers of the network stack, (b) the construction of such a graph based on browser logs, (c) the monitonng of resources contained in such a graph, and (d) the analysis and / or prioritization of data generated by monitoring based on the properties of such a graph.

[0353] Such analysis may be used to identify the root cause of an incident, differentiate security-related incidents from others, reduce false positive alerts raised by monitoring, identify critical resources that have a disproportionate amount of downstream dependencies, and / or Princeton - 105476 increase the priority of alerts generated by monitoring ad individual nodes and / or generate new alerts derived from data collected at multiple nodes in such a graph. The prioritization may involve the prioritization of monitoring on resources that have disproportionate amount of downstream dependencies as identified by such a graph. The disclosed approach provides for the automatic discovery and monitoring of APIs, externally-loaded code (including but not limited to JavaScript code), configuration files, markup files (including but not limited to HTML files), stylesheets and other resources loaded by a target web page or during a web browser interaction, mobile application interaction, or software program usage. This may include monitoring of such resources at multiple layers of the network stack.

[0354] The disclosed approach provides network monitoring data on-chain via an oracle for the use of validating the authenticity of data retrieved by another oracle.

[0355] The disclosed approach provides network monitoring data to Al systems for the use of validating the integrity of an MCP server. A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the disclosure. Accordingly, other implementations are within the scope of the following claims.

Claims

CLAIMS1. A system for monitoring network resources associated with a computer implemented services session on a network, comprising: a dependency discovery engine, configured to receive a uniform resource locator (URL) associated with a network service, and responsively perform steps of: identifying substantially all network requests and responses associated with the network service; associating with each identified network request any respective responses; performing network request filtering using a "content-type" header of respective network responses to identify thereby responses of types critical to functionality' and security of the computer implemented sendees session; and for each content type of responses of types critical to functionality and security, extracting response URLs from the respective identified responses to create thereby a set of dependency objects by content ty pe; at least one monitoring engine, configured to monitor relevant data associated with each of the set of dependency objects; and an alerting engine, configured to analysis monitor relevant data across multiple layers to identify thereby root causes of events and / or intermediate causes of events.

2. The system of claim 1, where the network resources being monitored and / or discovered are associated with a mobile application, application programming interface (API) call, or other mechanism configured to retrieve resources and / or data from the network.

3. The system of claim 1 or 2, where the computer implemented services session is instantiated at a web browser at a client device.

4. The system of claim 1 or 2, where the computer implemented services session is instantiated at an intermediate network node configured to monitor network traffic passing therethrough.

5. The system of claim 1 or 2, where the computer implemented services session is instantiated at an edge router associated with an enterprise network and configured to monitor network traffic passing therethrough.

6. The system of any one of claims 1-5. where the computer implemented services session is configured to provide network services and data to at least one blockchain oracle.

7. The system of any one of claims 1-6, where the alerting engine provides alerts designed for use in blockchain smart contracts.

8. The system of any one of claims 1-7, further comprising a graph construction engine, configured to process the set of dependency objects to generate thereby a structureddependency graph depicting relationships between at least some of the set of dependency objects and optionally including dependency object descriptions.

9. The system of claim 8, wherein the structured dependency graph represents a relationship between at least some of dependency objects discovered by the dependency discovery engine.

10. The system of claim 9, wherein the structured dependency graph represents the relationship between all dependencies discovered by the dependency discovery engine.

11. The system of any one of claims 8-10, further comprising a visualization engine, configured for visualizing the structured dependency graph and active alerts via an annotated, color coded, and icon-based view of the structured dependency graph with organizational structures designed to help operators clearly see what is going on.

12. The system of any one of claims 8-11. further comprising enterprise services applications, configured for: managing the discovering and identifying type of enterprise resources associated with network request and responses; the generating of a structured dependency graph depicting relationships between enterprise dependency objects and including enterprise dependency object descriptions; and the monitoring of relevant data associated with each of the enterprise object dependencies within the dependency graph.

13. The system of any one of claims 8-12, further comprising a commercial monitoring tool configured for: managing the discovering and identify ing type of at least a subset of resources associated with network request and responses; the generating of a structured dependency graph depicting relationships between the set of dependency objects and including dependency object descriptions, and the monitoring of relevant data associated with at least the set of dependency objects.

14. The system of claim 13, wherein the commercial monitoring tool is configured as a Software as a Service tool.

15. The system of any one of claims 1-14, wherein the dependency discover}’ engine configured to ignore those content types selected as not posing a significant security or availability risk.

16. The system of claim 15, wherein the content types include images and / or fonts.

17. The system of any one of claims 1-16, wherein the dependency discover}' engine is implemented via a web-browser automation framework.

18. The system of claim 17, wherein the web-browser automation framework comprises a Selenium framework instantiated within a browser program.

19. The system of any one of claims 1-16, wherein the dependency discover}' engine is implemented in response to user interaction with a web service in a browser being monitored by the dependency discover}' engine.

20. The system of any one of claims 1-19, wherein the dependency discover}7engine is further configured to package all dependency URLs and full-graph domain name system (DNS) lookups of domains in these URLs into a JSON dependency object that represents an attack surface for a target web service.

21. The system of any one of claims 1-20, wherein the at least one monitoring engine is further configured to raise alerts or record discrepancies that could lead to an alert based on monitored relevant data.

22. The system of any one of claims 1-21, wherein each of a plurality of monitoring engines is configured monitor a respective type of dependency object, each dependency object being monitored using one or more monitoring techniques associated with that type of dependency object.

23. The system of any one of claims 1-22, wherein each of a plurality of monitoring engines is located in a respective geographic region of the network.

24. The system of any one of claims 1-23, where the computer implemented services session is configured to provide network services and data to at least one Artificial Intelligence Agent system.

25. The system of any one of claims 1-24, where the at least one monitoring engine is further configured to track network infrastructure supporting at least one Artificial Intelligence (Al) system and monitor infrastructure dependencies of the at least one Al system.

26. A computer implemented method for monitoring network resources associated with a web browser session on a network, comprising: receiving a uniform resource locator (URL) associated with a network service, and iteratively performing the following steps until substantially all network resources associated with the network service have been processed: identifying substantially all network requests and responses associated with the network service; associating with each identified network request any respective responses; performing network request filtering using a "content-type" header of respective network responses to identify thereby responses of types critical to functionality and security of the web browser session; andfor each response critical content type, extracting response URLs from the respective identified responses of types critical to functional and security to create thereby a set of dependency objects by content type; monitoring relevant data associated with each of the set of dependency objects; and analyzing monitored relevant data across multiple layers to identify thereby root causes of events and / or intermediate causes of events.

27. The computer implemented method of claim 26, further comprising processing the set of dependency objects to generate thereby a structured dependency graph depicting relationships between the set of dependency objects and dependency object descriptions for monitoring.

28. The computer implemented method of claim 27, wherein the structured dependency graph represents a relationship between at least some dependencies discovered by a dependency discover}' engine.

29. The computer implemented method of claim 28, wherein the structured dependency graph represents the relationship between all dependencies discovered by the dependency discoveryengine.

30. The computer implemented method of claim any one of claims 27-29, further comprising visualizing the structured dependency graph and active alerts via an annotated, color coded, and icon-based view of the dependency graph with organizational structures designed to help operators clearly see what is going on.

31. The computer implemented method of any one of claims 27-30, wherein the method is implemented one or more enterprise services applications configured for: managing the discovering and identifying ty pe of enterprise resources associated with network request and responses; the generating of a structured dependency graph depicting relationships between enterprise dependency objects and including enterprise dependency object descriptions; and the monitoring of relevant data associated with each of the enterprise object dependencies within the dependency graph.

32. The computer implemented method of any one of claims 27-30, wherein the method is implemented as a commercial monitoring tool configured for: managing the discovering and identify ing ty pe of at least a subset of resources associated with network request and responses; the generating of a structured dependency graph depicting relationships between the set of dependency objects and including dependency- object descriptions; and the monitoring of relevant data associated with at least the set of dependency objects.

33. The computer implemented method of any one of claims 26-32, wherein said identifying is configured to ignore those content types selected as not posing a significant security or availability risk.

34. The computer implemented method of claim 33, wherein the content types include images and / or fonts.

35. The computer implemented method of any one of claims 26-34, wherein the method is implemented via a web-browser automation framework.

36. The computer implemented method of claim 35, wherein the web-browser automation framework comprises a Selenium framework instantiated within a browser program.

37. The computer implemented method of any one of claims 26-36, wherein the method is implemented in response to user interaction with a web service in a browser being monitored by a dependency discovery engine.

38. The computer implemented method of any one of claims 26-37, further comprising packaging all dependency URLs and full-graph DNS lookups of the domains in these URLs into a JavsScript Object Notation (JSON) dependency object that represents an attack surface for a target web service.

39. The computer implemented method of any one of claims 26-38, further comprising raising alerts or record discrepancies that could lead to an alert based on monitored relevant data.

40. The computer implemented method of any one of claims 26-39, wherein each of a plurality of monitoring engines is configured monitor a respective type of dependency object, each dependency object being monitored using one or more monitoring techniques associated with that type of dependency object.

41. The computer implemented method of claim 40, wherein each of the plurality of monitoring engines is located in a respective geographic region of the network.

42. A computer implemented method for discovering within a network one or more Domain Name System (DNS) servers associated with a network resource identified by a uniform resource locator (URL), the computer implemented method comprising recursively resolving and querying names of nameservers associated with a domain name system (DNS) resolution of the network resource identified by a uniform resource locator (URL) to determine thereby all dependency URLs and full -graph DNS lookups of domains in these URLs.

43. A computer implemented method for discovering within a network one or more Domain Name System (DNS) servers associated with a network resource identified by a uniform resource locator (URL), the computer implemented method comprising recursively resolving and querying names of nameservers associated with a domain name system (DNS) resolutionof the network resource identified by a uniform resource locator (URL) to determine thereby nameservers responsible for resolving the names of nameservers that are associated with a DNS resolution, any multiple levels of the resolved nameservers, and nameserver resolution along canonical name (CNAME)Zdelegation name (DNAME) chains.

Images