Mar 21 2024

HACK-PROOF YOUR CLOUD: THE STEP-BY-STEP CONTINUOUS THREAT EXPOSURE MANAGEMENT CTEM STRATEGY FOR AWS & AZURE

Continuous Threat Exposure Management (CTEM) is an evolving cybersecurity practice focused on identifying, assessing, prioritizing, and addressing security weaknesses and vulnerabilities in an organization’s digital assets and networks continuously. Unlike traditional approaches that might assess threats periodically, CTEM emphasizes a proactive, ongoing process of evaluation and mitigation to adapt to the rapidly changing threat landscape. Here’s a closer look at its key components:

  1. Identification: CTEM starts with the continuous identification of all digital assets within an organization’s environment, including on-premises systems, cloud services, and remote endpoints. It involves understanding what assets exist, where they are located, and their importance to the organization.
  2. Assessment: Regular and ongoing assessments of these assets are conducted to identify vulnerabilities, misconfigurations, and other security weaknesses. This process often utilizes automated scanning tools and threat intelligence to detect issues that could be exploited by attackers.
  3. Prioritization: Not all vulnerabilities pose the same level of risk. CTEM involves prioritizing these weaknesses based on their severity, the value of the affected assets, and the potential impact of an exploit. This helps organizations focus their efforts on the most critical issues first.
  4. Mitigation and Remediation: Once vulnerabilities are identified and prioritized, CTEM focuses on mitigating or remedying these issues. This can involve applying patches, changing configurations, or implementing other security measures to reduce the risk of exploitation.
  5. Continuous Improvement: CTEM is a cyclical process that feeds back into itself. The effectiveness of mitigation efforts is assessed, and the approach is refined over time to improve security posture continuously.

The goal of CTEM is to reduce the “attack surface” of an organization—minimizing the number of vulnerabilities that could be exploited by attackers and thereby reducing the organization’s overall risk. By continuously managing and reducing exposure to threats, organizations can better protect against breaches and cyber attacks.

CTEM VS. ALTERNATIVE APPROACHES

Continuous Threat Exposure Management (CTEM) represents a proactive and ongoing approach to managing cybersecurity risks, distinguishing itself from traditional, more reactive security practices. Understanding the differences between CTEM and alternative approaches can help organizations choose the best strategy for their specific needs and threat landscapes. Let’s compare CTEM with some of these alternative approaches:

1. CTEM VS. PERIODIC SECURITY ASSESSMENTS

  • Periodic Security Assessments typically involve scheduled audits or evaluations of an organization’s security posture at fixed intervals (e.g., quarterly or annually). This approach may fail to catch new vulnerabilities or threats that emerge between assessments, leaving organizations exposed for potentially long periods.
  • CTEM, on the other hand, emphasizes continuous monitoring and assessment of threats and vulnerabilities. It ensures that emerging threats can be identified and addressed in near real-time, greatly reducing the window of exposure.

2. CTEM VS. PENETRATION TESTING

  • Penetration Testing is a targeted approach where security professionals simulate cyber-attacks on a system to identify vulnerabilities. While valuable, penetration tests are typically conducted annually or semi-annually and might not uncover vulnerabilities introduced between tests.
  • CTEM complements penetration testing by continuously scanning for and identifying vulnerabilities, ensuring that new threats are addressed promptly and not just during the next scheduled test.

3. CTEM VS. INCIDENT RESPONSE PLANNING

  • Incident Response Planning focuses on preparing for, detecting, responding to, and recovering from cybersecurity incidents. It’s reactive by nature, kicking into gear after an incident has occurred.
  • CTEM works upstream of incident response by aiming to prevent incidents before they happen through continuous threat and vulnerability management. While incident response is a critical component of a comprehensive cybersecurity strategy, CTEM can reduce the likelihood and impact of incidents occurring in the first place.

4. CTEM VS. TRADITIONAL VULNERABILITY MANAGEMENT

  • Traditional Vulnerability Management involves identifying, classifying, remediating, and mitigating vulnerabilities within software and hardware. While it can be an ongoing process, it often lacks the continuous, real-time monitoring and prioritization framework of CTEM.
  • CTEM enhances traditional vulnerability management by integrating it into a continuous cycle that includes real-time detection, prioritization based on current threat intelligence, and immediate action to mitigate risks.

KEY ADVANTAGES OF CTEM

  • Real-Time Threat Intelligence: CTEM integrates the latest threat intelligence to ensure that the organization’s security measures are always ahead of potential threats.
  • Automation and Integration: By leveraging automation and integrating various security tools, CTEM can streamline the process of threat and vulnerability management, reducing the time from detection to remediation.
  • Risk-Based Prioritization: CTEM prioritizes vulnerabilities based on their potential impact on the organization, ensuring that resources are allocated effectively to address the most critical issues first.

CTEM offers a comprehensive and continuous approach to cybersecurity, focusing on reducing exposure to threats in a dynamic and ever-evolving threat landscape. While alternative approaches each have their place within an organization’s overall security strategy, integrating them with CTEM principles can provide a more resilient and responsive defense mechanism against cyber threats.

CTEM IN AWS

Implementing Continuous Threat Exposure Management (CTEM) within an AWS Cloud environment involves leveraging AWS services and tools, alongside third-party solutions and best practices, to continuously identify, assess, prioritize, and remediate vulnerabilities and threats. Here’s a detailed example of how CTEM can be applied in AWS:

1. IDENTIFICATION OF ASSETS

  • AWS Config: Use AWS Config to continuously monitor and record AWS resource configurations and changes, helping to identify which assets exist in your environment, their configurations, and their interdependencies.
  • AWS Resource Groups: Organize resources by applications, projects, or environments to simplify management and monitoring.

2. ASSESSMENT

  • Amazon Inspector: Automatically assess applications for vulnerabilities or deviations from best practices, especially important for EC2 instances and container-based applications.
  • AWS Security Hub: Aggregates security alerts and findings from various AWS services (like Amazon Inspector, Amazon GuardDuty, and IAM Access Analyzer) and supported third-party solutions to give a comprehensive view of your security and compliance status.

3. PRIORITIZATION

  • AWS Security Hub: Provides a consolidated view of security alerts and findings rated by severity, allowing you to prioritize issues based on their potential impact on your AWS environment.
  • Custom Lambda Functions: Create AWS Lambda functions to automate the analysis and prioritization process, using criteria specific to your organization’s risk tolerance and security posture.

4. MITIGATION AND REMEDIATION

  • AWS Systems Manager Patch Manager: Automate the process of patching managed instances with both security and non-security related updates.
  • CloudFormation Templates: Use AWS CloudFormation to enforce infrastructure configurations that meet your security standards. Quickly redeploy configurations if deviations are detected.
  • Amazon EventBridge and AWS Lambda: Automate responses to security findings. For example, if Security Hub detects a critical vulnerability, EventBridge can trigger a Lambda function to isolate affected instances or apply necessary patches.

5. CONTINUOUS IMPROVEMENT

  • AWS Well-Architected Tool: Regularly review your workloads against AWS best practices to identify areas for improvement.
  • Feedback Loop: Implement a feedback loop using AWS CloudWatch Logs and Amazon Elasticsearch Service to analyze logs and metrics for security insights, which can inform the continuous improvement of your CTEM processes.

IMPLEMENTING CTEM IN AWS: AN EXAMPLE SCENARIO

Imagine you’re managing a web application hosted on AWS. Here’s how CTEM comes to life:

  • Identification: Use AWS Config and Resource Groups to maintain an updated inventory of your EC2 instances, RDS databases, and S3 buckets critical to your application.
  • Assessment: Employ Amazon Inspector to regularly scan your EC2 instances for vulnerabilities and AWS Security Hub to assess your overall security posture across services.
  • Prioritization: Security Hub alerts you to a critical vulnerability in an EC2 instance running your application backend. It’s flagged as high priority due to its access to sensitive data.
  • Mitigation and Remediation: You automatically trigger a Lambda function through EventBridge based on the Security Hub finding, which isolates the affected EC2 instance and initiates a patching process via Systems Manager Patch Manager.
  • Continuous Improvement: Post-incident, you use the AWS Well-Architected Tool to evaluate your architecture. Insights gained lead to the implementation of stricter IAM policies and enhanced monitoring with CloudWatch and Elasticsearch for anomaly detection.

This cycle of identifying, assessing, prioritizing, mitigating, and continuously improving forms the core of CTEM in AWS, helping to ensure that your cloud environment remains secure against evolving threats.

CTEM IN AZURE

Implementing Continuous Threat Exposure Management (CTEM) in Azure involves utilizing a range of Azure services and features designed to continuously identify, assess, prioritize, and mitigate security risks. Below is a step-by-step example illustrating how an organization can apply CTEM principles within the Azure cloud environment:

STEP 1: ASSET IDENTIFICATION AND MANAGEMENT

  • Azure Resource Graph: Use Azure Resource Graph to query and visualize all resources across your Azure environment. This is crucial for understanding what assets you have, their configurations, and their interrelationships.
  • Azure Tags: Implement tagging strategies to categorize resources based on sensitivity, department, or environment. This aids in the prioritization process later on.

STEP 2: CONTINUOUS VULNERABILITY ASSESSMENT

  • Azure Security Center: Enable Azure Security Center (ASC) at the Standard tier to conduct continuous security assessments across your Azure resources. ASC provides security recommendations and assesses your resources for vulnerabilities and misconfigurations.
  • Azure Defender: Integrated into Azure Security Center, Azure Defender provides advanced threat protection for workloads running in Azure, including virtual machines, databases, and containers.

STEP 3: PRIORITIZATION OF RISKS

  • ASC Secure Score: Use the Secure Score in Azure Security Center as a metric to prioritize security recommendations based on their potential impact on your environment’s security posture.
  • Custom Logic with Azure Logic Apps: Develop custom workflows using Azure Logic Apps to prioritize alerts based on your organization’s specific criteria, such as asset sensitivity or compliance requirements.

STEP 4: AUTOMATED REMEDIATION

  • Azure Automation: Employ Azure Automation to run remediation scripts or configurations management across your Azure VMs and services. This can be used to automatically apply patches, update configurations, or manage access controls in response to identified vulnerabilities.
  • Azure Logic Apps: Trigger automated workflows in response to security alerts. For example, if Azure Security Center identifies an unprotected data storage, an Azure Logic App can automatically initiate a workflow to apply the necessary encryption settings.

STEP 5: CONTINUOUS MONITORING AND INCIDENT RESPONSE

  • Azure Monitor: Utilize Azure Monitor to collect, analyze, and act on telemetry data from your Azure resources. This includes logs, metrics, and alerts that can help you detect and respond to threats in real-time.
  • Azure Sentinel: Deploy Azure Sentinel, a cloud-native SIEM service, for a more comprehensive security information and event management solution. Sentinel can collect data across all users, devices, applications, and infrastructure, both on-premises and in multiple clouds.

STEP 6: CONTINUOUS IMPROVEMENT AND COMPLIANCE

  • Azure Policy: Implement Azure Policy to enforce organizational standards and to assess compliance at scale. Continuous evaluation of your configurations against these policies ensures compliance and guides ongoing improvement.
  • Feedback Loops: Establish feedback loops using the insights gained from Azure Monitor, Azure Security Center, and Azure Sentinel to refine and improve your security posture continuously.

EXAMPLE SCENARIO: SECURING A WEB APPLICATION IN AZURE

Let’s say you’re managing a web application hosted in Azure, utilizing Azure App Service for the web front end, Azure SQL Database for data storage, and Azure Blob Storage for unstructured data.

  • Identification: You catalog all resources related to the web application using Azure Resource Graph and apply tags based on sensitivity and function.
  • Assessment: Azure Security Center continuously assesses these resources for vulnerabilities, such as misconfigurations or outdated software.
  • Prioritization: Based on the Secure Score and custom logic in Azure Logic Apps, you prioritize a detected SQL injection vulnerability in Azure SQL Database as critical.
  • Mitigation: Azure Automation is triggered to isolate the affected database and apply a patch. Concurrently, Azure Logic Apps notifies the security team and logs the incident for review.
  • Monitoring: Azure Monitor and Azure Sentinel provide ongoing surveillance, detecting any unusual access patterns or potential breaches.
  • Improvement: Insights from the incident lead to a review and enhancement of the application’s code and a reinforcement of security policies through Azure Policy to prevent similar vulnerabilities in the future.

By following these steps and utilizing Azure’s comprehensive suite of security tools, organizations can implement an effective CTEM strategy that continuously protects against evolving cyber threats.

IMPLEMENTING CTEM IN CLOUD ENVIRONMENTS LIKE AWS AND AZURE

Implementing Continuous Threat Exposure Management (CTEM) in cloud environments like AWS and Azure involves a series of strategic steps, leveraging each platform’s unique tools and services. The approach combines best practices for security and compliance management, automation, and continuous monitoring. Here’s a guide to get started with CTEM in both AWS and Azure:

COMMON STEPS FOR BOTH AWS AND AZURE

  1. Understand Your Environment
    • Catalogue your cloud resources and services.
    • Understand the data flow and dependencies between your cloud assets.
  2. Define Your Security Policies and Objectives
    • Establish what your security baseline looks like.
    • Define key compliance requirements and security objectives.
  3. Integrate Continuous Monitoring Tools
    • Leverage cloud-native tools for threat detection, vulnerability assessment, and compliance monitoring.
    • Integrate third-party security tools if necessary for enhanced capabilities.
  4. Automate Security Responses
    • Implement automated responses to common threats and vulnerabilities.
    • Use cloud services to automate patch management and configuration adjustments.
  5. Continuously Assess and Refine
    • Regularly review security policies and controls.
    • Adjust based on new threats, technological advancements, and changes in the business environment.

IMPLEMENTING CTEM IN AWS

  1. Enable AWS Security Services
    • Utilize AWS Security Hub for a comprehensive view of your security state and to centralize and prioritize security alerts.
    • Use Amazon Inspector for automated security assessments to help find vulnerabilities or deviations from best practices.
    • Implement AWS Config to continuously monitor and record AWS resource configurations.
  2. Automate Response with AWS Lambda
    • Use AWS Lambda to automate responses to security findings, such as isolating compromised instances or automatically patching vulnerabilities.
  3. Leverage Amazon CloudWatch
    • Employ CloudWatch for monitoring and alerting based on specific metrics or logs that indicate potential security threats.

IMPLEMENTING CTEM IN AZURE

  1. Utilize Azure Security Tools
    • Activate Azure Security Center for continuous assessment and security recommendations. Use its advanced threat protection features to detect and mitigate threats.
    • Implement Azure Sentinel for SIEM (Security Information and Event Management) capabilities, integrating it with other Azure services for a comprehensive security analysis and threat detection.
  2. Automate with Azure Logic Apps
    • Use Azure Logic Apps to automate responses to security alerts, such as sending notifications or triggering remediation processes.
  3. Monitor with Azure Monitor
    • Leverage Azure Monitor to collect, analyze, and act on telemetry data from your Azure and on-premises environments, helping you detect and respond to threats in real-time.

BEST PRACTICES FOR BOTH ENVIRONMENTS

  • Continuous Compliance: Use policy-as-code to enforce and automate compliance standards across your cloud environments.
  • Identity and Access Management (IAM): Implement strict IAM policies to ensure least privilege access and utilize multi-factor authentication (MFA) for enhanced security.
  • Encrypt Data: Ensure data at rest and in transit is encrypted using the cloud providers’ encryption capabilities.
  • Educate Your Team: Regularly train your team on the latest cloud security best practices and the specific tools and services you are using.

Implementing CTEM in AWS and Azure requires a deep understanding of each cloud environment’s unique features and capabilities. By leveraging the right mix of tools and services, organizations can create a robust security posture that continuously identifies, assesses, and mitigates threats.

AWS Security

Azure Security

InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory

Tags: AWS, AWS security, Azure, Azure Security, cloud security


Sep 13 2023

Understanding DDoS simulation testing in AWS

Category: DDoSdisc7 @ 9:04 am

https://aws.amazon.com/blogs/security/understanding-ddos-simulation-testing-at-aws/

Distributed denial of service (DDoS) events occur when a threat actor sends traffic floods from multiple sources to disrupt the availability of a targeted application. DDoS simulation testing uses a controlled DDoS event to allow the owner of an application to assess the application’s resilience and practice event response. DDoS simulation testing is permitted on Amazon Web Services (AWS), subject to Testing policy terms and conditions. In this blog post, we help you understand when it’s appropriate to perform a DDoS simulation test on an application running on AWS, and what options you have for running the test.

DDoS protection at AWS

Security is the top priority at AWS. AWS services include basic DDoS protection as a standard feature to help protect customers from the most common and frequently occurring infrastructure (layer 3 and 4) DDoS events, such as SYN/UDP floods, reflection attacks, and others. While this protection is designed to protect the availability of AWS infrastructure, your application might require more nuanced protections that consider your traffic patterns and integrate with your internal reporting and incident response processes. If you need more nuanced protection, then you should consider subscribing to AWS Shield Advanced in addition to the native resiliency offered by the AWS services you use.

AWS Shield Advanced is a managed service that helps you protect your application against external threats, like DDoS events, volumetric bots, and vulnerability exploitation attempts. When you subscribe to Shield Advanced and add protection to your resources, Shield Advanced provides expanded DDoS event protection for those resources. With advanced protections enabled on your resources, you get tailored detection based on the traffic patterns of your application, assistance with protecting against Layer 7 DDoS events, access to 24Ă—7 specialized support from the Shield Response Team (SRT), access to centralized management of security policies through AWS Firewall Manager, and cost protections to help safeguard against scaling charges resulting from DDoS-related usage spikes. You can also configure AWS WAF (a web application firewall) to integrate with Shield Advanced to create custom layer 7 firewall rules and enable automatic application layer DDoS mitigation.

Acceptable DDoS simulation use cases on AWS

AWS is constantly learning and innovating by delivering new DDoS protection capabilities, which are explained in the DDoS Best Practices whitepaper. This whitepaper provides an overview of DDoS events and the choices that you can make when building on AWS to help you architect your application to absorb or mitigate volumetric events. If your application is architected according to our best practices, then a DDoS simulation test might not be necessary, because these architectures have been through rigorous internal AWS testing and verified as best practices for customers to use.

Using DDoS simulations to explore the limits of AWS infrastructure isn’t a good use case for these tests. Similarly, validating if AWS is effectively protecting its side of the shared responsibility model isn’t a good test motive. Further, using AWS resources as a source to simulate a DDoS attack on other AWS resources isn’t encouraged. Load tests are performed to gain reliable information on application performance under stress and these are different from DDoS tests. For more information, see the Amazon Elastic Compute Cloud (Amazon EC2) testing policy and penetration testing. Application owners, who have a security compliance requirement from a regulator or who want to test the effectiveness of their DDoS mitigation strategies, typically run DDoS simulation tests.

DDoS simulation tests at AWS

AWS offers two options for running DDoS simulation tests. They are:

  • A simulated DDoS attack in production traffic with an authorized pre-approved AWS Partner.
  • A synthetic simulated DDoS attack with the SRT, also referred to as a firedrill.

The motivation for DDoS testing varies from application to application and these engagements don’t offer the same value to all customers. Establishing clear motives for the test can help you choose the right option. If you want to test your incident response strategy, we recommend scheduling a firedrill with our SRT. If you want to test the Shield Advanced features or test application resiliency, we recommend that you work with an AWS approved partner.

DDoS simulation testing with an AWS Partner

AWS DDoS test partners are authorized to conduct DDoS simulation tests on customers’ behalf without prior approval from AWS. Customers can currently contact the following partners to set up these paid engagements:

Before contacting the partners, customers must agree to the terms and conditions for DDoS simulation tests. The application must be well-architected prior to DDoS simulation testing as described in AWS DDoS Best Practices whitepaper. AWS DDoS test partners that want to perform DDoS simulation tests that don’t comply with the technical restrictions set forth in our public DDoS testing policy, or other DDoS test vendors that aren’t approved, can request approval to perform DDoS simulation tests by submitting the DDoS Simulation Testing form at least 14 days before the proposed test date. For questions, please send an email to aws-ddos-testing@amazon.com.

After choosing a test partner, customers go through various phases of testing. Typically, the first phase involves a discovery discussion, where the customer defines clear goals, assembles technical details, and defines the test schedule with the partner. In the next phase, partners run multiple simulations based on agreed attack vectors, duration, diversity of the attack vectors, and other factors. These tests are usually carried out by slowly ramping up traffic levels from low levels to desired high levels with an ability for an emergency stop. The final stage involves reporting, discussing observed gaps, identifying actionable tasks, and driving those tasks to completion.

These engagements are typically long-term, paid contracts that are planned over months and carried out over weeks, with results analyzed over time. These tests and reports are beneficial to customers who need to evaluate detection and mitigation capabilities on a large scale. If you’re an application owner and want to evaluate the DDoS resiliency of your application, practice event response with real traffic, or have a DDoS compliance or regulation requirement, we recommend this type of engagement. These tests aren’t recommended if you want to learn the volumetric breaking points of the AWS network or understand when AWS starts to throttle requests. AWS services are designed to scale, and when certain dynamic volume thresholds are exceeded, AWS detection systems will be invoked to block traffic. Lastly, it’s critical to distinguish between these tests and stress tests, in which meaningful packets are sent to the application to assess its behavior.

DDoS firedrill testing with the Shield Response Team

Shield Advanced service offers additional assistance through the SRT, this team can also help with testing incident response workflows. Customers can contact the SRT and request firedrill testing. Firedrill testing is a type of synthetic test that doesn’t generate real volumetric traffic but does post a shield event to the requesting customer’s account.

These tests are available for customers who are already on-boarded to Shield Advanced and want to test their Amazon CloudWatch alarms by invoking a DDoSDetected metric, or test their proactive engagement setup or their custom incident response strategy. Because this event isn’t based on real traffic, the customer won’t see traffic generated on their account or see logs that drive helpful reports.

These tests are intended to generate associated Shield Advanced metrics and post a DDoS event for a customer resource. For example, SRT can post a 14 Gbps UDP mock attack on a protected resource for about 15 minutes and customers can test their response capability during such an event.

Note: Not all attack vectors and AWS resource types are supported for a firedrill. Shield Advanced onboarded customers can contact AWS Support teams to request assistance with running a firedrill or understand more about them.

Conclusion

DDoS simulations and incident response testing on AWS through the SRT or an AWS Partner are useful in improving application security controls, identifying Shield Advanced misconfigurations, optimizing existing detection systems, and improving incident readiness. The goal of these engagements is to help you build a DDoS resilient architecture to protect your application’s availability. However, these engagements don’t offer the same value to all customers. Most customers can obtain similar benefits by following AWS Best Practices for DDoS Resiliency. AWS recommends architecting your application according to DDoS best practices and fine tuning AWS Shield Advanced out-of-the-box offerings to your application needs to improve security posture.

DDoS Protection Second Edition

The 2023-2028 World Outlook for DDoS Protection and Mitigation

InfoSec tools | InfoSec services | InfoSec books | Follow our blog | DISC llc is listed on The vCISO Directory

Tags: AWS, DDoS Protection, DDoS simulation testing


Aug 11 2022

AWS and Splunk partner for faster cyberattack response

Category: Cyber Attack,Information SecurityDISC @ 2:44 pm

OCSF initiative will give enterprise security teams an open standard for moving and analyzing threat data

BLACK HAT AWS and Splunk are leading an initiative aimed at creating an open standard for ingesting and analyzing data, enabling enterprise security teams to more quickly respond to cyberthreats.

Seventeen security and tech companies at the Black Hat USA 2022 show this week unveiled the Open Cybersecurity Schema Framework (OCSF) project, which will use the ICD Schema developed by Symantec as the foundation for the vendor-agnostic standard.

The creation of the OCSF, licensed under the Apache License 2.0, comes as organizations are seeing their attack surfaces rapidly expand as their IT environments become increasingly decentralized, stretching from core datacenters out to the cloud and the edge. Parallel with this, the number and complexity of the cyberthreats they face is growing quickly.

“Today’s security leaders face an agile, determined and diverse set of threat actors,” officials with cybersecurity vendor Trend Micro, one of the initial members of OCSF, wrote in a blog post. “From emboldened nation state hackers to ransomware-as-a-service (RaaS) affiliates, adversaries are sharing tactics, techniques and procedures (TTPs) on an unprecedented scale – and it shows.”

Trend Micro blocked more than 94 billion threats in 2021, a 42 percent year-on-year increase, and 43 percent of organizations responding to a survey from the vendor said their digital attack surface is getting out of control.

Cybersecurity vendors have responded by creating platforms that combine attack surface management, threat prevention, and detection and response to make it easier and faster for enterprises to counter attacks. They streamline processes, close security gaps, and reduce costs, but they’re still based on vendor-specific products and point offerings.

Vendors may use different data formats in their products, which means moving datasets from one vendor’s product to that of another often requires the time-consuming task of changing the format of the data.

“Unfortunately, normalizing and unifying data from across these disparate tools takes time and money,” Trend Micro said. “It slows down threat response and ties up analysts who should be working on higher value tasks. Yet up until now it has simply become an accepted cost of cybersecurity. Imagine how much extra value could be created if we found an industry-wide way to release teams from this operational burden?”

Dan Schofield, program manager for technology partnerships at IBM Security, another OCSF member, wrote that the lack of open industry standards for logging and event purposes creates challenges when it comes to detection engineering, threat hunting, and analytics, and until now, there has been no critical mass of vendors willing to address the issue.

Source: AWS and Splunk partner for faster cyberattack response

Tags: AWS, Splunk


May 19 2019

AWS Security Profiles: Tracy Pierce, Senior Consultant, Security Specialty, Remote Consulting Services | Amazon Web Services

Category: AWS SecurityDISC @ 1:00 pm

In the weeks leading up to re:Inforce, we’ll share conversations we’ve had with people at AWS who will be presenting at the event so you can learn more about them and some of the interesting work that they’re doing. You’ve worn a lot of hats at AWS. What do you do in your current role, […]

Source: AWS Security Profiles: Tracy Pierce, Senior Consultant, Security Specialty, Remote Consulting Services | Amazon Web Services


 Subscribe in a reader




Tags: AWS, AWS security