Query Comms: Jan 20 - Jan 24
Query + AWS Dev Day 2025
Secure your spot on February 4th at 8:30AM at the AWS New York City Office for a hands-on workshop using Query Federated Search with Amazon Security Lake.
Attendees will:
Sign up to attend from the link below!
Using the Query Federated Search for Splunk App
Query extends the reach of your Splunk instance to data sources outside of Splunk.
No need for centralization, normalization, or ingest.
Check out this short demo:
领英推荐
Amazon Redshift Integrated Into Query Federated Search
?? Detection Engineer: Hey, remember when we had to investigate all of those weird logins from the Seychelles from Big Rocket Co. a few weeks ago?
?? SOC Analyst #1: Yeah, good thing we got the Google Workspace Connectors configured in Query. Also, those pivot tables you set up in the data lake with the Data and Analytics team were very cool.
?? Detection Engineer: I think I found an even better way to get the data we need. I started using Amazon Redshift, it’s a data warehouse on AWS, so we can integrate it with our data lake!
?? SOC Analyst #1: Uhh…okay? I mean isn’t a warehouse a bit much? Plus, we have a lot of those floating around now…ClickHouse, Snowflake, Databricks, plus the legacy SIEM…why did you use that?
?? Detection Engineer: It’s true we could use our Amazon Athena and Security Lake Connectors as normal, but I am building materialized views in Redshift to roll up metrics and correlation for our major datasets. Such as our asset inventory data, our CSPM data, some vulnerability tables, and a few others. It’s way quicker than Amazon Athena and we can consolidate our Connectors down as well!
?? SOC Analyst #1: Well, that seems a bit redundant at first glance, but I think I understand. You just copy the data from S3, build the tables in Redshift, then create the Mat View?
?? Detection Engineer: Exactly! I also make sure we have several columns in there that we can link to Entities inside of Query. Take our asset and vulnerability data for instance, I make sure to identify IP addresses, MAC addresses, hostnames, last logged in users, IAM role associations, the resource IDs, AWS Systems Manager info, and more! That way we have the materialized views able to serve up the data in various ways no matter how we search. Not to mention whenever you query by those Entities, you also get vulnerability and configuration data from the MV!
???? SOC Analyst #1: Okay, now I think I understand…is this the part where you tell me we still need to use Amazon Athena?
?? Detection Engineer: No! This is the part where I tell you Query already has a Connector for Amazon Redshift! I got with their TAMs to get their IP ranges and their docs have a section for IAM Role based authentication. That way we have the network and identity layers locked down.
?? SOC Analyst #1: Wow! Alright, during next month's purple team exercise lets make sure the scenarios we run through are able to be satisfied by these new MVs you created. I’d sure love to reduce the complexity of some of our runbooks!
?? SOC Analyst #3: The Magic Conch says your materialized views won’t get us killed in the streets!
??? All SOC: ALL HAIL THE MAGIC CONCH AND LEVEL FOUR PLATES!
This is what you look like still hoarding all your security data in a central location because you "need to." You've got a problem... but it's not your fault.
You've been trained for years that centralization of security data is a necessity. And for a long time, it made sense. Until it didn't.?
With Query, you centralize only what you absolutely must in high cost storage, like the SIEM (hint: it's way less than what you have now) and move everything else into more affordable repositories. Or heck, just leave it where it is.?
Your security operations team can easily search it all. Pivoting from start to finish, question to answer, alert to resolution. Sound better?
Don't be a hoarder.