Security-JAWS Report #38 #secjaws #secjaws38 #jawsug

Hello, this is Usuda.

Security JAWS 38th meeting was held, so I'm reporting about it.

Security-JAWS [38th] Study Meeting August 21, 2025 (Thursday) - connpass

Video

https://www.youtube.com/watch?v=IZJM0EKPnHE

Report### Session1: AWS re:Inforce 2025 TDIR reCap Amazon Web Services Japan Technical Division Director, Nozomu Kita

• Today introducing three updates to TDIR planning services
• Amazon GuardDuty's expanded threat detection coverage
  • First, what is extended threat detection
    • In English, it's called Extended Threat Detection
    • Now Amazon GuardDuty can detect signals collectively as attack sequences that were previously detected individually
  • Existing attack sequence detection was only for IAM and S3
  • Now attack sequence detection is also available for EKS clusters
  • A series of suspicious actions executed by potentially compromised Amazon EKS clusters can be detected
  • Detected with Critical severity, requiring prompt response
  • Recommended to configure both EKS protection and Runtime Monitoring EKS addon together
• New AWS Security Hub in preview
  • Separate console from existing AWS Security Hub
  • Can be accessed by clicking "Security Hub Advanced" at the bottom left of the existing screen
  • Existing product has been renamed to AWS Security Hub CSPM
  • Available for free during preview, so please use it extensively
  • What's new?
    • Existing AWS Security Hub CSPM provided CSPM functionality and aggregation of findings
    • The new version enhances aggregation with many additional capabilities
    • Can correlate data, detect exposures, and visualize attack paths
    • Enhanced third-party integration with Jira/ServiceNow ticket management
  • Screen layout differs from the existing version
    • Widget showing Amazon GuardDuty content as threat information
    • Exposure is a new widget
    • Findings for vulnerabilities, sensitive data, etc. are now on separate pages
    • Filter settings can be saved
  • Details about exposures
    • Correlates and visualizes security signals
    • Called "Exposure" in English
    • Can detect potential threats and risks unique to your environment
    • For example, you can see if EC2 instance vulnerabilities detected by Amazon Inspector might connect to other issues
    • Determines priority by integrating information about misconfigurations, vulnerabilities, sensitive data, etc.
    • Useful when using AWS native security features as they can be correlated
  • Visualization of potential attack paths
    • Helps understand and visualize paths where attackers could chain vulnerabilities and misconfigurations to compromise high-priority resources
  • Current usage guidance
    • Continue using existing AWS Security Hub CSPM for CSPM functionality
      • This is the only place with CSPM features
    • Use the new AWS Security Hub for centralized management and visualization functions
• Amazon Inspector code security feature
  • Amazon Inspector is a vulnerability management service
  • Previously supported EC2/ECR/Lambda
  • Now can review code stored in repositories
  • Previously only package vulnerability management was available, requiring separate application vulnerability management, now possible with Amazon Inspector
  • Core features:
    • Static Application Security Testing (SAST)
    • Software Composition Analysis (SCA)
    • Infrastructure as Code (IaC) scanning
  • Supported languages differ for each feature
  • Details in the documentation
  • Findings can be checked the same way as before
    • SAST scan shows specific code issues and suggested fixes
  • Can be integrated with Git Actions
    • Scan results can be added to PRs#### Thoughts

There are a lot of great updates!

I'm going to start taking full advantage of the new AWS Security Hub!

Session2: Introducing Two Level 500 Sessions from AWS re:Inforce at Level 200 Security-JAWS Shun Yoshie

• I wrote it in the title but it might actually be difficult to explain at level 200
• Will gently introduce the two sessions SEC501/SEC504
• What is Level 500?
  • Until now, the highest level of AWS sessions was 400 (Expert)
  • At this re:Inforce, Level 500 "Distinguished" appeared
    • The level description mentions advanced research, theoretical foundations, etc.
  • Advanced sessions that unfold while reading academic papers
• SEC 501 Shor's Algorithm and Post-Quantum Cryptography
  • Feels like attending a linear algebra class
  • Discussed quantum computing and what happens with quantum-resistant cryptography
  • What are quantum computers?
    • Various existing cryptography (RSA/elliptic curve, etc.) could be broken instantly when quantum computing arrives
    • Post-Quantum Cryptography (PQC) is a new type of cryptography that can withstand this
  • NIST has released 3 PQC standards
  • These will become the base going forward
  • AWS is at the stage of figuring out how to use these
  • KMS supports PQC
  • Some parts can be used with Transfer Family
  • What we need to be aware of is knowing how to use PQC in AWS when it becomes necessary
  • AWS doesn't recommend users implement PQC all at once, but rather migrate gradually
  • They mentioned they want to make it clear which services support PQC
• SEC 504 REACT threat detection model
  • Explained by unraveling the REACT framework paper
  • Talked about cloud security threat detection
  • Various threats don't have labels in learning data
  • REACT is a framework that helps label and detect where detection is difficult
  • Actually used in Amazon GuardDuty and Amazon Macie

Thoughts

Level 500 is difficult, but there are things we need to do like PQC support, so I want to prepare for them### Session3: Escaping from Fragmented Operations! We've Consolidated Security Governance with AWS Organization Takahiro Arai, DX Promotion Department, SECOM Trust Systems Co., Ltd.

• Background/Purpose
  • Customer systems we operate have expanded AWS usage with over 100 AWS accounts
  • Some used AWS Organizations while others didn't, resulting in fragmentation
  • Settings and operations were not standardized
• Response Policy
  • Decided to integrate into a single AWS Organizations
  • Challenges
    • Differences in OU structure and account configuration
    • Security setting issues
    • Lack of documentation
• Resolving OU/Account Configuration Issues
  • Configured according to AWS best practices
  • Avoided creating some elements like Policy Statements that weren't planned to be used
  • Consolidated some OUs
  • Organization enabled common settings implementation
• Resolving Security Setting Issues
  • Main focus with extensive content
  • Restricting permissions with SCP
  • Changing login methods
  • Automated remediation with Config
  • Security service notifications
  • Centralizing internet exit points
• Changing Login Methods
  • Pre-integration: Jump accounts and direct logins were common
  • Consolidated into IAM Identity Center
  • Enabled JustInTime login with external IdP (not TEAM)
• Automated Remediation with Config
  • Deployed Config conformance packs via StackSets with OU selection for risky settings
  • Targets include S3.5/EC2.18/EC2.19, etc.
• Security Service Notifications
  • Managed everything in the Audit account
  • AWS Security Hub: configured for one-time detection notifications and summary notifications
  • Amazon GuardDuty and IAM Access Analyzer: immediate notifications with phone calls
  • Weekly summary notifications with Inspector
• Centralizing Internet Exit Points
  • Built in Infrastructure OU using Transit Gateway/Network Firewall
  • Extended existing dedicated line connection to on-premises
  • Implemented whitelist restrictions with Network Firewall
• Documentation Enhancement
  • Defined three patterns
  • AWS Organizations account configuration documentation
    • Made configuration intent clear
  • Account user documentation
    • Security detection response policies, etc.
  • Security operations documentation
    • Response policies dynamically embedded in notification URLs
• Schedule
  • Initially planned for completion in 6 months but delayed by about 3 months due to various adjustments
  • Scrutinized target accounts, ultimately deleting some which reduced costs
  • Migrated each account in approximately 40 minutes
• Migration Precautions
  • Created GuardDuty/Access Analyzer suppression rules in advance to reduce detections
  • Exported Security Hub findings as they might disappear
  • Temporarily suspended notifications during migration
  • Removed Config recorders manually configured for Control Tower registration
  • Pre-configured billing statement settings and phone verification missing from some AWS Organizations accounts
• Challenges Faced
  • Careful coordination with each department including cost aspects
  • Difficult to establish procedures due to various account states
  • Consolidated some policies due to SCP limitations
• Improvements Achieved
  • Enhanced account security
    • Ability to issue new accounts with zero detections
  • Visualization and regular reporting of Security Hub scores
    • Monthly security reports improved user awareness
  • Reduction of IAM users for human access
• Lessons and Future Outlook
  • Creating a new AWS Organizations rather than using existing ones was the right decision
  • Requires cooperation and understanding from all AWS-using departments
  • Consolidation is just the beginning with ongoing improvements planned
  • Want to implement EC2 login using IAM Identity Center information- I want to automatically configure GuardDuty runtime monitoring
  • I want to integrate the network of existing accounts
    • Want to properly manage addresses so they can be consolidated
  • I want to optimize costs

Thoughts

It was a good presentation! The content about transitioning to multi-account management was very informative, so everyone should follow this example!

Session4: [With Examples] Defending APIs for $0 with aws-cdk - Wallarm, Inc. Japan Branch, Mr. Kamimachi

• How do you protect an app when using AI, for example?
• Using AWS WAF for protection is one consideration
• However, WebACL starts at $5/month, and costs increase with more requests
• Most WAFs operate primarily with regex and signatures
  • They can miss detections due to fragmentation
  • Some may ignore payloads exceeding 32KB
• AWS WAF is easy to implement
  • Creating a similar system yourself was difficult
• CDK now ensures distribution and restriction capabilities
  • Everything can be created declaratively
• Trying Wallarm with TypeScript CDK
  • Free tier includes 500,000 requests/month
  • Note that you need to maintain a host
  • Code that fits on a single slide
  • Give it a try

Thoughts

Applying security while keeping costs down is important. Let's make good use of free tiers.

Session5: (Tentative) Security Lake makes security monitoring fun - ken5scal

• Started using Security Lake after realizing it wasn't a SIEM
• Got interested in Apache Iceberg, so will talk about that
• FISC documents mention SIEM
• There are various solutions available
• What SIEM do we really need?
• Limitations on data for analysis:
  • The information collected is limited to begin with
  • Formats are inconsistent and difficult to use
  • Limited data storage capacity
  • High storage costs
  • Difficult if personal information cannot be removed
  • Analysis requires proprietary queries
  • Queries might only work in browsers, not locally
• With effort, it's somewhat manageable
• However, it takes a lot of effort without solving everything
• It's still challenging
• Maybe it's difficult because we're assuming SIEM is needed
• So I changed the configuration:
  • Process logs and put them into an archive
  • Format and organize them
  • Then input to AWS Security Lake
  • Can centralize and manage security logs
  • AWS CloudTrail, GuardDuty, WAF logs are unified into OCSF format
  • Can query with Athena
  • Non-AWS logs are converted to OCSF format manually
  • Using multiple collection methods:
    • API crawling, Webhook, direct storage, manual input
    • Also using AWS AppFabric
    • Detection with Amazon Macie
• Analysis:
  • Analyzing from various sources
  • Using Athena and also DuckDB
  • Easy local verification with any query engine
• Achieved the controllability I wanted
• This is supported by Apache Iceberg
  • Being a standard means any compliant tool can be used
  • Apache Iceberg creates a logical metadata layer for access rather than accessing actual data
  • Catalog and metadata allow flexible responses
  • Actual data is stored in the data layer
  • In Security Lake, it's stored in S3
• Scenario: Protecting customer (investor) funds
  • Can adapt to evolving schemas for specific requirements
  • Auditing is also possible#### Impression

It seems that collecting security logs in AWS Security Lake and organizing them with OCSF would make things easier. However, while it can handle various analysis purposes, it doesn't mean it's natively easy to use out of the box. You'll need to do various things to master it, so consider your use cases carefully.

Session6: Introducing the AWS Security Hub Survey Report Security-JAWS Keiuke Usuda

Please wait a little longer for the report release ★ミ

[Cloud Zoom Consultation] Slot to answer questions received on the day's slido & connpass

No consultations this time! Everyone please feel free to ask lots of questions.

Summary

We gained a lot of knowledge this time as well! Please wait a little longer for the survey report ★ミ