[HN Gopher] Stay ahead of cyber threats with graph databases
       ___________________________________________________________________
        
       Stay ahead of cyber threats with graph databases
        
       Author : taubek
       Score  : 28 points
       Date   : 2023-01-20 14:48 UTC (8 hours ago)
        
 (HTM) web link (memgraph.com)
 (TXT) w3m dump (memgraph.com)
        
       | dmichulke wrote:
       | If - in the event of a cyber attack - you are concerned with the
       | run-time of your visual display tool for tracing back the source
       | of the attack, then this article is for you.
        
         | mbuda wrote:
         | I guess the question which part of cyber attach data you can
         | visualize and how?
        
         | badrabbit wrote:
         | I am not aware of any incident reponse methodology or technique
         | that would involve anything more than tabular data. Even things
         | like maltego, very cool but haven't seen them used in IR just
         | by intel people to organize stuff for themselves.
        
           | insanitybit wrote:
           | A core component of IR is pivoting - going from "I have this
           | info" to "that lets me grab some other info". Graphs are
           | really good at pivoting.
        
             | badrabbit wrote:
             | So are pivot tables in excel. If you show me a tool that
             | can handle csvs (and excel is crap at huge csvs,
             | timelineexlporer is great) and nice graph UI, I am all for
             | it. The number one priority is not missing stuff so there
             | is no way around having to collect all the right data,
             | eliminate known noise and sift through the data to piece
             | together a timeline.
        
         | honkler wrote:
         | I've noticed that majority of people working in "cyber
         | security" are made of management material. Even those working
         | on technical side of things. I've seen them spend all day on
         | Twitter. You have to wonder if they ever get time for actually
         | working on their stuff. As opposed to kernel devs, but they are
         | likely assholes more than anyone else so not a fan of them.
        
           | insanitybit wrote:
           | As someone who has spent a career in infosec, I've seen the
           | opposite. Infosec has far more counter culture remaining than
           | software dev (I have worked both roles - currently I'm
           | employed as a Software Engineer).
           | 
           | What infosec has much more of is sales people. There's just a
           | huge market trying to solve a tough problem. So from an
           | outside perspective maybe you see a lot of bullshit but it's
           | a highly technical field. Really, I only learned to be a
           | software dev to up my infosec game, I find infosec to be a
           | far more challenging and interesting field.
        
             | honkler wrote:
             | I know a few full-time infosec professors who spend a ton
             | of time on twitter. You would expect these people to lead
             | path-breaking research in their fields, but all they do is
             | share memes about infosec, and ofcourse a few papers a year
             | written mainly by their grad students.
             | 
             | But maybe they too are salesmen types. Marketing their
             | services to midwit management people on twitter. I include
             | politicians in this too. Hurr durr china is going to defeat
             | us in "cyber space" opens up a lot of business
             | opportunities for government contractors. No one care about
             | compilers, or operating systems the same way.
        
               | insanitybit wrote:
               | IDK maybe my bar is just so low across the board that I
               | don't notice the difference anymore. Devs seem just as
               | bad to me - they don't know shit about compilers or OS
               | either lol
               | 
               | As for Twitter, that has to do with infosec having
               | trouble communicating and a bunch of other stuff. I
               | started to explain and it's not really worth getting
               | into. Twitter was really important to infosec
               | communication.
        
             | rychco wrote:
             | I can agree with this, though I'm presumably (based on the
             | language) earlier into my career. The deeply technical
             | parts & the counter culture found in reversing forums &
             | places like DEFCON are still thriving & always awesome.
             | 
             | However, it's also full of bullshit & marketing that want
             | to convince you that every little technical detail is a
             | vector for a potential cyberattack! You don't want to be
             | the next business suffering from ransomware gangs, do you?
             | Better purchase our advanced endpoint detection powered by
             | AI/"Neural Networks", and don't forget your automated
             | security scanning designed with ChatGPT and quantum
             | encrypted database backups to stop the Chinese/Russian
             | state actors/hackers in their tracks!
        
               | insanitybit wrote:
               | I only mean to say that the counter culture is there
               | _relative_ to software devs. It 's depressing how far
               | from its roots infosec has made it. BlackHat is a great
               | example - it's a fed conference.
               | 
               | In terms of the explosion in products, sure. But that
               | doesn't apply to the technical people. There are lots of
               | problems because there's a large market solving a complex
               | problem. If you're actually talking to technical people
               | they can be of a pretty high calibur.
        
               | honkler wrote:
               | This could be because product development is much more
               | quantifiable, while infosec is not. This means the grift
               | can continue for a long time, before an actual ransomware
               | incident happens and the team gets fired. Afterall many
               | of the recent companies that were hacked had contracts
               | with cyber defense firms, but they were just too busy
               | posting memes on social media.
               | 
               | Side note: you should read my other comment on this
               | thread.
        
       | 2OEH8eoCRo0 wrote:
       | I'm a noob here but what is stopping you from displaying or
       | exploring your relational DB in a graph fashion? Why does the
       | underlying database structure matter at this level?
       | 
       | I think this is how Sqrrl works or how they explained it when I
       | was busy bombing interviews.
        
         | pphysch wrote:
         | Hype, mainly
        
         | josipmrden wrote:
         | Nothing is stopping you from displaying it like that. However,
         | if you have a huge dataset, you might experience slow
         | performance and being unfeasible to do your analytics job. If
         | you have a small dataset, you can use whatever you want.
        
         | [deleted]
        
         | nathanwallace wrote:
         | Graph DB == connect the dots. Relational DB == join the dots.
         | :-)
         | 
         | Steampipe [1] is an open source project [2] to live query all
         | your cloud resources with SQL (via Postgres FDWs). It includes
         | a dashboards as code layer written in HCL + SQL. We recently
         | added support for relationship graphs & visualizations with
         | hundreds of open source dashboards focused on cybersecurity
         | [3].
         | 
         | In our experience, the hard part of these graphs was
         | understanding which relationships / vectors are important to
         | highlight and making them simple enough to browse in that way.
         | 
         | 1 - https://steampipe.io 2 -
         | https://github.com/turbot/steampipe 3 -
         | https://steampipe.io/blog/release-0-18-0
        
         | insanitybit wrote:
         | Sqrrl hasn't existed for a long time, but I can tell you that
         | they used a graph database (I don't know if it's public _which_
         | one they used so I won 't go further).
         | 
         | As someone who actually built a graph based SIEM (Grapl) I have
         | opinions here.
         | 
         | Relational databases are fine for graph work. So are non
         | relational databases. What matters more is really how you can
         | model your data and how easy it will be to work with in a
         | "graphy" way, as well as how your system scales by default.
         | 
         | What a graphdb is going to do is get a lot of that "right" out
         | of the box. You'll have a query language/ schema language that
         | makes it easier to express graphs (annoying in SQL imo), that
         | optimizes your edge indexing and join behaviors, that provides
         | graph algorithms and optimizes for them (find a path, etc).
         | 
         | Typical relational databases are not going to be optimized for
         | this work. You're going to need to be very careful about your
         | indexes and queries to ensure that a join doesn't blow things
         | up. You'll just have more work out of the box, and then it's
         | just like... why didn't you use something that exists to solve
         | this?
         | 
         | SIEM scale is much larger than people may expect. You have
         | massive retention (years), billions of events a day, and lots
         | of queries. This makes a lot of problems way harder - like
         | intelligently indexing your edge data.
        
       | yeehawjared wrote:
       | I explored this many years ago:
       | https://experiments.withgoogle.com/visualizing-cyber-threats
       | 
       | The tldr; was that analysts are terrible. Powerful rule engines
       | for the win. Also, accurately capturing and aggregating all the
       | data in large organizations is very hard to do.
        
         | AtlasBarfed wrote:
         | Clearly you simply need an enterprise event bus stack, an
         | enterprise event analysis stack, and an enterprise event
         | visualization stack.
         | 
         | Our enterprise salespeople are on the way!
        
       | somat wrote:
       | I have no idea what I am talking about, but for complicated
       | system analysts would it not be better to use markov style
       | statistical systems.
        
         | josipmrden wrote:
         | I guess yes but the question is how do you model it and with
         | what tools. And what are the questions you want to have
         | answered with a Markov chains? Not to mention that they can
         | likely explode with the number of data points. I also have no
         | idea what I am talking about.
        
       | jesprenj wrote:
       | memgraph.com was discussed on HN a week ago:
       | 
       | https://news.ycombinator.com/item?id=34342371 -- Bullshit Graph
       | Database Performance Benchmarks
        
         | josipmrden wrote:
         | Hello jesprenj, I'm the writer of the article.
         | 
         | Yes, thank you for the reference. We're much appreciating
         | comments, both positive and negative on the benchmarks, and are
         | focused on even more workloads, and acknowledged datasets in
         | the future
         | 
         | As for the title itself, I would not comment much on that.
        
       | Aaronstotle wrote:
       | This article feels like it was written by an AI
        
         | josipmrden wrote:
         | Sorry Aaronstotle if it feels that way, I'm actually the writer
         | of this article. I wanted to get an overview to people that can
         | connect dots in their minds using "graphs", but don't think of
         | them when it comes to developing solutions and thinking of how
         | the parts of the attack are connected.
        
       | badrabbit wrote:
       | I can't comment on this specific use case since it isn't useful
       | to me during incident reponse and haven't seen anyone else even
       | talk about mapping relationships this way. I personally prefer
       | the simplicity and power of excel and tabular data.
       | 
       | That said, neo4j+Bloodhound is something I am heavily invested in
       | and not just me but most serious threat actors use
       | Bloodhound+neo4j to choose lateral movement attack paths. Graph
       | databases are how hospitals or govenrment departments get fully
       | owned, except when they are 90s era flat IP network with everyone
       | an admin over every server lol.
        
       | waihtis wrote:
       | a lot of people taking jabs at this, but in principle it's a good
       | idea. At least a few problems do surface to mind: 1) having clean
       | data to work on in the first place and 2) having enough skills to
       | write the right queries. Outside of Fortune 100 security teams
       | both are a complete roll of the dice.
        
       ___________________________________________________________________
       (page generated 2023-01-20 23:02 UTC)