In the ever-evolving landscape of cloud security, AWS CloudTrail has emerged as an essential tool for monitoring and understanding activity across your AWS environment. By logging user actions and resource behavior, CloudTrail provides invaluable insights for strengthening security, ensuring compliance, and creating a robust audit trail.

However, while CloudTrail captures a wealth of event data, the real challenge lies in identifying anomalies that could indicate potential threats. This blog explores how CloudTrail can be leveraged for threat hunting and anomaly detection, offering practical guidance and alert strategies to detect suspicious activities early.

What is AWS CloudTrail?

AWS CloudTrail records detailed logs of actions across AWS services, including:

• Who performed an action
• When it occurred
• Where it originated

These logs form a comprehensive audit trail, aiding:

• Security analysis by identifying unauthorized activities
• Compliance auditing to meet regulatory requirements
• Resource tracking to monitor and troubleshoot changes

Despite its comprehensive coverage, organizations often face challenges in identifying meaningful patterns amid the data, especially during an active attack where the attacker’s sequence of actions must be pieced together.

The Threat Landscape: Why Anomaly Detection is Crucial

Threat actors often begin with reconnaissance to find vulnerabilities, subsequently escalating privileges and exploiting resources. Detecting this early activity can significantly reduce potential damage. Yet, AWS doesn’t provide a built-in guide on which CloudTrail events to monitor or how to prioritize them.

To address this gap, Coralogix has developed a threat-hunting framework using CloudTrail, focusing on over 150 critical events. This includes a correlation alert with its foundational building blocks to link together multiple anomalous events that are usually seen during reconnaissance and an anomaly dashboard to identify suspicious activity effectively.

Building Blocks for Anomaly Detection

1. Multiple Events Detected (By User)

Alert Trigger:
This alert fires when more than 15 unique CloudTrail events that are part of 150 critical events as mentioned above, are detected from a single user within a 20-minute interval.

Rationale: External threat actors usually use automated tools to perform recon activities. When they run such tools, a high number of CloudTrail events are logged within a short interval of time. Many of these events are for “Get”, “List” and “describe” actions. 

Challenges & Fine-Tuning Recommendations:

• False Positives: High activity by legitimate users can trigger this alert.
• Fine-Tuning Recommendations:
  • Adjust threshold values based on usage patterns.
  • Whitelist specific users as needed.

This alert provides a high-fidelity signal for detecting unusual access patterns when fine-tuned to your organization’s needs.

2. Unique Error Types

Alert Trigger:
This alert fires when more than one unique error code is detected within a 20-minute interval for CloudTrail events from a single user.

Rationale:
Threat actors operating in unfamiliar environments often cause multiple unique errors due to insufficient knowledge of permissions and privileges.

Fine-Tuning Recommendations:

• Understand the reasons behind these errors (e.g., misconfigurations or malicious attempts).
• Whitelist legitimate users or error codes where appropriate.

3. More than Usual Errors

Alert Trigger:
This alert fires when an unusually high number of errors are detected in CloudTrail events for a single user within a 20-minute window.

Rationale:
Similar to the previous alert, attackers’ lack of familiarity often leads to failed actions, making this metric a strong indicator of suspicious activity.

Correlation Alert: Correlating Anomalies for Better Detection

To enhance detection fidelity, a correlation alert combines the above building blocks. This alert triggers when either of the following combinations occur within 20 minutes:

• Combination 1:
  • Multiple Events Detected (By User)
  • Unique Error Types
• Combination 2:
  • Multiple Events Detected (By User)
  • More than Usual Errors

Purpose of the Correlation Alert

This alert flags multiple anomalous activities by a user in a short time frame, especially those resulting in errors or unusual patterns. Such behavior is rarely legitimate and warrants further investigation. If the activity is benign, adjust the relevant building block alerts by:

• Modifying thresholds
• Whitelisting specific users or error codes

Dashboards: Visualizing the Anomalies

In addition to the alerts, Coralogix has also created a dashboard that provides:

• A clear view of event trends and anomalies
• Insights into top users triggering errors or anomalies
• Breakdown of error codes by user, helping to pinpoint the root cause

By combining alerts with actionable insights, organizations can quickly identify and respond to potential threats.

Conclusion

AWS CloudTrail is a powerful tool for cloud monitoring, but its true value lies in its ability to enable proactive threat hunting. By implementing the above strategies, organizations can:

• Detect and investigate suspicious activities early
• Minimize false positives with tailored fine-tuning
• Strengthen overall security posture

With the right tools, dashboards, and alert configurations, CloudTrail becomes a cornerstone of any robust cloud security strategy. Start your anomaly detection journey today to stay ahead of potential threats and protect your AWS environment.

Kubernetes continues to be the favorite orchestration tool for most companies. This consistent demand means that the need for advanced security and observability solutions has never been greater. Tetragon, powered by the innovative eBPF technology, provides a groundbreaking approach to runtime security and system observability. By operating directly within the Linux kernel, Tetragon enables teams to monitor, detect, and enforce policies with unparalleled efficiency and precision.

This article explores how Tetragon leverages eBPF to deliver real-time insights into Kubernetes environments, enhance threat detection, and streamline policy enforcement. We’ll also look at how Coralogix amplifies these capabilities, offering powerful analytics, alerting, and visualization tools to turn Tetragon’s data into actionable intelligence for modern cloud-native ecosystems.

What is Tetragon?

Tetragon, developed by Cilium, is an open-source runtime security observability and enforcement platform. It leverages eBPF technology to provide real-time monitoring, detection, and enforcement of security policies directly within the Linux kernel. Tetragon enables fine-grained visibility into system activities without requiring intrusive instrumentation or modifying application code.

What is eBPF anyway…?

Extended Berkeley Packet Filter is a revolutionary technology in the Linux kernel that allows programs to run safely and efficiently within the kernel space without modifying kernel source code or adding modules.

eBPF provides a programmable interface to dynamically attach small programs to kernel-level events, such as system calls, network packets, and file operations, enabling deep observability and control over system behavior.

Unlike traditional observability solutions, eBPF operates at the kernel level, providing unparalleled visibility into application and system events with minimal overhead.

Traditional methods often rely on user-space instrumentation or kernel modules, which can be intrusive, require context switching, and may introduce performance penalties. In contrast, eBPF programs execute directly in the kernel’s execution context, offering high-performance data collection and real-time insights without the need for costly polling or extensive logging.

This unique capability makes eBPF an ideal foundation for modern observability, security, and performance monitoring tools.

Application and Usage In Kubernetes

By combining eBPF’s kernel-level observability with Tetragon’s Kubernetes-native capabilities, teams can achieve a high-performance, secure, scalable observability and security solution tailored for modern cloud-native environments.

Real-Time Observability

Extends eBPF’s capabilities to provide real-time monitoring of process execution, file access, and network activity for Kubernetes pods and nodes.

Tracks workload behaviors at a granular level to aid in debugging, compliance, and performance optimization.

Runtime Threat Detection

Can detect anomalous behaviors and security threats within Kubernetes clusters, such as unauthorized process execution, suspicious file writes, or network connections.

Useful for identifying and responding to active threats without waiting for postmortem analysis.

Native Kubernetes Integration

Integrates with Kubernetes metadata (e.g., pods, namespaces, labels), mapping observability data to specific workloads and clusters, and provides a Kubernetes-aware view of security events, making it easier to manage and enforce security at the application level.

Policy Enforcement

Enforces granular security policies directly in the kernel, tailored to specific workloads or namespaces in the Kubernetes cluster.

Enhanced Forensics and Audit Capability

Captures detailed logs of system events, making it easier to perform root-cause analysis or audits for compliance requirements making it extremely useful for tracing back the origin of security incidents or debugging application issues.

Scalability for Large Clusters

Designed to operate efficiently at scale, leveraging eBPF’s low overhead to monitor large Kubernetes deployments without impacting performance making it suitable for environments with dynamic workloads where traditional tools struggle to keep up or are less scaleable.

Lightweight Agent Deployment

Tetragon agents run as lightweight daemons on Kubernetes nodes, avoiding the need for complex instrumentation or sidecar containers.

How it all comes together

Coralogix enhances the observability and operational insights of Tetragon by leveraging advanced log correlation, powerful alerting mechanisms, and intuitive visualizations. Coralogix allows users to unify Tetragon’s detailed runtime logs with data from other sources such as cloud platforms such as AWS, application logs, and network traffic.

This centralization enables users to correlate eBPF-driven insights, such as process execution or anomalous system calls, with other contextual information, like application behavior or network activity. Such correlations provide a holistic view of the cluster, making it easier to troubleshoot issues, detect threats, and optimize system performance.

The alerting capabilities enable real-time notifications based on predefined or custom thresholds, patterns, or anomalies in the logs. For example, users can configure alerts for specific eBPF-detected events like privilege escalations or unauthorized file access. These alerts are enriched with Kubernetes metadata (e.g., pod name, namespace) and provide actionable context for rapid incident response.

Customized dashboards are available to display actions and trends derived from Tetragon events, such as process activity, and system call distributions. By combining these insights with Kubernetes performance data, users gain a comprehensive view of their environment in an intuitive format. This facilitates proactive performance tuning, compliance auditing, and security posture evaluation.

In short, Coralogix amplifies Tetragon’s capabilities by turning its granular kernel-level observability into actionable intelligence, seamlessly integrated into the broader ecosystem of a Kubernetes monitoring strategy.

Learn more about Coralogix security here.

In today’s fast-evolving cybersecurity landscape, organizations face an increasing number of threats targeting their digital assets. Offensive Security Assessment plays a critical role in safeguarding these assets by proactively identifying and addressing vulnerabilities before attackers can exploit them. This method simulates real-world attack scenarios to test and enhance an organization’s security defenses.

What is an Offensive Security Assessment?

Offensive Security Assessment is a hands-on approach to evaluating an organization’s security posture by mimicking the behavior of malicious attackers. By simulating multi-stage attacks, this technique identifies potential vulnerabilities and explores how an attacker might exploit them. It assumes an attacker has already gained initial access to the system and examines how they could escalate privileges, move laterally within the Cloud, exfiltrate sensitive data, or disrupt operations.

Offensive, Defensive, and Purple Teaming Insights

Elevate Your Offensive Security Assessment: Proactive Strategies for Modern Threats

In today’s complex Infrastructure, understanding and addressing vulnerabilities is critical to safeguarding your assets. This guide walks you through key strategies to strengthen your cloud security posture by combining offensive, defensive, and collaborative approaches.

Detect Critical Gaps in Your Infrastructure

Assess the infrastructure to determine the blast radius and evaluate the potential impact of security misconfigurations. By prioritizing mitigation strategies based on the highest risks, you can proactively strengthen your defenses and focus on the most critical areas for improvement.

Identify Rogue Access in Your Cloud Environment

Detect accounts, users, and groups with unnecessary or elevated privileges to sensitive information. By analyzing cloud permissions, you can minimize the attack surface and enforce least privilege principles.

Elevate Your Security with Collaborative Purple Teaming

Leverage the power of Purple Teaming to enhance your defenses:

• Collaborative Assessments: Work alongside experts to simulate real-world attack scenarios based on findings from offensive security assessments.
• Enhanced Visibility: Integrate missing log sources into Coralogix for comprehensive monitoring and detection.
• Custom Recommendations: Build tailored strategies to detect and respond to threats, enhancing your overall alerting capabilities.

Full Flexibility for Custom Attack Scenarios

Test your cloud infrastructure under tailored conditions, focusing on your specific threat landscape. Whether targeting insider threats, unauthorized access, or lateral movement, the flexibility ensures the assessment aligns with your business objectives.

Simulating Real-World Attack Scenarios with Operational Safeguards

Demonstrate how skilled adversaries could exploit vulnerabilities in your cloud environment, all while maintaining operational integrity.

Our safeguards include:

• No Service Disruption: Ensuring uninterrupted operations throughout the assessment.
• Data Integrity: No deletion or modification of existing data.
• Configuration Preservation: Retaining current system configurations during testing.

These safeguards allow for a realistic yet safe assessment of your defenses, preparing your team to detect and respond to advanced threats without risk to your business continuity.

Why Snowbit for Offensive Security?

At Snowbit, we go beyond traditional security assessments. Our Offensive Security Assessment helps customers identify custom attack paths unique to their infrastructure—paths that could be exploited by adversaries. By leveraging cutting-edge techniques, our managed security services team simulates real-world attack scenarios to uncover vulnerabilities and hidden risks.

Turn Insights Into Actionable Alerts
Following each assessment, our research team develops tailored alerts for every identified attack path, ensuring continuous monitoring and proactive defense. These alerts are integrated directly into the Coralogix SIEM platform, giving customers unparalleled visibility and actionable intelligence to safeguard their cloud environments.

Case Study:

GCP Offensive Security Assessment

AWS Offensive Security Assessment

Learn more about Coralogix security offerings today

Amazon Virtual Private Cloud (VPC) Flow Logs is a feature provided by AWS (Amazon Web Services) that allows you to capture information about the IP traffic going to and from network interfaces in your VPC. It provides detailed information about the traffic within your VPC, including information such as source and destination IP addresses, ports, protocol, and the amount of data transferred.

VPC Flow logs capture information that provide visibility into network traffic for monitoring, troubleshooting security and performance, and optimizing resource utilization. The information captured includes: 

• Source and destination IP addresses and ports
• Protocol (TCP, UDP, ICMP)
• Number of packets and bytes
• Start and end time of flows
• Whether the traffic was accepted or rejected

VPC Flow logs do not capture payload data or real-time traffic; data is aggregated over 10 seconds or longer intervals before being published to CloudWatch Logs, S3, or Kinesis Firehose.

Decoding and Understanding AWS VPC Flow Logs

It’s essential to understand what each field captured in a VPC flow log means, in order to analyze and troubleshoot your VPC network traffic effectively. Here’s a quick overview:

Default Fields

VPC flow logs contain the following default fields:

• version: The VPC flow logs version used
• account-id: The AWS account ID that owns the interface
• interface-id: The ID of the elastic network interface (ENI) where traffic is recorded
• srcaddr: The source IP address
• dstaddr: The destination IP address
• srcport: The source port number
• dstport: The destination port number
• protocol: The protocol (TCP, UDP, ICMP, and etc.)
• packets: The number of packets in the flow
• bytes: The number of bytes in the flow
• start: The time the flow started
• end: The time the flow ended
• action: Whether traffic was accepted or rejected
• log-status: Logging completion status

Additional Fields

You can enable further metadata like:

• VPC ID: ID of the VPC containing the interface
• Subnet ID: ID of the subnet containing the interface
• Instance ID: ID of the EC2 instance containing the interface
• TCP flags: TCP flags seen on the flow (SYN, ACK, etc.)
• Type: Type of flow (IPv4 or IPv6)
• Packet loss: Percentage of lost packets

These fields can provide more context for the recorded flows.

Analyzing the comprehensive flow log data enables deep network visibility for monitoring, troubleshooting, and optimization.

Key Benefits of Enabling VPC Flow Logs

VPC Flow Logs can help with: 

• Network monitoring: Analyze traffic patterns, identify anomalous flows, and optimize performance.
• Troubleshooting: Diagnose connectivity and latency issues and ACL misconfigurations.
• Security analysis: Detect suspicious traffic, unauthorized access attempts, and DDoS patterns. 
• Cost optimization: Identify unnecessary traffic across regions/VPCs to reduce data transfer costs.

Enabling VPC Flow Logs

You can enable flow logs at the VPC, subnet, or network interface level. Flow logs can be published to CloudWatch Logs, S3, or Kinesis Firehose.

To enable, you specify the resources to monitor and the destination via AWS Console, CLI, or API calls. You can also configure sampling rate, aggregation interval, and filters.

Using the AWS Management Console

• Open the Amazon VPC Console and navigate to “Flow Logs” in the left sidebar
• Click “Create Flow Log”
• Specify the resources to monitor by choosing VPCs, Subnets, or Network Interfaces
• Select the destination for logs – CloudWatch Logs, S3 bucket, or Kinesis Data Firehose
• Set additional parameters like log format, filters, or aggregation interval
• Click “Create”

Using AWS CLI

Below is a sample CLI command to create a flow log:

aws ec2 create-flow-logs –resource-ids vpc-111bbb222 –resource-type VPC –traffic-type ALL –log-destination-type cloud-watch-logs

Using CloudFormation Template

You can specify a flow log resource in your AWS CloudFormation template as below:

Resources:

  VPCFlowLog: 

    Type: AWS::EC2::FlowLog

    Properties:

      ResourceType: VPC

      ResourceId: vpc-12abc34df5

      TrafficType: ALL

      LogDestinationType: cloud-watch-logs

      LogDestination: !Ref LogsGroup

      LogFormat: ${version} ${vpc-id}

This allows flow log creation to be automated as part of stack deployments.

The key is choosing the right resources for monitoring, log destinations, and traffic filters based on your specific use cases.

Enhanced Visibility with Coralogix

Sending your VPC Flow Logs to Coralogix provides greater visibility with:

• Log parsing and indexing to make logs searchable and easier to analyze
• Anomaly detection to spot abnormal traffic patterns 
• Root cause analysis to correlate network issues with other log types inside a VPC
• Traffic pattern analysis over time to understand growth and changes

Coralogix integrates seamlessly with AWS services to ingest flow logs data and provides a powerful query language and visualization tools for insights.

You can read more about how to set up VPC flow logs delivery to S3 for streaming via lambda to Coralogix here.

Coralogix security offering provides a comprehensive set of out-of-the-box detections & alerts for AWS VPC Flow Logs. Some of the notable ones include:

Alerts

Here are some examples of the out-of-the-box alerts customers can deploy to their platform with 1-click.

• Non-Standard DNS Protocol Activity
  • Scope: This alert triggers when DNS queries from internal hosts use TCP port 53 instead of the standard UDP. While TCP over port 53 can be legitimate for zone transfers or to accommodate large packets, it can also indicate suspicious activities such as tunneling or attempts to bypass security controls.
  • Potential Impact: Non-standard DNS protocol activity could indicate malicious behavior, such as data exfiltration or command and control communication. It may lead to unauthorized access to resources, data breaches, or the introduction of malware into the network.
  • Remediation Recommendation:
    • Investigate: Immediately investigate the source and destination of the DNS traffic using TCP port 53. Determine if it aligns with legitimate activities such as zone transfers or if it indicates malicious behavior.
    • Monitor: Continuously monitor DNS traffic for similar anomalies. Implement alerting mechanisms to promptly identify and respond to any deviations from normal behavior.
    • Restrict Traffic: Enforce strict egress filtering rules to only allow DNS traffic over UDP port 53. Consider implementing DNS security solutions that can detect and mitigate suspicious DNS activities.
    • Educate Users: Educate internal users about the risks associated with non-standard DNS protocol activities and the importance of adhering to security policies and best practices.

• Incoming Connections Over Remote Service Ports
  • Scope: This alert triggers when an incoming SSH (port 22) or RDP (port 3389) connection is accepted. These ports enable remote command line and desktop access, posing a security risk if unauthorized.
  • Potential Impact: Unauthorized incoming SSH or RDP connections can lead to unauthorized access to sensitive systems, data breaches, or the execution of malicious activities such as privilege escalation or data theft.
  • Remediation Recommendation:
    • Review Access Controls: Review and strengthen access controls to restrict SSH and RDP access only to authorized users and IP addresses.
    • Implement Multi-Factor Authentication (MFA): Require the use of MFA for SSH and RDP authentication to add an extra layer of security.
    • Monitor and Audit: Continuously monitor incoming SSH and RDP connections for unauthorized access attempts. Enable detailed logging and auditing to track user activities and detect suspicious behavior.
    • Network Segmentation: Implement network segmentation to isolate critical systems from less secure environments, reducing the impact of potential security breaches.
    • Update and Patch Systems: Ensure that SSH and RDP servers are regularly updated with the latest security patches to mitigate known vulnerabilities.

• Excessive Inbound ICMP Traffic
  • Scope: This alert triggers whenever an IP address sends many ICMP ping requests to hosts within a VPC within a short interval.
  • Potential Impact: Excessive inbound ICMP traffic can potentially be used in ICMP flood attacks, causing network congestion, service disruption, or denial of service (DoS) to the affected hosts.
  • Remediation Recommendation:
    • Implement Rate Limiting: Configure rate-limiting mechanisms to limit the number of ICMP requests allowed per second, mitigating the impact of ICMP flood attacks.
    • Block Suspicious IPs: Identify and block IP addresses generating excessive ICMP traffic, especially those exhibiting patterns indicative of malicious intent.
    • Network Intrusion Detection/Prevention Systems (NIDS/NIPS): Deploy NIDS/NIPS solutions to detect and block ICMP flood attacks in real-time.
    • Traffic Shaping: Implement traffic shaping techniques to prioritize legitimate traffic and mitigate the impact of ICMP floods on network performance.
    • Update Security Policies: Regularly review and update security policies to adapt to emerging threats and vulnerabilities, including ICMP flood attacks.

Dashboards

Using Coralogix Security, out-of-box insights can be deployed to understand various metrics. Some of the examples include – 

• Total Accepted/Rejected traffic
• Total Egress traffic
• Distribution of top source countries over time
• Top source IPs
• Top destination IPs etc.

Optimization Based on Insights

By leveraging the deeper visibility provided by VPC Flow Logs analytics with Coralogix, you can:  

• Detect and troubleshoot sub-optimal network routes faster
• Identify unnecessary cross-region/VPC traffic to minimize costs
• Inform security group and NACL rules optimization
• Plan for scaling needs proactively based on growth trends

VPC Flow Logs + Coralogix provides the comprehensive visibility and analytics capabilities needed to master observability across cloud-native applications and dynamic AWS network environments.

Conclusion

As we have seen, VPC flow logs are essential to the Security Monitoring arsenal. By sending AWS VPC flow logs to Coralogix, organizations can unlock further value through integrated log analytics and security capabilities. Coralogix enables faster searching through parsing and indexing and customizable dashboards and alerts tailored to the environment that provide security teams early warning across operations, security, and business metrics extracted from the flow logs.

Learn more about Coralogix security offerings today.

Amazon Route53

Amazon Route53 is a highly available and scalable Domain Name System (DNS) web service provided by Amazon Web Services (AWS). Its primary purpose is to enable users to route internet traffic to their resources, such as websites, web applications, and APIs, while offering domain registration, DNS routing, and health-checking capabilities. 

It is designed to deliver fast and reliable connections to internet applications running on AWS or on-premises systems. It uses a global network of servers to answer DNS queries and maintains high availability through redundant controls and data planes. 

Users can leverage this service to build complex routing relationships, set up both public and private hosted zones, and implement health checks to ensure application availability.

Here is a brief visual overview, including logs, best practices, detections, and the security value we will discuss in this post:

Amazon Route53 Resolver

It is a component that facilitates DNS query resolution across AWS, the internet, and on-premises networks with secure control over Amazon Virtual Private Cloud (VPC) DNS. 

Here are some key features and functionalities:

• Inbound DNS Resolution – Resolve DNS queries originating from your VPCs to outside, such as public internet or other AWS services within the same account. Receive recursive DNS resolution for your VPCs, allowing them to resolve public domain names or private domain names within your AWS environment.
  
• Outbound DNS Resolution – Resolve DNS queries originating from your on-premises network to resources within your VPCs. It acts as a resolver for your on-premises DNS servers, allowing them to resolve private domain names hosted in your AWS environment.
  
• Resolver Endpoints – Use resolver endpoints deployed within your VPCs to handle DNS queries. These endpoints can be configured to forward DNS queries to designated DNS resolvers in your on-premises network or to use Route53 Resolver’s built-in recursive DNS resolvers for outbound resolution.
  
• Conditional Forwarding – Implement conditional forwarding rules, allowing you to direct DNS queries for specific domain names or subdomains to designated DNS resolvers in your on-premises network.
  
• Integration with AWS Services – Seamless integration with other AWS services, such as Amazon VPC, AWS Directory Service, and AWS Transit Gateway, to provide secure and reliable DNS resolution across hybrid cloud environments.

For more detailed guidance on setting up and utilizing resolver, refer to the AWS documentation.

Best Practices for Route53 Resolver

• Avoid Loop Configurations – Do not associate the same VPC to a Resolver rule and its inbound endpoint, especially if they share a common VPC, or else risk entering loops where queries are continuously passed back and forth without reaching the intended destinations.
  
• Use Resolver Endpoints – Simplify DNS management and reduce administrative overhead.
  
• Implement DNS Resolution Rules – Route traffic to specific DNS resolvers based on domain names or IP addresses, enabling granular control over DNS resolution.
  
• Use Conditional Forwarding – Configure conditional forwarding rules to direct DNS queries for specific domains or subdomains to designated DNS servers in your on-premises network. This allows you to maintain centralized control over DNS resolution for your organization’s internal domains while leveraging Route53 Resolver for other DNS queries.
  
• High Availability – When creating your Route 53 Resolver inbound endpoints, ensure to create at least two IP addresses that the DNS resolvers on your network will forward queries to. It is also recommended to specify IP addresses in at least two Availability Zones for redundancy.
  
• Security Measures – Configure DNS firewall rules to block or allow DNS queries based on predefined criteria, such as domain names, IP addresses, or query types. This helps protect your network from DNS-based attacks, such as malware infections, data exfiltration, or command-and-control communication. Also, use DNS over HTTPS (DoH) or DNS over TLS (DoT) to encrypt DNS queries and responses, preventing eavesdropping and tampering by attackers.
  
• Enable DNS Query Logging – Troubleshoot DNS-related issues, detect malicious activity, and comply with regulatory requirements.

For more detailed guidance on best practices, refer to the AWS documentation. 

Monitoring Route53 Resolver Logs

Monitoring is an important part of maintaining the reliability, availability, and performance of your AWS solutions. To monitor resolver logs, you can enable query logging, which records all DNS queries that your resolver handles. Optimize the performance and reliability of your DNS resolution and ensure compliance with relevant regulations.

Resolver Query Logging

AWS Route53 Resolver query logging allows you to monitor DNS queries originating from Amazon Virtual Private Cloud (VPC) environments and on-premises resources connected via Resolver endpoints. By configuring query logging, you can gain insight into the following types of queries:

• Queries initiated within specific VPCs
• Queries from on-premises resources using inbound Resolver endpoints
• Queries using outbound Resolver endpoints for recursive DNS resolution
• Queries involving Route53 Resolver DNS Firewall rules

Resolved queries are logged with information such as the AWS Region, VPC ID, source IP address, instance ID, query name, DNS record type, response code, and response data. Logged queries are sent to one of the following AWS resources: 

• Amazon CloudWatch Logs
• Amazon Simple Storage Service (S3)
• Amazon Kinesis Data Firehose

Please see here for more details.

Public DNS Query Logging

Amazon Route53 provides DNS query logging capabilities that allow you to monitor and log information about the public DNS queries received by Route53. These logs provide insights into the following:

• Domain or subdomain requested
• Date and time of the request
• DNS record type (e.g., A or AAAA)
• Route53 edge location that responded to the DNS query
• DNS response code, such as “NoError” or “ServFail”

Once you configure query logging, Route53 sends logs to Amazon CloudWatch Logs, where you can access and analyze them. This is particularly helpful for security analysis, troubleshooting, compliance auditing, and gaining insights into DNS query patterns.

Please see here for more details.

Please note that AWS Route53 Resolver query logging does not incur any additional charges apart from the fees for the selected destination service, such as Amazon CloudWatch Logs, Amazon Simple Storage Service (S3), or Amazon Kinesis Data Firehose.

Security Monitoring Use Cases

The security value of AWS Route53 Resolver logs is quite significant. By enabling Resolver logging, you gain visibility into the DNS query activity within your infrastructure, along with: 

• Security Monitoring Of DNS Specific Attacks – Detect and investigate suspicious or unauthorized DNS activity. By analyzing DNS query logs, you can identify potential indicators of compromise, such as unusual query patterns, unauthorized domain resolutions, or attempts to access malicious domains. Here are some examples of potential attacks on AWS Route53 Resolver:

• DNS Spoofing or Cache Poisoning – Attackers may attempt to poison the DNS cache of Route53 Resolver by sending forged DNS responses containing incorrect or malicious IP addresses for legitimate domain names. This can lead to users being directed to attacker-controlled servers, enabling various forms of attacks such as phishing or malware distribution.
  
• DNS Amplification – Attackers may abuse Route53 Resolver’s recursive DNS capabilities to launch DNS amplification attacks. By sending large volumes of DNS queries with spoofed source IP addresses to Route53 Resolver, attackers can cause it to generate significantly larger DNS responses, amplifying the volume of traffic directed at a victim’s network, potentially leading to denial-of-service (DoS) conditions.
  
• DNS Tunneling – Attackers may use DNS tunneling techniques to bypass network security controls and exfiltrate data from compromised systems. By encoding data within DNS queries or responses, attackers can establish covert communication channels with external servers, allowing them to transfer sensitive information undetected by traditional security mechanisms.
  
• DNS Flood Attacks – Attackers may launch DNS flood attacks against Route53 Resolver by sending a high volume of bogus DNS queries or responses to overwhelm its resources and cause service disruptions. DNS flood attacks can degrade the performance of Route53 Resolver, leading to increased latency, packet loss, or even service outages.
  

• Anomaly Detection – Route53 Resolver logs can help you identify abnormal DNS behavior within your network. By comparing DNS query logs over time, you can detect unusual spikes in query volume, unexpected changes in DNS resolution patterns, or anomalous DNS responses that may indicate security incidents or infrastructure issues.
  
• Incident Response – In the event of a security incident or a potential breach, Resolver logs can provide valuable evidence for investigation. By correlating DNS query data with other security events and logs, such as firewall or endpoint logs, you can reconstruct the attack chain and identify the root cause of the incident. This helps in understanding the scope of the incident and taking appropriate remedial actions.
  
• Performance and Troubleshooting – Resolver logs provide insights into DNS query performance and can help in troubleshooting DNS-related issues. By monitoring query response times, error rates, and other relevant metrics, you can identify bottlenecks, misconfigurations, or connectivity issues that may impact the performance of your DNS infrastructure. This allows you to proactively address these issues and ensure optimal DNS resolution.

In summary, monitoring AWS Route53 Resolver logs is essential for security, incident response, compliance, and performance optimization. It provides valuable insights into DNS activity, helps detect and respond to threats, and ensures the smooth functioning of your DNS infrastructure.

It’s important to note that while Route53 Resolver Logs provide valuable security value, they should be used in conjunction with other security measures and best practices to ensure a comprehensive security posture for your AWS infrastructure.

Out-of-the-Box AWS Route53 Resolver Security with Snowbit by Coralogix

So far we have discussed Route53 Resolver, best practices for using it effectively, and its security value. Equally important is to have in place mechanisms to be notified in real-time of any unusual or abnormal events and/or configuration changes. Hence detective controls are needed to be in place. 

Coralogix’s Snowbit security offering provides a comprehensive set of out-of-the-box detections & alerts for Route53 Resolver. Some of the notable ones include:

1. Route53 audit events
2. Anomalous DNS query response codes detected
3. Anomalous uncommon DNS record types detected
4. DNS queries to monero mining pools detected
5. AWS metadata query detected
6. DNS queries with Base64 encoded string detected
7. Anomalous DNS activity on TCP detected

Not only are existing alerts customizable based on specific customer requirements but also any needed custom detections and dashboards can be added quickly – reducing time to value dramatically.

We would love to discuss this further with you so feel free to schedule a demo with our team.

Modern day Security Information and Event Management (SIEM) tooling enterprise security technology combine systems together for a comprehensive view of IT security. This can be tricky, so we’ve put together a simple SIEM tutorial to help you understand what a great SIEM provider will do for you.

A SIEM’s responsibility is to collect, store, analyze, investigate and report on log and other data for incident response, forensics and regulatory compliance purposes. This SIEM tutorial will explain the technical capabilities that a SIEM provider should have.

Technical Capabilities of Modern SIEM Providers

Data collection

One of the most understood SIEM capabilities, data collection or log management, collects and stores the log files from multiple disparate hosts into a centralized location. This allows your security teams to easily access this information. Furthermore, the log management process can reformat the data it receives so that it is all consistent, making analysis less of a tedious and confusing process.

A SIEM can collect data in several ways and the most reliable methods include:

• Using an agent installed on the device to collect from
• By directly connecting to a device using a network protocol or API call
• By accessing log files directly from storage, typically in Syslog format or CEF (Common Event Format)
• Via an event streaming protocol like Netflow or SNMP

A core function of a SIEM is the ability of collecting data from multiple devices, standardizing it and saving it in a format that enables analysis.

Advanced analytics

A SIEM tool needs to analyse security data in real time time. Part of this process involves using ‘Advanced Analytics’. SIEM or ‘Next Gen SIEM’ tools of today, have been extending their capabilities to more frequently include analytics functions. These automated analytics run in the background to proactively identify possible security breaches within businesses’ systems. An effective SIEM provides advanced analytics by using statistics, descriptive and predictive data mining, machine learning, simulation and optimization. Together they produce additional critical insights. Key advanced analytics methods include anomaly detection, peer group profiling and entity relationship modeling.

New methods, modeling or machine learning techniques for generating these analytics, can be defined using SIEM tooling services from query editors (using KQL – Kibana Query Language), UEBA (User Entity Behavioral Analytics) and EBA (Entity Behavior Analysis) models. All configurable through user interfaces and can be managed using prebuilt or custom incident timelines. They can flag anomalies and display details of an incident for the full scope of the event and its context. 

As these analytics functions become more standard, some SIEM vendors are pairing the traditional log collection with threat detection and response automation. This is key to producing insights from high volumes of data, where machine learning can automate this analysis to identify hidden threats.

Advanced threat detection

Security threats will continually evolve. A ‘Next Gen’ SIEM should be able to adapt to new advanced threats by implementing network security monitoring, endpoint detection and response sandboxing and behavior analytics in combination with one another to identify and quarantine new potential threats. Security teams need specialized tools to monitor, analyze and detect threats across the cyber kill chain. A cyber kill chain being the steps that trace stages of a cyberattack from the early reconnaissance stages to the exfiltration of data. By configuring machine learning and search context analytics services, you can realize a risk-based monitoring strategy that automatically identifies and prioritizes attacks and threats, that the security team can quickly spot and investigate true dangers to your environment.

These are configurations that can be defined in modern day SIEMs, and will result in real time threat detection monitoring of endpoints from anti-virus logs, insecure ports to cloud services. The set goal of threat detection should be not only to detect threats, but also to determine the scope of those threats by identifying where a specific advance threat may have moved to after being initially detected, how that threat should be contained, and how information should be shared.

Incident Response

Our SIEM tutorial wouldn’t be complete without this feature. Incident response is an organizational process that allows security teams to contain security incidents or cyber attacks and prevent or control damages. Many organizations need to develop proactive incident response capabilities that will actively search corporate systems for signs of a cyber attack. Threat hunting is the core activity of proactive incident response, which is carried out by security analysts. It typically involves querying security data using a SIEM, and running vulnerability scans or penetration tests against organizational systems. The objective is to discover suspicious activity or anomalies that represent a security incident.

An effective incident response strategy needs a robust SIEM platform to identify, track and reassign incidents. This can add the capability of automation and orchestration to your SOC (Security Operation Center) making your cyber security incident response team more productive. A SOC can use customizable tools in the SIEM, designed for security incidents, ensuring that threats do not slip through the cracks. 

Other key capabilities should include the ability to either manually or automatically aggregates events, support for APIs that can be used to pull data from or push information to third-party systems, an ability to gather legally admissible forensics evidence, and playbooks that provide organizations with guidance on how to respond to specific types of incidents. SIEM solutions should display the security information in a simple format, such as graphics or dashboards.

SOC Automation

Modern day SIEMs will leverage Security Orchestration and Automation (SOAR) technology that helps identify and automatically respond to security incidents, and supports incident investigation by SOC team members. The foundational technology of a SOC is a SIEM system. The SIEM will use statistical models to find security incidents and raise alerts about them. These alerts will come with crucial contextual information. A SIEM functions as a ‘single pane of glass’ which enables the SOC to monitor enterprise systems.

Monitoring is a key function of tools used in the SOC. The SOC is responsible for enterprise-wide monitoring of IT systems and user accounts, and also monitoring of the security tools themselves. An example is ensuring antivirus is installed and updated on all organizational systems. The main tool that orchestrates monitoring is the SIEM.

SOC automation benefits from SOAR integration with SIEM. A SOAR platform will take things a step further by combining comprehensive data gathering, case management, standardization, workflow and analytics to provide organizations the ability to implement sophisticated defense-in-depth capabilities. A SOAR’s main benefit to a SOC, is that it can automate and orchestrate time-consuming, manual tasks using playbooks, including opening a ticket in a tracking system, such as JIRA, without requiring any human intervention. This would allow engineers and analysts to better use their specialized skills.

All in all…

SIEM tools are proving to be more important than ever in modern times of cyber security. They are becoming undeniably useful in being able to draw together data and threats from across your IT environment into a single easy-to-use dashboard. Many of ‘Next Gen SIEM’ tools are configured to flag suspect patterns on their own and sometimes even resolve the underlying issue automatically. The best SIEM tools are adept at using past trends to differentiate between actual threats and legitimate use, enabling you to avoid false alarms while simultaneously ensuring optimal protection.

This SIEM tutorial was aimed at providing context and clarity to the role of an effective SIEM provider. Any provider that is missing these capabilities should be investigated, to ensure they’re the right fit for you and your security operations.

In a previous post, we looked at an example of a fictional bookstore company and recommended mirroring strategies for that specific scenario. In this post, we’ll be looking at a fictional bank and recommended mirroring strategies for their network traffic.

For a list of the most commonly used strategies, check out our traffic mirroring tutorial.

GoldenBank

In this scenario, the client is running two different services, in two different private VPCs. The two VPCs cannot communicate with each other. The reverse proxies handle the majority of the traffic and perform basic request validations such as URIs and web methods and possibly also parameters type validation and then forward the request to the frontend servers.

Unlike the previous scenario, the connection between the reverse proxy and the frontend servers is also encrypted in TLS. The frontend servers perform business context validation of the requests and then process them by sending requests to the backend servers.

Close-up App1

Close-up App2

The backend servers in app1 rely on a storage server, while the backend servers of app2 rely on an AWS RDS service.

Following are the details of the security groups of all instances in both applications’ VPCs:

VPC App1

Rev Proxy

(No public IP)

Frontend

(No public IP)

Backend

(No Public IP)

Storage

(No Public IP)

DNS

(No Public IP)

Package Cache

(No Public IP)

Here are our visibility recommendations for similar networks:

Reverse proxies and front-end servers

Outbound

* Even though most of the traffic is encrypted since it would include responses to client requests, the outbound traffic is still extremely valuable. It can indicate the size of the data being sent to the client and assist in detecting large data leaks, it can detect connections originating from the reverse proxy itself and help detect command and control connections, it can also detect connections or connection attempts to other servers other than the frontend servers which can detect lateral movement.

Inbound

* Since the incoming traffic on HTTPS is encrypted, the only thing it can indicate is its volume over time which can indicate certain types of DoS or DDoS and also the validity of the certificates used. So if the traffic volume is expected to be high, we would recommend excluding this traffic.

Backend servers

Since the frontend servers are contacting these servers with requests that are supposed to be valid after the checks done by the proxy and frontend servers, the traffic volume is expected to be significantly lower than traffic volume to the proxy and frontend servers.

Also, since this is the last chance to detect malicious traffic before it reaches the database, we believe that all traffic from these servers should be mirrored. However, if this is still too expensive for your organization, we would recommend that you use the following mirroring configuration to at least be able to tell if a backend server is behaving abnormally which may indicate that it has already been breached:

Outbound

* – Although this rule will also mirror the server’s responses to frontend requests we do recommend that you mirror it since it might also contain HTTPS connections initiated by malware running on the proxy servers to command and control servers. Also, this might include unintended responses that will indicate that an attack (such as XSS or SQL Injection) took place.

** – Since the filesystem activity is usually heavy, we would recommend you avoid mirroring this type of traffic unless it is highly valuable in your application or network architecture.

Inbound

Storage servers

Outbound

DNS server

Since this server generates a very minimal amount of traffic that is so extremely valuable for detecting so many types of attacks we recommend that you would mirror all traffic in and out of this server.

Package cache server

Since this server is responsible for packages installations on all other servers, the data from and to this server can answer questions like who installed what and when, which can be crucial in a forensic investigation and for detecting installation of malicious tools on the server.

Also, the traffic volume from and to this server is expected to be quite low. Therefore, we recommend that you would mirror all traffic in and out of this server.

Bastion server

Since this server is serving as the only way to manage all other servers, provided that it is being used to update the code on the various servers, install required packages, etc., the traffic volume should be relatively low and the value of the data it can provide is extremely high and therefore we recommend that you would mirror all traffic in and out of this server.

VPC App2

Rev Proxy

(No Public IP)

Frontend

(No Public IP)

Backend

(No Public IP)

RDS

(No Public IP)

DNS

(No Public IP)

Package Cache

(No Public IP)

This network architecture is quite complex and would require an approach that would combine multiple data sources to provide proper security for it. In addition, it involves traffic that is completely encrypted, storage servers that are contacted via encrypted connections, and also AWS services that cannot be mirrored to the STA.

Here are our visibility recommendations for similar networks:

Reverse Proxies and Front-end servers

Outbound

* Even though most of the traffic is encrypted since it would include responses to clients requests, the outbound traffic is still extremely valuable. It can indicate the size of the data being sent to the client and assist in detecting large data leaks, it can detect connections originating from the reverse proxy itself and help detect command and control connections, it can also detect connections or connection attempts to other servers other than the frontend servers which can detect lateral movement.

Inbound

* Since the incoming traffic on HTTPS is encrypted, the only thing it can indicate is its volume over time which can indicate certain types of DoS or DDoS and also the validity of the certificates used. So if the traffic volume is expected to be high, we would recommend excluding this traffic.

Backend servers

Outbound

* – Since this server is expected to communicate with the RDS service, we would recommend mirroring all the traffic from this instance as this will allow the detection of database-related attacks. In addition, the RDS security group should be configured to allow connections only from the backend server (this can be more strict by configuring the RDS itself to allow connections only if they were identified by a certificate that exists only on the backend server) and an alert should be defined in Coralogix based on CloudTrail logs that would fire if the security group is modified.

Also, by forwarding the database logs from the RDS instance, an alert should be defined in Coralogix so it would be triggered if the database detects connections from other IPs.

Inbound

Since the traffic volume here should be quite low due to the validations done by the proxies and front-end servers, and due to the fact that this is the last point we can tap into the data before it is saved into the DB we recommend that you mirror all incoming traffic from this server

DNS server

Since this server generates a very minimal amount of traffic that is so extremely valuable for detecting so many types of attacks we recommend that you mirror all traffic in and out of this server.

Package cache server

Since this server is responsible for packages installations on all other servers, the data from and to this server can answer questions like who installed what when, which can be crucial in a forensic investigation and for detecting installation of malicious tools on the server. Also, the traffic volume from and to this server is expected to be quite low. Therefore, we recommend that you mirror all traffic in and out of this server.

Bastion server

Since this server is serving as the only way to manage all other servers, provided that it is being used to update the code on the various servers, install required packages, etc., the traffic volume should be relatively low and the value of the data it can provide is extremely high and therefore we recommend that you mirror all traffic in and out of this server.

Summary

Just like in any other field of security, there is no real right or wrong here, it’s more a matter of whether or not it is worth the trade-off in particular cases. There are several strategies that can be taken to minimize the overall cost of the AWS traffic monitoring solution and still get acceptable results.

For a list of the most commonly used strategies, check out our traffic mirroring tutorial.

You have to capture everything to investigate security issues thoroughly, right? More often than not, data that at one time was labeled irrelevant and thrown away is found to be the missing piece of the puzzle when investigating a malicious attacker or the source of an information leak.

So, you need to capture every network packet. As ideal as this might be, capturing every packet from every workstation and every server in every branch office is usually impractical and too expensive, especially for larger organizations. 

In this post, we’ll look at an example of a fictional bookstore company and the recommended mirroring strategies for that specific scenario. 

For a list of the most commonly used strategies, check out our traffic mirroring tutorial.

MyBookStore Company

This example represents a simple book store. The frontend servers hold the code for handling customers’ requests for searching and purchasing books, all the system’s data is stored in the database servers. Currently, the throughput to the website is not extremely high but is expected to grow significantly in the upcoming months due to the new year’s sales.

The network diagram above describes a typical network of a SaaS service. It’s a collection of reverse proxies that handle HTTPS encryption and client connections after basic validation, such as URIs paths and sometimes even parameters and HTTP methods. They  then send the HTTP requests as HTTP to the frontend servers, making requests to their backend servers that process the data and update or query the DB servers and return the requested result.

Security groups and public IP configuration

The following table represents the network security measures indicated by the allowed connections in and out of each server shown on the diagram.

Rev Proxy

(With public IP)

Frontend

(No public IP)

Backend

(No public IP)

DB

(No public IP)

DNS

(No public IP)

Packages Cache

(No public IP)

Bastion

(With public IP)

In this setup, the only servers that are exposed to the Internet and expected to be reachable by other servers on the Internet are the proxy servers and the bastion server. All other servers do not have a public IP address assigned to them. 

All DNS queries are expected to be sent to the local DNS server, resolving them against other DNS servers on the Internet.

Package installations and updates for all the servers on this network are expected to be handled against the local packages caching server. So all other servers will not need to access the Internet at all except for time synchronization against public NTP servers.

SSH connections to the servers are expected to happen only via the bastion server and not directly from the Internet.

In this scenario, we would recommend using the following mirroring configuration by server type.

Reverse Proxies

Since these servers are contacted by users from the Internet over a TLS encrypted connection, most of the traffic to it should be on port 443 (HTTPS) and its value to traffic rate ratio is expected to be quite low, we would recommend the following mirror filter configuration:

Outbound

* Note – Although this rule will also mirror the server’s encrypted responses to the HTTPS requests we do recommend that you mirror it since it might also contain HTTPS connections initiated by malware running on the proxy servers to command and control servers and especially since the traffic volume of the server’s responses is not expected to be extremely high.

Inbound

Frontend servers

Since the frontend servers receive the unencrypted traffic they are essentially the first place on the network in which we can detect attacks against the system and therefore their traffic data is very valuable from an information security perspective. 

This is why we believe that you would mirror any traffic from and to these servers. This will, of course, include the valid traffic by the customers. Although this can be extremely valuable for creating a good baseline that can later be used to detect anomalies, it can also be rather expensive for the organization. 

For such cases we would recommend the following mirroring configuration for detecting abnormal behavior of the frontend servers that can indicate a cyberattack that is currently in progress:

Outbound

* Note – Although this rule will also mirror the server’s responses to the HTTPS requests, we do recommend that you mirror it since it might also contain HTTPS connections initiated by malware running on the proxy servers to command and control servers. Also, this might include unintended responses that will indicate that an attack (such as XSS or SQL Injection) took place.

Inbound

Backend servers

Since the frontend servers are contacting these servers with requests that are supposed to be valid after the checks done by the proxy and frontend servers, the traffic volume is expected to be significantly lower than traffic volume to the proxy and frontend servers.

Also, since this is the last chance to detect malicious traffic before it reaches the database, we believe that all traffic from these servers should be mirrored. However, if this is still too expensive for your organization, we would recommend that you use the following mirroring configuration to at least be able to tell if a backend server is behaving abnormally, which may indicate that it has already been breached:

Outbound

* Note – Although this rule will also mirror the server’s responses to frontend requests we do recommend that you mirror it since it might also contain HTTPS connections initiated by malware running on the proxy servers to command and control servers. Also, this might include unintended responses that will indicate that an attack (such as XSS or SQL Injection) took place.

Inbound

Databases

Since this server is at the heart of the customer’s system, we recommend that you would mirror all traffic in and out of this server.

DNS server

Since this server generates a very minimal amount of traffic that is so extremely valuable for detecting so many types of attacks we recommend that you would mirror all traffic in and out of this server.

Package cache server

Since this server is responsible for packages installations on all other servers, the data from and to this server can answer questions like who installed what and when which can be crucial in a forensic investigation and for detecting installation of malicious tools on the server. Also, the traffic volume from and to this server is expected to be quite low. Therefore, we recommend that you would mirror all traffic in and out of this server.

Bastion server

Since this server is serving as the only way to manage all other servers, provided that it is being used to update the code on the various servers, install required packages, etc., the traffic volume should be relatively low and the value of the data it can provide is extremely high and therefore we recommend that you would mirror all traffic in and out of this server.

Summary

Just like in any other field of security, there is no real right or wrong here, it’s more a matter of whether or not it is worth the trade-off in particular cases. There are several strategies that can be taken to minimize the overall cost of the AWS traffic monitoring solution and still get acceptable results.

For a list of the most commonly used strategies, check out our traffic mirroring tutorial.

Security is one of the most changeable landscapes in technology at the moment. With innovations, come new threats, and it seems like every week brings news of a major organization succumbing to a cyber attack. We’re seeing innovations like AI-driven threat detection and zero-trust networking continuing to be a huge area of investment. However, security should never be treated as a single plane. 

Here at Coralogix, we’re firm believers that observability is the backbone of good security practice. That’s why, in this piece, we’re going to examine what’s in the arsenal when it comes to protecting your platforms at their core: the application level. 

The cybersecurity picture today

Trends in cyber security seem to revolve around two key facets: detection and recovery. Detection, because stopping an attack before it happens is less costly than recovery. Recovery, because there is a certain inevitability associated with cyber-attacks and organizations want to be best prepared for such an eventuality. GDPR logging and monitoring and NIS require disclosure from an organization hit by a cyberattack within 72 hours, so it’s easy to see companies are today focussing on these pillars. 

In terms of attack style, three main types dominate a CISO’s headspace in 2021. These are (in no particular order), supply-chain attacks, insider threats, and ransomware. 

Code-layer security for your application 

It’s fair to say that applications need safe and secure code to run without the threat of compromising other interdependent systems. The SolarWinds cyber attack is a great example of when compromised code had a devastating knock-on effect. Below, we’ll explore how you can boost your security at a code level.

Maintain a repository

Many companies will employ a trusted code repository to ensure that they aren’t shipping any vulnerabilities. You can supercharge the use of a repository by implementing GitOps as a methodology. Not only does this give you ship and roll-back code quickly, but with the Coralogix Kubernetes Operator, you can keep track of these deployments with your observability platform. 

Write secure code

This seems like an obvious suggestion, but it shouldn’t be overlooked. Vulnerabilities in Java code occupy the top spots in the OWASP top 10, so ensure your engineers are well versed in shortcomings around SSL/TLS libraries. While there are tools available which scan your code for the best-known vulnerabilities, they’re no substitute for on-the-ground knowledge. 

Monitor your code

Lack of proper monitoring, alerting, and logging is cited as a key catalyst of application-level security problems. Fortunately, Coralogix has a wide range of integrations for the most popular programming languages so that you can monitor key security events at a code level.

Cloud service security for your application

Public cloud provides a range of benefits that organizations look to capitalize on. However, the public cloud arena brings its own additional set of application security considerations.

Serverless monitoring

In a 2019 survey, 40% of respondents indicated that they had adopted a serverless architecture. Function as a Service (FaaS) applications have certainly brought huge benefits for organizations, but also bring a new set of challenges. On AWS, the FaaS offerings are Lambda and S3 (which is stateful backend storage for Lambda). The Internet is littered with examples of security incidents directly related to S3 security problems, most famously Capital One’s insider threat fiasco. This is where tools like Coralogix’s Cloudwatch integration can be useful, allowing you to monitor changes in roles and permissions in your Coralogix dashboard. Coralogix also offers direct integration with AWS via its Serverless Application Repository, for all your serverless security monitoring needs. 

Edge computing

Edge computing is one of the newer benefits realized by cloud computing. It greatly reduces the amount of data in flight, which is good for security. However, it also relies on a network of endpoint devices for processing. There are numerous considerations for security logging and monitoring when it comes to IoT or edge computing. A big problem with monitoring these environments is the sheer amount of data generated and how to manage it. Using an AI-powered tool, like Loggregation, to help you keep on top of logging outputs is a great way of streamlining your security monitoring.

Container security for your application 

If you have a containerized environment, then you’re probably aware of the complexity of managing its security. While there are numerous general containerized environment security considerations, we’re going to examine the one most relevant to application-level security.

Runtime Security

Runtime security for containers refers to the security approach for when the container is deployed. Successful container runtime security is heavily reliant on an effective container monitoring and observability strategy. 

Runtime security is also about examining internal network traffic, instead of just relying on traditional firewalling. You also have to monitor the orchestration platforms (for example Kubernetes or Istio) to make sure you don’t have vulnerabilities there. Coralogix provides lots of different Kubernetes integrations, including Helm charts, to give you that vital level of granular observability.

What’s the big deal?

With many organizations being increasingly troubled by cyberattacks, it’s important to make sure that security focus isn’t just on the outer layer, for example, firewalls. In this article, we’ve highlighted steps you can take to effectively monitor your applications and their components to increase your system security, from the inside out. 

What’s the biggest takeaway from this, then? Well, you can monitor your code security, cloud services, and container runtime. But don’t ever do it in isolation. Coralogix gives you the ability to overlay and contextualize this data with other helpful metrics, like firewalls, to keep your vital applications secure and healthy. 

With the exponential rise in cybercrimes in the last decade, cybersecurity for businesses is no longer an option — it’s a necessity. Fuelled by the forced shift to remote working due to the pandemic, US businesses saw an alarming 50% rise in reported cyber attacks per week from 2020 to 2021. Many companies still use outdated technologies, unclear policies, and understaffed cybersecurity teams to target digital attacks.

So, if you’re a business looking to upgrade its cybersecurity measures, here are five powerful tools that can protect your business from breaches.

1. Access protection

Designed to monitor outgoing and incoming network traffic, firewalls are the first layer of defense from unauthorized access in private networks. They are easy to implement, adopt, and configure based on security parameters set by the organization.

Among the different types of firewalls, one of the popular choices among businesses is a next-generation firewall. A next-generation firewall can help protect your network from threats through integrated intrusion prevention, cloud security, and application control. A proxy firewall can work well for companies looking for a budget option.

Even though firewalls block a significant portion of malicious traffic, expecting a firewall to suffice as a security solution would be a mistake. Advanced attackers can build attacks that can bypass even the most complex firewalls, and your organization’s defenses should catch up to these sophisticated attacks. Thus, instead of relying on the functionality of a single firewall, your business needs to adopt a multi-layer defense system. And one of the first vulnerabilities you should address is having unsecured endpoints.

2. Endpoint protection

Endpoint Protection essentially refers to securing devices that connect to a company’s private network beyond the corporate firewall. Typically, these range from laptops, mobile phones, and USB drives to printers and servers. Without a proper endpoint protection program, the organization stands to lose control over sensitive data if it’s copied to an external device from an unsecured endpoint.

Softwares like antivirus and anti-malware are the essential elements of an endpoint protection program, but the current cybersecurity threats demand much more. Thus, next-generation antiviruses with integrated AI/ML threat detection, threat hunting, and VPNs are essential to your business.

If your organization has shifted to being primarily remote, implementing a protocol like Zero Trust Network Access (ZTNA) can strengthen your cybersecurity measures. Secure firewalls and VPNs, though necessary, can create an attack surface for hackers to exploit since the user is immediately granted complete application access. In contrast, ZTNA isolates application access from network access, giving partial access incrementally and on a need-to-know basis. 

Combining ZTNA with a strong antivirus creates multi-layer access protection that drastically reduces your cyber risk exposure. However, as we discussed earlier, bad network actors who can bypass this security will always be present. Thus, it’s essential to have a robust monitoring system across your applications, which brings us to the next point…

3. Log management & Observability

Log management is a fundamental security control for your applications. Drawing information from event logs can be instrumental to identifying network risks early, mitigating bad actors, and quickly mitigating vulnerabilities during breaches or event reconstruction.

However, many organizations still struggle with deriving valuable insights from log data due to complex, distributed systems, inconsistency in log data, and format differences. In such cases, a log management system like Coralogix can help. It creates a centralized, secure dashboard to make sense of raw log data, clustering millions of similar logs to help you investigate faster. Our AI-driven analysis software can help establish security baselines and alerting systems to identify critical issues and anomalies. 

A strong log monitoring and observability system also protects you from DDoS attacks. A DDoS attack floods the bandwidth and resources of a particular server or application through unauthorized traffic, typically causing a major outage. 

With observability platforms, you can get ahead of this. Coralogix’s native Cloudflare integrations combined with load balancers give you the ability to cross-analyze attack and application metrics and enable your team to mitigate such attacks. Thus, you can effectively build a DDOS warning system to detect attacks early.

Along with logs, another critical business data that you should monitor regularly are emails. With over 36% of data breaches in 2022 attributed to phishing scams, businesses cannot be too careful.

4. Email gateway security

As most companies primarily share sensitive data through email, hacking email gateways is a prime target for cybercriminals. Thus, a top priority should be robust filtering systems to identify spam and phishing emails, embedded code, and fraudulent websites. 

Email gateways act as a firewall for all email communications at the network level — scanning and auto-archiving malicious email content. They also protect against business data loss by monitoring outgoing emails, allowing admins to manage email policies through a central dashboard. Additionally, they help businesses meet compliance by safely securing data and storing copies for legal purposes. 

However, the issue here is that sophisticated attacks can still bypass these security measures, especially if social engineering is involved. One wrong click by an employee can give hackers access to an otherwise robust system. That’s why the most critical security tool of them all is a strong cybersecurity training program.

5. Cybersecurity training

Even though you might think that cybersecurity training is not a ‘tool,’ a company’s security measures are only as strong as the awareness among employees who use them. In 2021, over 85% of data breaches were associated with some level of human error. IBM’s study even found out that the breach would not have occurred if the human element was not present in 19 out of 20 cases that they analyzed.

Cybersecurity starts with the people, not just the tools. Thus, you need to implement a strong security culture about security threats like phishing and social engineering in your organization. All resources related to cybersecurity should be simplified and made mandatory during onboarding. These policies should be further reviewed, updated, and re-taught semi-annually in line with new threats. 

Apart from training, the execution of these policies can mean the difference between a hackable and a secure network. To ensure this, regular workshops and phishing tests should also be conducted to identify potential employee targets. Another way to increase the effectiveness of these training is to send out cybersecurity newsletters every week. 

Some companies like Dell have even adopted a gamified cybersecurity training program to encourage high engagement from employees. The addition of screen locks, multi-factor authentication, and encryption would also help add another layer of security. 

Upgrade your cybersecurity measures today!

Implementing these five cybersecurity tools lays a critical foundation for the security of your business. However, the key here is to understand that, with cyberattacks, it sometimes just takes one point of failure. Therefore, preparing for a breach is just as important as preventing it. Having comprehensive data backups at regular intervals and encryption for susceptible data is crucial. This will ensure your organization is as secure as your customers need it to be —  with or without a breach!