Integrated Dashboard for Real-time Security Monitoring and Incident Response

Integrated Dashboard for Real-time Security Monitoring and Incident Response | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Research Article Integrated Dashboard for Real-time Security Monitoring and Incident Response Rohitha Yamaganti, Varakala Pranay Goud, Panda Bishwanath Kumar, and 1 more This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-6270470/v1 This work is licensed under a CC BY 4.0 License Status: Under Review Version 1 posted 8 You are reading this latest preprint version Abstract In a fully managed serverless environment, the cloud service provider is responsible for securing the cloud infrastructure, considerably decreasing application developers' operational and maintenance workloads. However, such environments limit the use of traditional cybersecurity tools and frameworks, reducing observability and situational awareness (for example, risk assessment and incident management). Furthermore, existing security frameworks designed for serverless applications frequently lack universal adaptability to different application architectures and require customization, expert skills, and other adaptations for implementation in fully managed serverless environments. This article describes a three-tiered security system developed primarily for applications deployed in fully controlled serverless environments. The first two tiers use an innovative ontology developed entirely from serverless logs to turn them into a unified application activity knowledge graph. The third tier tackles the critical need for observability and situational awareness by adding two graph-based tools: An incident response interface that uses ontologies to visualize and analyse application activity records in connection to cybersecurity warnings. User research found that this tool allowed users to respond to new security alarms more quickly and accurately than a baseline tool. A paradigm for evaluating the criticality of assets (CoA) that enables specialists to prioritize cybersecurity scenarios effectively. Cloud Cloud Computing Security Cloud forensics Monitoring Figures Figure 1 Figure 2 Figure 3 Figure 4 1 INTRODUCTION Serverless computing in cloud environments[1] has grown rapidly, providing advantages such as reduced operational tasks, seamless scalability, and cost-effective pay-as-you-go pricing. This architecture is great for streaming, synchronization, batch processing, and APIs because it breaks applications down into stateless functional units handled by cloud service providers (CSPs). However, serverless systems have a shared security responsibility model, with CSPs controlling infrastructure security and developers protecting application data and functionality, posing unique cybersecurity problems. Key findings from the Cloud Security Alliance and Netwrix surveys indicate the monitoring problems in serverless applications: 1. High-granularity CSP logs hinder detecting application-layer threats (e.g., SQL injections, brute-force attacks).Diverse triggering mechanisms obscure root cause analysis. 2. Limited integration with traditional cybersecurity tools complicates attack surface evaluation. 3. A lack of specialized expertise in securing serverless environments impairs incident response. 4. Conventional security solutions are insufficient for serverless ecosystems, often requiring technical adjustments and introducing performance overhead. To address these gaps, robust cybersecurity situational awareness (CSA) capabilities are crucial, enabling real-time monitoring, risk assessment, and incident response via audit log analysis. This paper introduces the Perimeterless stack, a zero-trust security framework designed specifically for fully managed serverless settings. It presents a unique ontology that converts serverless application logs into a single activity knowledge graph, laying the groundwork for a three-layer security scheme: · Ontology creation and log transformation. · Graph-based log utilization. · Advanced CSA tools: ─ Incident Response (IR) Dashboard: Enhances log analysis and accelerates incident response using graph-based visualization. ─ Criticality of Asset (CoA) Risk Framework: Facilitates expert-driven prioritization of assets for optimized resource management. The Perimeterless stack offers two key advantages: it operates independently of application code, relying solely on API logs, and imposes zero operational overhead. A proof of concept using AWS serverless[3] logs demonstrated its effectiveness, with simulated scenarios showing an 18% improvement in mean time to detect (MTTD) incidents and a strong Kendall-W agreement score of 0.71 for the CoA framework. 1.1 Key Contributions: · Introduction of a graph-based IR dashboard that utilizes the Perimeterless stack for enhanced serverless application visualization, improving CSA tasks like incident response. · Development of the CoA risk assessment framework, which improves application observability and facilitates asset prioritization. · Demonstration of the Perimeterless stack’s flexibility in enabling various CSA tools, including the IR dashboard and CoA framework. · Creation of a novel AWS serverless application log dataset, to be made publicly available on GitHub following the paper’s publication. 2 BACKGROUND 2.1 Serverless Environment Serverless computing[4] refers to a suite of services that allow developers to create applications without handling the underlying infrastructure. The primary categories include: · Serverless Functions: These are fully managed computing services (e.g., AWS Lambda) that automatically scale and eliminate the need for developers to oversee server infrastructure. · Serverless Storage Solutions: These scalable storage services (e.g., Amazon S3, Azure Blob Storage) offer high reliability and availability without requiring the management of physical storage systems. · Application Integration Tools: These services (e.g., AWS Step Functions, Azure Logic Apps) facilitate the orchestration of workflows and enable seamless interactions between serverless application components. · Identity and Access Management (IAM): These frameworks define and enforce permissions and access controls within serverless environments, ensuring secure use of resources. 2.2 Audit Log Analysis in Serverless Systems In serverless environments like AWS, automated log auditing is crucial for monitoring and transparency. This study focused on AWS due to its prominence as a leading cloud service provider. A testbed application was developed using AWS CloudTrail to track API activities, enabling operational and activity auditing. Key AWS services analysed include: · Lambda: AWS’s serverless function service[2] generates three types of logs: ─ Function and Extension Logs: Created by developers through configuration. ─ Platform Logs: Automatically capture runtime details like execution time, memory usage, and data transfer. · Storage: Logging is enabled for services like Amazon S3 (object storage) and DynamoDB (NoSQL database), ensuring complete access records for users and resources. · CloudTrail captures logs for API activity in integration components supporting event-driven triggers, such as: · Event Bridge: Triggers operations like invoking Lambda functions based on scheduled events. · API Gateway: Manages RESTful APIs, ensuring seamless interaction between components. · Step Functions: Automates workflows by coordinating microservices and AWS tools. API request logs include key fields such as event Source (service type), event Name (API operation), resources (AWS resource), and user Identity (action credentials). This comprehensive logging approach enhances auditing and monitoring capabilities in serverless applications. 2.3 Security Threats in Cloud-Based Applications 2.3.1 Denial-of-Wallet (Dow) Attack Akin to denial-of-service (DoS) attacks, denial-of-wallet attacks disrupt application availability by exploiting the pay-as-you-go model in serverless environments. These attacks aim to exhaust a user’s financial resources through excessive API calls, effectively draining their budget. This attack type has been identified as a critical concern by organizations specializing in application and cybersecurity, emphasizing the importance of robust preventative measures. 2.3.2 Data Leakage Data leaking refers to the unintended disclosure of sensitive information, such as proprietary data, financial records, or personal health information, to unauthorized parties. According to recent cloud security surveys, a significant percentage of firms have experienced sensitive data breaches. These attacks pose serious threats to firms, causing both immediate operational interruptions and long-term reputational damage. In data leakage scenarios, attackers obtain access to sensitive information by exploiting cloud-based vulnerabilities. This could include exploiting misconfigured serverless storage solutions or employing more complex tactics to penetrate several layers of security. High-profile cases in recent years have highlighted the perils of data leakage, particularly those utilizing inadequately secured cloud storage options such as misconfigured S3 buckets. 3 PROTOTYPE APPLICATION This section introduces the Airline Reservation serverless application, which is deployed on AWS and serves as a prototype for evaluating the Perimeterless stack. The application is built on AWS serverless[5] services such as DynamoDB, S3, SQS, SNS, AppSync, and Lambda functions. AWS CloudTrail is used to monitor and log API activities. The program has two primary workflows: the Catalon and Loyalty workflows, which use short-lived functions to fetch data from DynamoDB, and the Booking workflow, which handles aircraft reservations and dynamic user activities like seat selection and booking modification. To evaluate the Perimeterless stack, we created a cloud-based prototype that ran the serverless application in a controlled environment. We used Python scripts to replicate both regular and malicious behaviour, as well as usual user interactions, faults, and attack scenarios. The simulations were logged through AWS CloudTrail, with Lambda function invocations and API data access logs collected. Two attack scenarios were simulated: DoW Attack: We modified the Lambda function for flight reservations to generate excessive fake API requests to a DynamoDB table, depleting the user’s budget. Data Leakage: We altered the Lambda function for booking confirmations to send sensitive data to a public S3 bucket instead of private storage. 4 PERIMETERLESS STACK This section introduces the Perimeterless framework, designed to enhance cybersecurity situational awareness in serverless[6] environments. The method starts by logging activities from a Cloud Service Provider (CSP) like AWS using native auditing tools (e.g., AWS CloudTrail), converting the logs into structured formats like CSV. The framework consists of multiple layers: · Serverless Ontology Layer: Defines key entities and relationships within serverless applications · CSP Activity Knowledge Graph: Tailors the general serverless ontology to a specific CSP (e.g., AWS) based on collected logs · AWS Application Activity Knowledge Graph: Applies the CSP-specific ontology to application logs, generating triplets that capture relationships, stored in a Neo4j graph database for efficient querying. The Situational Awareness Layer leverages this knowledge graph for two key CSA functionalities: · Incident Response (IR) Dashboard: A custom dashboard, built with Dash and integrated with Neo4j, for effective exploration and investigation of application activity. · Criticality of Asset (CoA) Framework: Assigns criticality scores to resources, enhancing the graph with contextual information for better prioritization and decision-making. 4.1 Serverless Architecture Ontology Explicit activities and implicit contextual items are found in application logs, and components such as compute, storage, and resources are mapped along with roles and permissions to create a serverless ontology. Interactions and permissions are recorded in logs. Owlready2 was used to generate the Perimeterless ontology, and Protege was used to visualize it (Figure 5). It uses dashed lines for implicit associations and solid blue lines to show inheritance when mapping basic serverless[7] things (Gray) to AWS-specific entities (orange). The storage class, for instance, provides read/write access and inherits ownership. · Ontology Entities ─ IAM Entities: o User: Root account or owner. o Role: Permissions for tasks. o I AM User: Identity switching roles. o Policy: Defines permissions (e.g., Put Object for storage). · Categories: ─ Application Integration: Logic services like SNS. ─ CSP Internal: Insufficient logs. ─ CSP Service: Unmapped log formats. · Serverless Resource Categories: ─ Compute: Lambda functions. ─ Storage: S3, DynamoDB. ─ Application Integration: Workflow services. · Relationships ─ Explicit: Direct event-based interactions (e.g., Lambda invoking PutItem on DynamoDB). ─ Implicit: Contextual relationships like IAM role usage. Key relationships include: o has subclass: Inheritance. o has assumed: Roles for access. o has invoke: Function invocations. o has owner: Resource ownership. Example · Logs map actions into a graph structure, e.g., a step function triggers a Lambda using IAM roles, or Lambda writes to DynamoDB by assuming a role. · This ontology supports parsing semi-structured logs into an activity knowledge graph, enabling comprehensive analysis of serverless application behaviour. 4.2 Activity Log Knowledge Framework The Perimeterless pipeline used to create the application activity knowledge graph (KG) is described in this section. The pipeline, which is used to build the activity KG, is made up of eight separate modules (A–H), as shown in Figure 7. Two essential tasks are carried out by the ontology (1) the construction and maintenance of a CSP-specific ontology, and (2) the knowledge graph. 4.2.1 CSP-Specific Ontology Development . As the Perimeterless ontology abstracts serverless services, its application to new CSP activity logs requires continuous updates. This process involves: (A) reviewing new log formats to enhance the ontology with newly discovered or updated service entities and relationships. Once the ontology is modified, the parsing process must also be updated within the mapping (D) and update procedure modules (E). 4.2.2 Knowledge Graph Development To begin, data from each log source is imported (A) and converted into a graph-based format (D). This process translates the logs into triplets (e.g., my-function, Get Object, my-bucket) that are stored (E) in the activity KG database (G). Each event relationship in the logs is captured as an explicit event relationship and includes pertinent attributes (such as date, user agent, error message, and region). To demonstrate this methodology within the AWS environment, we extended the generic serverless ontology (from the first layer of the Perimeterless stack) using logs from the Airline Booking application, applying the Perimeterless pipeline (Figure 7). Below is a step-by-step breakdown of the mapping process for the Put Item event, · Extract the event name from the event Name field. · Identify the source entity using the user Agent field, which provides insights into the function environment, helping identify the serverless function. · Determine the target resource by referencing the event Source field, which indicates the originating service type. · Derive the IAM entity and role name (if applicable) from the user Identity type and user Identity. Principal Id fields, respectively. · Retrieve the storage name of the target source (such as a DynamoDB table or S3 bucket) from the request Parameters. Table Name or request Parameters. bucket Name fields, accordingly. 4.3 Incident Management Dashboard Developers and security teams can efficiently engage with the application activity graph using the dashboard (H in Figure 7). The main Perimeterless dashboard interface is displayed in Figure 1. Logs are limited to a time window (A) that can be customized by the user. Icons are used to represent different resource kinds (nodes), and the background colours of these icons indicate the level of confidentiality risk (for example, C.1, an AWS Lambda function, is green, signifying low criticality). A distinct API request ID can be used by users to filter (B, C.2). By choosing a node, comprehensive resource details (such as name, type, and criticality) become visible. Edges are used to symbolize events, and their thickness indicates how frequently they occur within the time frame. Based on chosen nodes and time, the dashboard displays event type distribution (C.3) and raw event logs (D). Key features: · A graphical view of application activity for system-wide understanding. · Time window and resource filtering for focused analysis. · Resource search and relationship query functionalities. · Raw log presentation for granular details. · Activity knowledge graph (KG) for advanced querying. · Event distribution visualization by time and resources. · Enrichment modules (e.g., asset criticality rankings) for enhanced data context. · Report generation, capturing graph configurations and logs for documentation. 4.4 Asset Criticality and Risk Evaluation In serverless systems, assets like Lambda functions and storage services collaborate in an application flow. Asset prioritization (CoA) during cyberattacks helps cybersecurity teams analyse incidents and form targeted defence strategies. CoA ranking considers factors such as: · Role in Application Flow: Assets with more dependencies (e.g., an S3 bucket accessed by multiple functions) are higher-risk. · Data Sensitivity: Assets with sensitive data (e.g., credit card details) are more critical. · Dynamic Activity: Higher weight is assigned to critical operations (e.g., database updates) compared to less essential tasks. By establishing a two-tier hierarchy business process and asset type levels—the Analytic Hierarchy Process (AHP), which is used in the suggested CoA framework, streamlines prioritization. By lowering the quantity of pairwise comparisons, AHP improves process efficiency. A consistency ratio (CR) is used to verify internal consistency, and Kendall's W test is used to evaluate expert external agreement (values > 0.6 imply strong agreement). The final scores are then calculated by averaging the hierarchical rankings for the CIA triad (confidentiality, integrity, and availability) elements. In order to improve serverless application security, this methodology makes sure resources are ordered efficiently. Table 1 . Rank Calculation Example Business Level B1 (0.7) B2 (0.15) B3 (0.15) Resource Type C1 (0.1) C2 (0.1) C3 (0.1) Resource L1 (0.6) L2 (0.2) L3 (0.2) Rank 0.252 0.084 0.084 5 INCIDENT MANAGEMENT DASHBOARD USER EVALUATION To assess the usefulness of the Perimeterless dashboard, we carried out a user study with 39 participants (28 male and 11 female computer engineering students, including 25 B.Sc. and 14 M.Sc. students). On a scale of 1 to 5, the participants' average score was less than 2.6, indicating a lack of prior understanding in serverless computing, cloud computing, and cybersecurity log analysis. This made it easier to show how accessible the dashboard is to regular users. The Institutional Review Board (IRB) gave the study its approval. After completing an expertise questionnaire, participants received training on the experimental protocol, Perimeterless dashboard, and baseline tools. Participants' accuracy and time spent on incident response (IR) tasks, like log filtration and event context recognition, were measured as part of the evaluation. 5.1 Research Methodology An introduction to serverless environments, services, API audit logs, and a serverless application (Airline Booking) with cybersecurity incidents was given to participants for 25 minutes. A 15-minute practical training session utilizing the Perimeterless dashboard or a baseline tool (Microsoft Excel and Amazon CloudWatch) came next. Participants in the user study completed five activities in 80 minutes in two simulated IR scenarios: Data Leakage and Denial of Wallet (DoW). Each assignment was preceded by a briefing screen that displayed the goals and information. Data Leakage Scenario Identifying the alert event and associated resources. Counting resources interacting during two time windows. Identifying the accessed storage resource. DoW Attack Scenario Identifying the suspicious function and its interactions. Analyzing interaction volume over three time periods to confirm a DoW attack. Comparison to Baseline Tool Amazon CloudWatch and Microsoft Excel were used as the baseline tools. Excel's filtering, aggregation, and visualization features have been validated for cybersecurity tasks, making it a reliable comparison. 5.2 Comparison with Existing Systems Table 2 Comparison with Existing Systems vs Previous Systems Aspect Previous System Proposed System Key Changes Responsibility Cloud Provider Developer-driven Security Framework Developer-driven approach Constraints Limited use of conventional tools; lack of observability Overcomes constraints with ontology-based knowledge graph and situational awareness tools Enhanced observability and awareness Flexibility/Adaptability Non-adaptable frameworks requiring customization and advanced skills Universally adaptable ontology-based framework with minimal customization Adaptable to diverse architectures Observability Tools Fragmented tools; poor log utilization Unified tools for incident response and risk evaluation leveraging a knowledge graph Visual and analytical insights for logs and alerts Efficiency Slower and less accurate incident responses; no risk prioritization framework Faster, more accurate responses; risk prioritization with CoA framework Improved speed, accuracy, and decision-making 5.3 Metrics MTTD (Hours) : Time to detect an incident. MTTR (Hours) : Time to respond post-detection. Incident Resolution Time (Hours) : Total time to resolve an incident. False Positive Rate (%) : Alerts flagged incorrectly as threats. Threat Classification Accuracy (%) : Correctly classified threats. Anomaly Detection Rate (%) : Actual anomalies detected. 6 RESULTS Mean Time to Detect (MTTD) and task accuracy were two key performance measures (KPIs) in which study participants who used the Perimeterless dashboard performed better than those who used the baseline tool. On average, participants who used the baseline took 81.5 minutes to complete activities, whereas those who used the Perimeterless dashboard took 44.3 minutes. The time needed to create pivot tables in Excel, particularly for people with little experience, was the primary cause of this discrepancy. Even with the instruction, participants noted that making pivot tables in Excel was difficult and time-consuming. With the exception of job 2, where the baseline tool had a little advantage in accuracy (0.008%), the dashboard performed quite well. The dashboard's accuracy increased by up to 18.5% for all other tasks. Additionally, the Perimeterless dashboard decreased MTTD for every job. with the largest reduction of 20 minutes observed in task 2. Overall, the average accuracy was higher with the dashboard (0.873) compared to the baseline tool (0.772). 7 ILLUSTRATION OF THE ASSET CRITICALITY RANKING SYSTEM In this section, we illustrate the application of the asset criticality framework to an application, enabling the generation of a confidentiality risk score for each resource. 7.1 Analytical Hierarchy Process Development As shown in Figure we determined the AHP levels in the manner described below: 1. We divided the Airline Booking application into its primary business processes, which are flight booking, loyalty credit administration, and back-office activities, at the first level of the hierarchy, the business process level. These procedures were found in the application's documentation 1. Using the Perimeterless ontology, we classified the Airline Booking application's resources into distinct groups for every business process at the second level, or resource type level. 7.2 Specialist Assessment Survey We created a paired comparison questionnaire based on the AHP hierarchy. The questionnaire was filled out by six professionals who had used, simulated, and examined the program. The experts' comparisons were framed by the application's data confidentiality. The questionnaire's structure was decided upon. The Kendall-W statistic, which was used to assess the experts' agreement, produced a score of 0.7179, indicating a high degree of consensus. The most important resource is given a score of one at the beginning of the ranking process. All of the experts in our analysis agreed that the back office process was the most important. The booking procedure was given the lowest ranking and was considered the least important, while the loyalty process came in second. 7.3 Ranking Results We created a pairwise comparison survey using the AHP hierarchy. Six specialists filled out the questionnaire after implementing, simulating, and analysing the application. The background for the experts' comparisons was the application's data confidentiality. The Kendall-W statistic was used to assess the experts' agreement, and the result showed a high degree of consensus with a value of 0.7179. A score of one is given to the most important resource at the beginning of the ranking process. According to our investigation, every expert agreed that the back office process was the most important. The booking procedure was rated as the least important and was given the lowest score, while the loyalty process came in second. 8 ANALYSIS With the help of integrated logging tools like AWS CloudTrail, our proposed Perimeterless framework offers a straightforward way to improve cybersecurity in serverless systems while providing comprehensive monitoring with little extra labor. The Perimeterless framework's versatility comes from its ability to work with existing logs, guaranteeing a seamless integration into existing workflows without sacrificing system efficiency. The constant upkeep needed to update the ontology and mapping procedures to account for modifications in log formats and the addition of new log data sources, however, is a significant obstacle. The deployment of the Perimeterless architecture should include an organized maintenance strategy in order to handle this. The mapping process will need to be changed in order to include other cloud service providers (CSPs), such Azure Similar to the upkeep of CloudTrail mappings, this modification entails updating the Perimeterless pipeline (which is controlled by the pipeline maintainer, as shown in Fig. 4 ). This keeps the Perimeterless framework working across various logging platforms without causing performance issues for the application. Instead of expanding the framework's ontology and pipeline to support various CSPs, one may convert each data source into AWS's log format (for instance, transforming Azure Log Analytics logs into CloudTrail logs). 9 SUMMARY AND FUTURE DIRECTIONS The Perimeterless stack, a three-tier security framework created to address the unique cybersecurity issues in fully managed serverless systems, was introduced in this paper. A generic cloud service provider (CSP) activity knowledge graph and a universal serverless ontology make up the system. By creating two situational awareness tools—an incident reaction dashboard and a criticality of assets risk evaluation framework—the third layer overcomes the constraints of restricted vision and situational awareness. Our comprehensive analysis demonstrated the Perimeterless stack's efficacy. Notably, the IR dashboard reduced Mean Time to Detect (MTTD) by 18%, and the suggested dashboard's average job accuracy (0.873) was higher than that of the baseline tool (0.772). The CoA risk assessment framework, focused on confidentiality, achieved a strong Kendall-W score of 0.71 for resource prioritization. The Perimeterless stack provides a flexible and scalable framework for developing new cybersecurity technologies. Because it allows them to modify the stack to meet particular needs and requirements, it is especially helpful for security teams who do not have direct access to application code or environments. Expanding situational awareness features, automating log unification across various CSPs, and examining the possibilities of graph-based models for proactive threat hunting in managed serverless systems are the main areas of future research. Declarations Conflict of Interest : The authors declare that there is no conflict of interest regarding the publication of this paper. Author Contribution R.Y. supervised the project, provided guidance, and reviewed the manuscript.V.P.G. and P.B.K. contributed to the methodology, implementation, and writing of the main manuscript text.M.P.K.R. was responsible for data collection, analysis, and preparation of figures and tables. Data Availability : The data used in this study are available from the corresponding author upon reasonable request. References Parast, F.K., Sindhav, C., Nikam, S., Yekta, H.I., Kent, K.B., Hakak, S., "Cloud computing security: A survey of service-based models," Computers & Security , vol. 114, pp. 102580, 2022. Leitner, P., Wittern, E., Spillner, J., Hummer, W., "A mixed-method empirical study of function-as-a-service software development in industrial practice," Journal of Systems and Software , vol. 149, pp. 340–359, 2019. Eismann, S., Scheuner, J., Van Eyk, E., Schwinger, M., Grohmann, J., Herbst, N., Abad, C.L., Iosup, A., "The state of serverless applications: Collection, characterization, and community consensus," IEEE Transactions on Software Engineering , vol. 48, no. 10, pp. 4152–4166, 2021. Castro, P., Ishakian, V., Muthusamy, V., Slominski, A., "The rise of serverless computing," Communications of the ACM , vol. 62, no. 12, pp. 44–54, 2019. Shafiei, H., Khonsari, A., Mousavi, P., "Serverless computing: A survey of opportunities, challenges, and applications," ACM Computing Surveys , vol. 54, no. 11s, pp. 1–32, 2022. Marin, E., Perino, D., Di Pietro, R., "Serverless computing: A security perspective," Journal of Cloud Computing , vol. 11, no. 1, pp. 1–12, 2022. Li, X., Leng, X., Chen, Y., "Securing serverless computing: Challenges, solutions, and opportunities," IEEE Network , 2022. Additional Declarations No competing interests reported. Cite Share Download PDF Status: Under Review Version 1 posted Reviews received at journal 13 Oct, 2025 Reviewers agreed at journal 05 Oct, 2025 Reviewers agreed at journal 09 Jun, 2025 Reviewers agreed at journal 03 Jun, 2025 Reviewers invited by journal 03 Jun, 2025 Editor assigned by journal 21 Mar, 2025 Submission checks completed at journal 20 Mar, 2025 First submitted to journal 20 Mar, 2025 You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {"props":{"pageProps":{"initialData":{"identity":"rs-6270470","acceptedTermsAndConditions":true,"allowDirectSubmit":false,"archivedVersions":[],"articleType":"Research Article","associatedPublications":[],"authors":[{"id":434443168,"identity":"07acbda5-d8cf-4d38-b8ef-6694eca78ead","order_by":0,"name":"Rohitha Yamaganti","email":"","orcid":"","institution":"Sreenidhi Institution of Science and Technology","correspondingAuthor":false,"prefix":"","firstName":"Rohitha","middleName":"","lastName":"Yamaganti","suffix":""},{"id":434443169,"identity":"3e169a56-4700-43a0-8015-fe41a3d10e39","order_by":1,"name":"Varakala Pranay Goud","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAABHUlEQVRIiWNgGAWjYHADNgaGBww2cvwgdkIBsVoSGNKMJRtAWgyI13I4ccMBEAePFnPpw88e/Gw7LG/efizxQ0INM+Pm86sTPzwwYJDnFzuAVYtlX5q5YW/bYcM5Z9IOSyQcY2M2u/F2swTQYYYzZydg1WJwhsFMgrctjXEGQ3qDRAIbD5vZjbMbQFoSDG7j0sL+TfJvW5r9DP7nzT8S/knwGM84u/kHfi08ZtK8bTaJMyTSjkkkthlIGPD3bsNri2UPT5m0zDmb5BkSz9IsEvsSDCRu8G6zAFI4/WLOw75N8k2ZhO0M/jTjGx++/a/v7z+7+eaPCht5fmkcDgMRjGzIQhJglRJYlcO1MPxBFuI/gFP1KBgFo2AUjEwAABx2X6m2C24/AAAAAElFTkSuQmCC","orcid":"","institution":"Sreenidhi Institution of Science and Technology","correspondingAuthor":true,"prefix":"","firstName":"Varakala","middleName":"Pranay","lastName":"Goud","suffix":""},{"id":434443170,"identity":"c0ca731f-dabc-4e10-acac-b1cfd7efb2f4","order_by":2,"name":"Panda Bishwanath Kumar","email":"","orcid":"","institution":"Sreenidhi Institution of Science and Technology","correspondingAuthor":false,"prefix":"","firstName":"Panda","middleName":"Bishwanath","lastName":"Kumar","suffix":""},{"id":434443171,"identity":"42820da3-5b5b-4973-8e5a-75a9c6744be0","order_by":3,"name":"Mudugulla Pramod Kumar Reddy","email":"","orcid":"","institution":"Sreenidhi Institution of Science and Technology","correspondingAuthor":false,"prefix":"","firstName":"Mudugulla","middleName":"Pramod Kumar","lastName":"Reddy","suffix":""}],"badges":[],"createdAt":"2025-03-20 14:23:26","currentVersionCode":1,"declarations":"","doi":"10.21203/rs.3.rs-6270470/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-6270470/v1","draftVersion":[],"editorialEvents":[],"editorialNote":"","failedWorkflow":false,"files":[{"id":80360853,"identity":"12d61a68-c86a-456b-97a4-3f5bb49393f7","added_by":"auto","created_at":"2025-04-11 03:53:59","extension":"png","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":158193,"visible":true,"origin":"","legend":"\u003cp\u003ePerimeterless incident response dashboard\u003c/p\u003e","description":"","filename":"1.png","url":"https://assets-eu.researchsquare.com/files/rs-6270470/v1/e0491b6c9630e355137a25a7.png"},{"id":80360257,"identity":"5a43f021-4bb4-4e38-ab00-6eab865c1eda","added_by":"auto","created_at":"2025-04-11 03:45:58","extension":"png","order_by":2,"title":"Figure 2","display":"","copyAsset":false,"role":"figure","size":113065,"visible":true,"origin":"","legend":"\u003cp\u003ePerimeterless pipeline.\u003c/p\u003e","description":"","filename":"2.png","url":"https://assets-eu.researchsquare.com/files/rs-6270470/v1/66c857098b99581fbc5ead14.png"},{"id":80360264,"identity":"8f506a49-ad57-4de5-82b5-989a7e3466b3","added_by":"auto","created_at":"2025-04-11 03:45:59","extension":"png","order_by":3,"title":"Figure 3","display":"","copyAsset":false,"role":"figure","size":108767,"visible":true,"origin":"","legend":"\u003cp\u003eCriticality of assets: Airline Booking confidentiality ranking. On the x-axis, labels for processes are horizontal, and labels for resource names are vertical.\u003c/p\u003e","description":"","filename":"3.png","url":"https://assets-eu.researchsquare.com/files/rs-6270470/v1/0f9b6bc02846f543dfd2af41.png"},{"id":80360258,"identity":"bdc0832a-c91a-4895-a2a9-0224143fba23","added_by":"auto","created_at":"2025-04-11 03:45:59","extension":"png","order_by":4,"title":"Figure 4","display":"","copyAsset":false,"role":"figure","size":81443,"visible":true,"origin":"","legend":"\u003cp\u003eCoA framework - Airline Booking hierarchy\u003cstrong\u003e.\u003c/strong\u003e\u003c/p\u003e","description":"","filename":"4.png","url":"https://assets-eu.researchsquare.com/files/rs-6270470/v1/405a8560b3f15e123f564387.png"},{"id":80361780,"identity":"90c3994b-a386-4a50-b63c-86cb74eeaa3a","added_by":"auto","created_at":"2025-04-11 04:09:59","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":1015381,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-6270470/v1/e647e0a6-1646-46f5-bbe3-915abe41c7f5.pdf"}],"financialInterests":"No competing interests reported.","formattedTitle":"\u003cp\u003eIntegrated Dashboard for Real-time Security Monitoring and Incident Response\u003c/p\u003e","fulltext":[{"header":"1\tINTRODUCTION","content":"\u003cp\u003eServerless computing in cloud environments[1] has grown rapidly, providing advantages such as reduced operational tasks, seamless scalability, and cost-effective pay-as-you-go pricing. This architecture is great for streaming, synchronization, batch processing, and APIs because it breaks applications down into stateless functional units handled by cloud service providers (CSPs). However, serverless systems have a shared security responsibility model, with CSPs controlling infrastructure security and developers protecting application data and functionality, posing unique cybersecurity problems. Key findings from the Cloud Security Alliance and Netwrix surveys indicate the monitoring problems in serverless applications:\u003c/p\u003e\n\u003cp\u003e1. High-granularity CSP logs hinder detecting application-layer threats (e.g., SQL injections, brute-force attacks).Diverse triggering mechanisms obscure root cause analysis.\u003c/p\u003e\n\u003cp\u003e2. Limited integration with traditional cybersecurity tools complicates attack surface evaluation.\u003c/p\u003e\n\u003cp\u003e3. A lack of specialized expertise in securing serverless environments impairs incident response.\u003c/p\u003e\n\u003cp\u003e4. Conventional security solutions are insufficient for serverless ecosystems, often requiring technical adjustments and introducing performance overhead. To address these gaps, robust cybersecurity situational awareness (CSA) capabilities are crucial, enabling real-time monitoring, risk assessment, and incident response via audit log analysis.\u003c/p\u003e\n\u003cp\u003eThis paper introduces the Perimeterless stack, a zero-trust security framework designed specifically for fully managed serverless settings. It presents a unique ontology that converts serverless application logs into a single activity knowledge graph, laying the groundwork for a three-layer security scheme:\u003c/p\u003e\n\u003cp\u003e\u0026middot; Ontology creation and log transformation.\u003c/p\u003e\n\u003cp\u003e\u0026middot; Graph-based log utilization.\u003c/p\u003e\n\u003cp\u003e\u0026middot; Advanced CSA tools:\u003c/p\u003e\n\u003cp\u003e─ Incident Response (IR) Dashboard: Enhances log analysis and accelerates incident response using graph-based visualization.\u003c/p\u003e\n\u003cp\u003e─ Criticality of Asset (CoA) Risk Framework: Facilitates expert-driven prioritization of assets for optimized resource management.\u003c/p\u003e\n\u003cp\u003eThe Perimeterless stack offers two key advantages: it operates independently of application code, relying solely on API logs, and imposes zero operational overhead. A proof of concept using AWS serverless[3] logs demonstrated its effectiveness, with simulated scenarios showing an 18% improvement in mean time to detect (MTTD) incidents and a strong Kendall-W agreement score of 0.71 for the CoA framework.\u003c/p\u003e\n\u003cp\u003e1.1 Key Contributions:\u003c/p\u003e\n\u003cp\u003e\u0026middot; Introduction of a graph-based IR dashboard that utilizes the Perimeterless stack for enhanced serverless application visualization, improving CSA tasks like incident response. \u003c/p\u003e\n\u003cp\u003e\u0026middot; Development of the CoA risk assessment framework, which improves application observability and facilitates asset prioritization. \u003c/p\u003e\n\u003cp\u003e\u0026middot; Demonstration of the Perimeterless stack\u0026rsquo;s flexibility in enabling various CSA tools, including the IR dashboard and CoA framework. \u003c/p\u003e\n\u003cp\u003e\u0026middot; Creation of a novel AWS serverless application log dataset, to be made publicly available on GitHub following the paper\u0026rsquo;s publication. \u003c/p\u003e"},{"header":"2 BACKGROUND","content":"\u003cp\u003e2.1\u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;Serverless Environment\u003c/p\u003e\n\u003cp\u003eServerless computing[4] refers to a suite of services that allow developers to create applications without handling the underlying infrastructure. The primary categories include:\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Serverless Functions: These are fully managed computing services (e.g., AWS Lambda) that automatically scale and eliminate the need for developers to oversee server infrastructure.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Serverless Storage Solutions: These scalable storage services (e.g., Amazon S3, Azure Blob Storage) offer high reliability and availability without requiring the management of physical storage systems.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Application Integration Tools: These services (e.g., AWS Step Functions, Azure Logic Apps) facilitate the orchestration of workflows and enable seamless interactions between serverless application components.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Identity and Access Management (IAM): These frameworks define and enforce permissions and access controls within serverless environments, ensuring secure use of resources.\u003c/p\u003e\n\u003cp\u003e2.2\u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;Audit Log Analysis in Serverless Systems\u003c/p\u003e\n\u003cp\u003eIn serverless environments like AWS, automated log auditing is crucial for monitoring and transparency. This study focused on AWS due to its prominence as a leading cloud service provider. A testbed application was developed using AWS CloudTrail to track API activities, enabling operational and activity auditing. Key AWS services analysed include:\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Lambda: AWS\u0026rsquo;s serverless function service[2] generates three types of logs:\u003c/p\u003e\n\u003cp\u003e─\u0026nbsp;\u0026nbsp;Function and Extension Logs: Created by developers through configuration.\u003c/p\u003e\n\u003cp\u003e─\u0026nbsp;\u0026nbsp;Platform Logs: Automatically capture runtime details like execution time, memory usage, and data transfer.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Storage: Logging is enabled for services like Amazon S3 (object storage) and DynamoDB (NoSQL database), ensuring complete access records for users and resources.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;CloudTrail captures logs for API activity in integration components supporting event-driven triggers, such as:\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Event Bridge: Triggers operations like invoking Lambda functions based on scheduled events.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;API Gateway: Manages RESTful APIs, ensuring seamless interaction between components.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Step Functions: Automates workflows by coordinating microservices and AWS tools.\u003c/p\u003e\n\u003cp\u003eAPI request logs include key fields such as event Source (service type), event Name (API operation), resources (AWS resource), and user Identity (action credentials). This comprehensive logging approach enhances auditing and monitoring capabilities in serverless applications.\u003c/p\u003e\n\u003cp\u003e2.3\u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;Security Threats in Cloud-Based Applications\u003c/p\u003e\n\u003ch3\u003e2.3.1 Denial-of-Wallet (Dow) Attack\u003c/h3\u003e\n\u003cp\u003e\u0026nbsp;Akin to denial-of-service (DoS) attacks, denial-of-wallet attacks disrupt application availability by exploiting the pay-as-you-go model in serverless environments. These attacks aim to exhaust a user\u0026rsquo;s financial resources through excessive API calls, effectively draining their budget. This attack type has been identified as a critical concern by organizations specializing in application and cybersecurity, emphasizing the importance of robust preventative measures.\u003c/p\u003e\n\u003ch3\u003e2.3.2 Data Leakage\u003c/h3\u003e\n\u003cp\u003eData leaking refers to the unintended disclosure of sensitive information, such as proprietary data, financial records, or personal health information, to unauthorized parties. According to recent cloud security surveys, a significant percentage of firms have experienced sensitive data breaches. These attacks pose serious threats to firms, causing both immediate operational interruptions and long-term reputational damage. \u0026nbsp;In data leakage scenarios, attackers obtain access to sensitive information by exploiting cloud-based vulnerabilities. This could include exploiting misconfigured serverless storage solutions or employing more complex tactics to penetrate several layers of security. High-profile cases in recent years have highlighted the perils of data leakage, particularly those utilizing inadequately secured cloud storage options such as misconfigured S3 buckets.\u003c/p\u003e"},{"header":"3 PROTOTYPE APPLICATION","content":"\u003cp\u003eThis section introduces the Airline Reservation serverless application, which is deployed on AWS and serves as a prototype for evaluating the Perimeterless stack. The application is built on AWS serverless[5] services such as DynamoDB, S3, SQS, SNS, AppSync, and Lambda functions. AWS CloudTrail is used to monitor and log API activities. The program has two primary workflows: the Catalon and Loyalty workflows, which use short-lived functions to fetch data from DynamoDB, and the Booking workflow, which handles aircraft reservations and dynamic user activities like seat selection and booking modification. To evaluate the Perimeterless stack, we created a cloud-based prototype that ran the serverless application in a controlled environment. We used Python scripts to replicate both regular and malicious behaviour, as well as usual user interactions, faults, and attack scenarios. The simulations were logged through AWS CloudTrail, with Lambda function invocations and API data access logs collected.\u003c/p\u003e \u003cp\u003eTwo attack scenarios were simulated:\u003c/p\u003e \u003cp\u003e \u003cul\u003e \u003cli\u003e \u003cp\u003eDoW Attack: We modified the Lambda function for flight reservations to generate excessive fake API requests to a DynamoDB table, depleting the user\u0026rsquo;s budget.\u003c/p\u003e \u003c/li\u003e \u003cli\u003e \u003cp\u003eData Leakage: We altered the Lambda function for booking confirmations to send sensitive data to a public S3 bucket instead of private storage.\u003c/p\u003e \u003c/li\u003e \u003c/ul\u003e \u003c/p\u003e"},{"header":"4 PERIMETERLESS STACK","content":"\u003cp\u003eThis section introduces the Perimeterless framework, designed to enhance cybersecurity situational awareness in serverless[6] environments. The method starts by logging activities from a Cloud Service Provider (CSP) like AWS using native auditing tools (e.g., AWS CloudTrail), converting the logs into structured formats like CSV.\u003c/p\u003e\n\u003cp\u003eThe framework consists of multiple layers:\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Serverless Ontology Layer: Defines key entities and relationships within serverless applications\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;CSP Activity Knowledge Graph: Tailors the general serverless ontology to a specific CSP (e.g., AWS) based on collected logs\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;AWS Application Activity Knowledge Graph: Applies the CSP-specific ontology to application logs, generating triplets that capture relationships, stored in a Neo4j graph database for efficient querying.\u003c/p\u003e\n\u003cp\u003eThe Situational Awareness Layer leverages this knowledge graph for two key CSA functionalities:\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Incident Response (IR) Dashboard: A custom dashboard, built with Dash and integrated with Neo4j, for effective exploration and investigation of application activity.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Criticality of Asset (CoA) Framework: Assigns criticality scores to resources, enhancing the graph with contextual information for better prioritization and decision-making.\u003c/p\u003e\n\u003cp\u003e4.1\u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;Serverless Architecture Ontology\u003c/p\u003e\n\u003cp\u003eExplicit activities and implicit contextual items are found in application logs, and components such as compute, storage, and resources are mapped along with roles and permissions to create a serverless ontology. Interactions and permissions are recorded in \u0026nbsp;logs. Owlready2 was used to generate the Perimeterless ontology, and Protege was used to visualize it (Figure 5). It uses dashed lines for implicit associations and solid blue lines to show inheritance when mapping basic serverless[7] things (Gray) to AWS-specific entities (orange). The storage class, for instance, provides read/write access and inherits ownership.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Ontology Entities\u003c/p\u003e\n\u003cp\u003e─\u0026nbsp;\u0026nbsp;IAM Entities:\u003c/p\u003e\n\u003cp\u003eo\u0026nbsp;User: Root account or owner.\u003c/p\u003e\n\u003cp\u003eo\u0026nbsp;Role: Permissions for tasks.\u003c/p\u003e\n\u003cp\u003eo\u0026nbsp;I AM User: Identity switching roles.\u003c/p\u003e\n\u003cp\u003eo\u0026nbsp;Policy: Defines permissions (e.g., Put Object for storage).\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Categories:\u003c/p\u003e\n\u003cp\u003e─\u0026nbsp;\u0026nbsp;Application Integration: Logic services like SNS.\u003c/p\u003e\n\u003cp\u003e─\u0026nbsp;\u0026nbsp;CSP Internal: Insufficient logs.\u003c/p\u003e\n\u003cp\u003e─\u0026nbsp;\u0026nbsp;CSP Service: Unmapped log formats.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Serverless Resource Categories:\u003c/p\u003e\n\u003cp\u003e─\u0026nbsp;\u0026nbsp;Compute: Lambda functions.\u003c/p\u003e\n\u003cp\u003e─\u0026nbsp;\u0026nbsp;Storage: S3, DynamoDB.\u003c/p\u003e\n\u003cp\u003e─\u0026nbsp;\u0026nbsp;Application Integration: Workflow services.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Relationships\u003c/p\u003e\n\u003cp\u003e─\u0026nbsp;\u0026nbsp;Explicit: Direct event-based interactions (e.g., Lambda invoking PutItem on DynamoDB).\u003c/p\u003e\n\u003cp\u003e─\u0026nbsp;\u0026nbsp;Implicit: Contextual relationships like IAM role usage. Key relationships include:\u003c/p\u003e\n\u003cp\u003eo\u0026nbsp;has subclass: Inheritance.\u003c/p\u003e\n\u003cp\u003eo\u0026nbsp;has assumed: Roles for access.\u003c/p\u003e\n\u003cp\u003eo\u0026nbsp;has invoke: Function invocations.\u003c/p\u003e\n\u003cp\u003eo\u0026nbsp;has owner: Resource ownership.\u003c/p\u003e\n\u003cp\u003eExample\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Logs map actions into a graph structure, e.g., a step function triggers a Lambda using IAM roles, or Lambda writes to DynamoDB by assuming a role.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;This ontology supports parsing semi-structured logs into an activity knowledge graph, enabling comprehensive analysis of serverless application behaviour.\u003c/p\u003e\n\u003cp\u003e4.2\u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;Activity Log Knowledge Framework\u003c/p\u003e\n\u003cp\u003eThe Perimeterless pipeline used to create the application activity knowledge graph (KG) is described in this section. The pipeline, which is used to build the activity KG, is made up of eight separate modules (A\u0026ndash;H), as shown in Figure 7. Two essential tasks are carried out by the ontology (1) the construction and maintenance of a CSP-specific ontology, and (2) the knowledge graph.\u003c/p\u003e\n\u003ch3\u003e4.2.1 CSP-Specific Ontology Development\u003c/h3\u003e\n\u003cp\u003e. As the Perimeterless ontology abstracts serverless services, its application to new CSP activity logs requires continuous updates. This process involves: (A) reviewing new log formats to enhance the ontology with newly discovered or updated service entities and relationships. Once the ontology is modified, the parsing process must also be updated within the mapping (D) and update procedure modules (E).\u003c/p\u003e\n\u003ch3\u003e4.2.2 Knowledge Graph Development\u003c/h3\u003e\n\u003cp\u003eTo begin, data from each log source is imported (A) and converted into a graph-based format (D). This process translates the logs into triplets (e.g., my-function, Get Object, my-bucket) that are stored (E) in the activity KG database (G). Each event relationship in the logs is captured as an explicit event relationship and includes pertinent attributes (such as date, user agent, error message, and region).\u003c/p\u003e\n\u003cp\u003eTo demonstrate this methodology within the AWS environment, we extended the generic serverless ontology (from the first layer of the Perimeterless stack) using logs from the Airline Booking application, applying the Perimeterless pipeline (Figure 7). Below is a step-by-step breakdown of the mapping process for the Put Item event,\u0026nbsp;\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Extract the event name from the event Name field.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Identify the source entity using the user Agent field, which provides insights into the function environment, helping identify the serverless function.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Determine the target resource by referencing the event Source field, which indicates the originating service type.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Derive the IAM entity and role name (if applicable) from the user Identity \u0026nbsp;type and user Identity. Principal Id fields, respectively.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Retrieve the storage name of the target source (such as a DynamoDB table or S3 bucket) from the request Parameters. Table Name or request Parameters. bucket Name fields, accordingly.\u003c/p\u003e\n\u003cp\u003e4.3\u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;Incident Management Dashboard\u003c/p\u003e\n\u003cp\u003eDevelopers and security teams can efficiently engage with the application activity graph using the dashboard (H in Figure 7). The main Perimeterless dashboard interface is displayed in Figure 1. Logs are limited to a time window (A) that can be customized by the user. Icons are used to represent different resource kinds (nodes), and the background colours of these icons indicate the level of confidentiality risk (for example, C.1, an AWS Lambda function, is green, signifying low criticality). A distinct API request ID can be used by users to filter (B, C.2). By choosing a node, comprehensive resource details (such as name, type, and criticality) become visible. Edges are used to symbolize events, and their thickness indicates how frequently they occur within the time frame. Based on chosen nodes and time, the dashboard displays event type distribution (C.3) and raw event logs (D).\u003c/p\u003e\n\u003ch4\u003eKey features:\u003c/h4\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;A graphical view of application activity for system-wide understanding.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Time window and resource filtering for focused analysis.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Resource search and relationship query functionalities.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Raw log presentation for granular details.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Activity knowledge graph (KG) for advanced querying.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Event distribution visualization by time and resources.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Enrichment modules (e.g., asset criticality rankings) for enhanced data context.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Report generation, capturing graph configurations and logs for documentation.\u003c/p\u003e\n\u003cp\u003e4.4\u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;Asset Criticality and Risk Evaluation\u003c/p\u003e\n\u003cp\u003eIn serverless systems, assets like Lambda functions and storage services collaborate in an application flow. Asset prioritization (CoA) during cyberattacks helps cybersecurity teams analyse incidents and form targeted defence strategies. CoA ranking considers factors such as:\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Role in Application Flow: Assets with more dependencies (e.g., an S3 bucket accessed by multiple functions) are higher-risk.\u003c/p\u003e\n\u003cp\u003e\u0026middot;\u0026nbsp; \u0026nbsp;Data Sensitivity: Assets with sensitive data (e.g., credit card details) are more critical.\u003c/p\u003e\n\u003cp\u003e\u0026middot; \u0026nbsp; Dynamic Activity: Higher weight is assigned to critical operations (e.g., database updates) compared to less essential tasks.\u003c/p\u003e\n\u003cp\u003eBy establishing a two-tier hierarchy business process and asset type levels\u0026mdash;the Analytic Hierarchy Process (AHP), which is used in the suggested CoA framework, streamlines prioritization. By lowering the quantity of pairwise comparisons, AHP improves process efficiency. A consistency ratio (CR) is used to verify internal consistency, and Kendall\u0026apos;s W test is used to evaluate expert external agreement (values \u0026gt; 0.6 imply strong agreement). The final scores are then calculated by averaging the hierarchical rankings for the CIA triad (confidentiality, integrity, and availability) elements. In order to improve serverless application security, this methodology makes sure resources are ordered efficiently.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTable\u0026nbsp;\u003c/strong\u003e\u003cstrong\u003e1\u003c/strong\u003e\u003cstrong\u003e.\u003c/strong\u003e Rank Calculation Example\u003c/p\u003e\n\u003cdiv align=\"Left\"\u003e\n \u003ctable border=\"0\" cellspacing=\"0\" cellpadding=\"0\" width=\"383\"\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd style=\"width: 29.2428%;\"\u003e\n \u003cp\u003e\u003cstrong\u003eBusiness Level\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd style=\"width: 24.0209%;\"\u003e\n \u003cp\u003e\u003cstrong\u003eB1 (0.7)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd style=\"width: 25.0653%;\"\u003e\n \u003cp\u003e\u003cstrong\u003eB2 (0.15)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd style=\"width: 21.671%;\"\u003e\n \u003cp\u003e\u003cstrong\u003eB3 (0.15)\u003c/strong\u003e\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd style=\"width: 29.2428%;\"\u003e\n \u003cp\u003eResource Type\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd style=\"width: 24.0209%;\"\u003e\n \u003cp\u003eC1 (0.1)\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd style=\"width: 25.0653%;\"\u003e\n \u003cp\u003eC2 (0.1)\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd style=\"width: 21.671%;\"\u003e\n \u003cp\u003eC3 (0.1)\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd style=\"width: 29.2428%;\"\u003e\n \u003cp\u003eResource\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd style=\"width: 24.0209%;\"\u003e\n \u003cp\u003eL1 (0.6)\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd style=\"width: 25.0653%;\"\u003e\n \u003cp\u003eL2 (0.2)\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd style=\"width: 21.671%;\"\u003e\n \u003cp\u003eL3 (0.2)\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd style=\"width: 29.2428%;\"\u003e\n \u003cp\u003eRank\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd style=\"width: 24.0209%;\"\u003e\n \u003cp\u003e0.252\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd style=\"width: 25.0653%;\"\u003e\n \u003cp\u003e0.084\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd style=\"width: 21.671%;\"\u003e\n \u003cp\u003e0.084\u0026nbsp;\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n \u003c/table\u003e\n\u003c/div\u003e"},{"header":"5 INCIDENT MANAGEMENT DASHBOARD USER EVALUATION","content":"\u003cp\u003eTo assess the usefulness of the Perimeterless dashboard, we carried out a user study with 39 participants (28 male and 11 female computer engineering students, including 25 B.Sc. and 14 M.Sc. students). On a scale of 1 to 5, the participants\u0026apos; average score was less than 2.6, indicating a lack of prior understanding in serverless computing, cloud computing, and cybersecurity log analysis. This made it easier to show how accessible the dashboard is to regular users.\u003c/p\u003e\n\u003cp\u003eThe Institutional Review Board (IRB) gave the study its approval. After completing an expertise questionnaire, participants received training on the experimental protocol, Perimeterless dashboard, and baseline tools. Participants\u0026apos; accuracy and time spent on incident response (IR) tasks, like log filtration and event context recognition, were measured as part of the evaluation.\u003c/p\u003e\n\u003cdiv id=\"Sec16\" class=\"Section2\"\u003e\n \u003ch2\u003e5.1 Research Methodology\u003c/h2\u003e\n \u003cp\u003eAn introduction to serverless environments, services, API audit logs, and a serverless application (Airline Booking) with cybersecurity incidents was given to participants for 25 minutes. A 15-minute practical training session utilizing the Perimeterless dashboard or a baseline tool (Microsoft Excel and Amazon CloudWatch) came next.\u003c/p\u003e\n \u003cp\u003eParticipants in the user study completed five activities in 80 minutes in two simulated IR scenarios: Data Leakage and Denial of Wallet (DoW). Each assignment was preceded by a briefing screen that displayed the goals and information.\u003c/p\u003e\n \u003cp\u003e\u003cem\u003eData Leakage Scenario\u003c/em\u003e\u003c/p\u003e\n \u003cul\u003e\n \u003cli\u003e\n \u003cp\u003eIdentifying the alert event and associated resources.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eCounting resources interacting during two time windows.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eIdentifying the accessed storage resource.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eDoW Attack Scenario\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eIdentifying the suspicious function and its interactions.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003eAnalyzing interaction volume over three time periods to confirm a DoW attack.\u003c/p\u003e\n \u003c/li\u003e\n \u003c/ul\u003e\n \u003cp\u003eComparison to Baseline Tool Amazon CloudWatch and Microsoft Excel were used as the baseline tools. Excel\u0026apos;s filtering, aggregation, and visualization features have been validated for cybersecurity tasks, making it a reliable comparison.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv id=\"Sec17\" class=\"Section2\"\u003e\n \u003ch2\u003e5.2 Comparison with Existing Systems\u003c/h2\u003e\n \u003cdiv class=\"gridtable\"\u003e\u0026nbsp;\u003ctable id=\"Tab2\" border=\"1\"\u003e\n \u003ccaption language=\"En\"\u003e\n \u003cdiv class=\"CaptionNumber\"\u003eTable 2\u003c/div\u003e\n \u003cdiv class=\"CaptionContent\"\u003e\n \u003cp\u003eComparison with Existing Systems vs Previous Systems\u003c/p\u003e\n \u003c/div\u003e\n \u003c/caption\u003e\n \u003cthead\u003e\n \u003ctr\u003e\n \u003cth align=\"left\"\u003e\n \u003cp\u003eAspect\u003c/p\u003e\n \u003c/th\u003e\n \u003cth align=\"left\"\u003e\n \u003cp\u003ePrevious System\u003c/p\u003e\n \u003c/th\u003e\n \u003cth align=\"left\"\u003e\n \u003cp\u003eProposed System\u003c/p\u003e\n \u003c/th\u003e\n \u003cth align=\"left\"\u003e\n \u003cp\u003eKey Changes\u003c/p\u003e\n \u003c/th\u003e\n \u003c/tr\u003e\n \u003c/thead\u003e\n \u003ctbody\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eResponsibility\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eCloud Provider\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eDeveloper-driven Security Framework\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eDeveloper-driven approach\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eConstraints\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eLimited use of conventional tools; lack of observability\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eOvercomes constraints with ontology-based knowledge graph and situational awareness tools\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eEnhanced observability and awareness\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eFlexibility/Adaptability\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eNon-adaptable frameworks requiring customization and advanced skills\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eUniversally adaptable ontology-based framework with minimal customization\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eAdaptable to diverse architectures\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eObservability Tools\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eFragmented tools; poor log utilization\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eUnified tools for incident response and risk evaluation leveraging a knowledge graph\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eVisual and analytical insights for logs and alerts\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003ctr\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eEfficiency\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eSlower and less accurate incident responses; no risk prioritization framework\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eFaster, more accurate responses; risk prioritization with CoA framework\u003c/p\u003e\n \u003c/td\u003e\n \u003ctd align=\"left\"\u003e\n \u003cp\u003eImproved speed, accuracy, and decision-making\u003c/p\u003e\n \u003c/td\u003e\n \u003c/tr\u003e\n \u003c/tbody\u003e\n \u003c/table\u003e\n \u003c/div\u003e\u003cspan\u003e\n \u003cp\u003e\u003cstrong\u003e5.3 Metrics\u003c/strong\u003e\u003c/p\u003e\n \u003c/span\u003e\n \u003cul\u003e\n \u003cli\u003e\n \u003cp\u003e\u003cstrong\u003eMTTD (Hours)\u003c/strong\u003e: Time to detect an incident.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003e\u003cstrong\u003eMTTR (Hours)\u003c/strong\u003e: Time to respond post-detection.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003e\u003cstrong\u003eIncident Resolution Time (Hours)\u003c/strong\u003e: Total time to resolve an incident.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003e\u003cstrong\u003eFalse Positive Rate (%)\u003c/strong\u003e: Alerts flagged incorrectly as threats.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003e\u003cstrong\u003eThreat Classification Accuracy (%)\u003c/strong\u003e: Correctly classified threats.\u003c/p\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003cp\u003e\u003cstrong\u003eAnomaly Detection Rate (%)\u003c/strong\u003e: Actual anomalies detected.\u003c/p\u003e\n \u003c/li\u003e\n \u003c/ul\u003e\n\u003c/div\u003e"},{"header":"6 RESULTS","content":"\u003cp\u003eMean Time to Detect (MTTD) and task accuracy were two key performance measures (KPIs) in which study participants who used the Perimeterless dashboard performed better than those who used the baseline tool. On average, participants who used the baseline took 81.5 minutes to complete activities, whereas those who used the Perimeterless dashboard took 44.3 minutes. The time needed to create pivot tables in Excel, particularly for people with little experience, was the primary cause of this discrepancy. Even with the instruction, participants noted that making pivot tables in Excel was difficult and time-consuming.\u003c/p\u003e \u003cp\u003eWith the exception of job 2, where the baseline tool had a little advantage in accuracy (0.008%), the dashboard performed quite well. The dashboard's accuracy increased by up to 18.5% for all other tasks. Additionally, the Perimeterless dashboard decreased MTTD for every job. with the largest reduction of 20 minutes observed in task 2. Overall, the average accuracy was higher with the dashboard (0.873) compared to the baseline tool (0.772).\u003c/p\u003e"},{"header":"7 ILLUSTRATION OF THE ASSET CRITICALITY RANKING SYSTEM","content":"\u003cp\u003eIn this section, we illustrate the application of the asset criticality framework to an application, enabling the generation of a confidentiality risk score for each resource.\u003c/p\u003e\n\u003cp\u003e7.1\u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;Analytical Hierarchy Process Development\u003c/p\u003e\n\u003cp\u003eAs shown in Figure we determined the AHP levels in the manner described below:\u003c/p\u003e\n\u003cp\u003e1.\u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;We divided the Airline Booking application into its primary business processes, which are flight booking, loyalty credit administration, and back-office activities, at the first level of the hierarchy, the business process level. These procedures were found in the application\u0026apos;s documentation\u003c/p\u003e\n\u003cp\u003e1.\u0026nbsp; \u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;Using the Perimeterless ontology, we classified the Airline Booking application\u0026apos;s resources into distinct groups for every business process at the second level, or resource type level.\u003c/p\u003e\n\u003cp\u003e7.2\u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;Specialist Assessment Survey\u003c/p\u003e\n\u003cp\u003eWe created a paired comparison questionnaire based on the AHP hierarchy. The questionnaire was filled out by six professionals who had used, simulated, and examined the program. The experts\u0026apos; comparisons were framed by the application\u0026apos;s data confidentiality. The questionnaire\u0026apos;s structure was decided upon. The Kendall-W statistic, which was used to assess the experts\u0026apos; agreement, produced a score of 0.7179, indicating a high degree of consensus. The most important resource is given a score of one at the beginning of the ranking process. All of the experts in our analysis agreed that the back office process was the most important. The booking procedure was given the lowest ranking and was considered the least important, while the loyalty process came in second.\u003c/p\u003e\n\u003cp\u003e7.3\u0026nbsp; \u0026nbsp; \u0026nbsp;\u0026nbsp;Ranking Results\u003c/p\u003e\n\u003cp\u003eWe created a pairwise comparison survey using the AHP hierarchy. Six specialists filled out the questionnaire after implementing, simulating, and analysing the application. The background for the experts\u0026apos; comparisons was the application\u0026apos;s data confidentiality. The Kendall-W statistic was used to assess the experts\u0026apos; agreement, and the result showed a high degree of consensus with a value of 0.7179. A score of one is given to the most important resource at the beginning of the ranking process. According to our investigation, every expert agreed that the back office process was the most important. The booking procedure was rated as the least important and was given the lowest score, while the loyalty process came in second.\u003c/p\u003e"},{"header":"8 ANALYSIS","content":"\u003cp\u003eWith the help of integrated logging tools like AWS CloudTrail, our proposed Perimeterless framework offers a straightforward way to improve cybersecurity in serverless systems while providing comprehensive monitoring with little extra labor. The Perimeterless framework's versatility comes from its ability to work with existing logs, guaranteeing a seamless integration into existing workflows without sacrificing system efficiency. The constant upkeep needed to update the ontology and mapping procedures to account for modifications in log formats and the addition of new log data sources, however, is a significant obstacle. The deployment of the Perimeterless architecture should include an organized maintenance strategy in order to handle this. The mapping process will need to be changed in order to include other cloud service providers (CSPs), such Azure Similar to the upkeep of CloudTrail mappings, this modification entails updating the Perimeterless pipeline (which is controlled by the pipeline maintainer, as shown in Fig.\u0026nbsp;\u003cspan refid=\"Fig4\" class=\"InternalRef\"\u003e4\u003c/span\u003e). This keeps the Perimeterless framework working across various logging platforms without causing performance issues for the application. Instead of expanding the framework's ontology and pipeline to support various CSPs, one may convert each data source into AWS's log format (for instance, transforming Azure Log Analytics logs into CloudTrail logs).\u003c/p\u003e"},{"header":"9 SUMMARY AND FUTURE DIRECTIONS","content":"\u003cp\u003eThe Perimeterless stack, a three-tier security framework created to address the unique cybersecurity issues in fully managed serverless systems, was introduced in this paper. A generic cloud service provider (CSP) activity knowledge graph and a universal serverless ontology make up the system. By creating two situational awareness tools\u0026mdash;an incident reaction dashboard and a criticality of assets risk evaluation framework\u0026mdash;the third layer overcomes the constraints of restricted vision and situational awareness. Our comprehensive analysis demonstrated the Perimeterless stack's efficacy. Notably, the IR dashboard reduced Mean Time to Detect (MTTD) by 18%, and the suggested dashboard's average job accuracy (0.873) was higher than that of the baseline tool (0.772). The CoA risk assessment framework, focused on confidentiality, achieved a strong Kendall-W score of 0.71 for resource prioritization. The Perimeterless stack provides a flexible and scalable framework for developing new cybersecurity technologies. Because it allows them to modify the stack to meet particular needs and requirements, it is especially helpful for security teams who do not have direct access to application code or environments. Expanding situational awareness features, automating log unification across various CSPs, and examining the possibilities of graph-based models for proactive threat hunting in managed serverless systems are the main areas of future research.\u003c/p\u003e"},{"header":"Declarations","content":"\u003cp\u003e \u003ch2\u003eConflict of Interest :\u003c/h2\u003e \u003cp\u003eThe authors declare that there is no conflict of interest regarding the publication of this paper.\u003c/p\u003e \u003c/p\u003e\u003ch2\u003eAuthor Contribution\u003c/h2\u003e\u003cp\u003eR.Y. supervised the project, provided guidance, and reviewed the manuscript.V.P.G. and P.B.K. contributed to the methodology, implementation, and writing of the main manuscript text.M.P.K.R. was responsible for data collection, analysis, and preparation of figures and tables.\u003c/p\u003e\u003ch2\u003eData Availability :\u003c/h2\u003e \u003cp\u003eThe data used in this study are available from the corresponding author upon reasonable request.\u003c/p\u003e"},{"header":"References","content":"\u003col\u003e\n \u003cli\u003eParast, F.K., Sindhav, C., Nikam, S., Yekta, H.I., Kent, K.B., Hakak, S., \u0026quot;Cloud computing security: A survey of service-based models,\u0026quot; \u003cem\u003eComputers \u0026amp; Security\u003c/em\u003e, vol. 114, pp. 102580, 2022.\u003c/li\u003e\n \u003cli\u003eLeitner, P., Wittern, E., Spillner, J., Hummer, W., \u0026quot;A mixed-method empirical study of function-as-a-service software development in industrial practice,\u0026quot; \u003cem\u003eJournal of Systems and Software\u003c/em\u003e, vol. 149, pp. 340\u0026ndash;359, 2019.\u003c/li\u003e\n \u003cli\u003eEismann, S., Scheuner, J., Van Eyk, E., Schwinger, M., Grohmann, J., Herbst, N., Abad, C.L., Iosup, A., \u0026quot;The state of serverless applications: Collection, characterization, and community consensus,\u0026quot; \u003cem\u003eIEEE Transactions on Software Engineering\u003c/em\u003e, vol. 48, no. 10, pp. 4152\u0026ndash;4166, 2021.\u003c/li\u003e\n \u003cli\u003eCastro, P., Ishakian, V., Muthusamy, V., Slominski, A., \u0026quot;The rise of serverless computing,\u0026quot; \u003cem\u003eCommunications of the ACM\u003c/em\u003e, vol. 62, no. 12, pp. 44\u0026ndash;54, 2019.\u003c/li\u003e\n \u003cli\u003eShafiei, H., Khonsari, A., Mousavi, P., \u0026quot;Serverless computing: A survey of opportunities, challenges, and applications,\u0026quot; \u003cem\u003eACM Computing Surveys\u003c/em\u003e, vol. 54, no. 11s, pp. 1\u0026ndash;32, 2022.\u003c/li\u003e\n \u003cli\u003eMarin, E., Perino, D., Di Pietro, R., \u0026quot;Serverless computing: A security perspective,\u0026quot;\u0026nbsp;\u003cem\u003eJournal of Cloud Computing\u003c/em\u003e, vol. 11, no. 1, pp. 1\u0026ndash;12, 2022.\u003cbr\u003eLi, X., Leng, X., Chen, Y., \u0026quot;Securing serverless computing: Challenges, solutions, and opportunities,\u0026quot; \u003cem\u003eIEEE Network\u003c/em\u003e, 2022.\u003c/li\u003e\n\u003c/ol\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":false,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":true,"hideJournal":false,"highlight":"","institution":"","isAcceptedByJournal":false,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":false,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"journal-of-grid-computing","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"grid","sideBox":"Learn more about [Journal of Grid Computing](http://link.springer.com/journal/10723)","snPcode":"10723","submissionUrl":"https://submission.nature.com/new-submission/10723/3","title":"Journal of Grid Computing","twitterHandle":"","acdcEnabled":true,"dfaEnabled":true,"editorialSystem":"em","reportingPortfolio":"Springer Hybrid","inReviewEnabled":true,"inReviewRevisionsEnabled":false},"keywords":"Cloud, Cloud Computing, Security, Cloud forensics, Monitoring","lastPublishedDoi":"10.21203/rs.3.rs-6270470/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-6270470/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003cp\u003eIn a fully managed serverless environment, the cloud service provider is responsible for securing the cloud infrastructure, considerably decreasing application developers' operational and maintenance workloads. However, such environments limit the use of traditional cybersecurity tools and frameworks, reducing observability and situational awareness (for example, risk assessment and incident management). Furthermore, existing security frameworks designed for serverless applications frequently lack universal adaptability to different application architectures and require customization, expert skills, and other adaptations for implementation in fully managed serverless environments. This article describes a three-tiered security system developed primarily for applications deployed in fully controlled serverless environments. The first two tiers use an innovative ontology developed entirely from serverless logs to turn them into a unified application activity knowledge graph. The third tier tackles the critical need for observability and situational awareness by adding two graph-based tools: An incident response interface that uses ontologies to visualize and analyse application activity records in connection to cybersecurity warnings. User research found that this tool allowed users to respond to new security alarms more quickly and accurately than a baseline tool. A paradigm for evaluating the criticality of assets (CoA) that enables specialists to prioritize cybersecurity scenarios effectively.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e","manuscriptTitle":"Integrated Dashboard for Real-time Security Monitoring and Incident Response","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2025-04-11 03:45:54","doi":"10.21203/rs.3.rs-6270470/v1","editorialEvents":[{"type":"communityComments","content":0},{"type":"editorInvitedReview","content":"","date":"2025-10-13T09:24:35+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"153151510861801748207733882149483467235","date":"2025-10-05T07:13:24+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"15209814043871052554565839123824440810","date":"2025-06-09T13:36:06+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"25315146243366604711313144946759874","date":"2025-06-03T20:56:57+00:00","index":"hide","fulltext":""},{"type":"reviewersInvited","content":"","date":"2025-06-03T18:07:36+00:00","index":"","fulltext":""},{"type":"editorAssigned","content":"","date":"2025-03-21T08:51:21+00:00","index":"","fulltext":""},{"type":"checksComplete","content":"","date":"2025-03-21T03:21:26+00:00","index":"","fulltext":""},{"type":"submitted","content":"Journal of Grid Computing","date":"2025-03-20T14:14:59+00:00","index":"","fulltext":""}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"journal-of-grid-computing","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"grid","sideBox":"Learn more about [Journal of Grid Computing](http://link.springer.com/journal/10723)","snPcode":"10723","submissionUrl":"https://submission.nature.com/new-submission/10723/3","title":"Journal of Grid Computing","twitterHandle":"","acdcEnabled":true,"dfaEnabled":true,"editorialSystem":"em","reportingPortfolio":"Springer Hybrid","inReviewEnabled":true,"inReviewRevisionsEnabled":false}}],"origin":"","ownerIdentity":"4dcffa01-dbf1-4161-a199-3aec3bb0c0e1","owner":[],"postedDate":"April 11th, 2025","published":true,"recentEditorialEvents":[],"rejectedJournal":[],"revision":"","amendment":"","status":"under-review","subjectAreas":[],"tags":[],"updatedAt":"2025-06-03T18:23:09+00:00","versionOfRecord":[],"versionCreatedAt":"2025-04-11 03:45:54","video":"","vorDoi":"","vorDoiUrl":"","workflowStages":[]},"version":"v1","identity":"rs-6270470","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-6270470","identity":"rs-6270470","version":["v1"]},"buildId":"8U1c8b4HqxoKbykW_rLl7","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}