SBN

Why Security Teams Need Graph-Based Security Solutions

TL; DR 

  • Your unknown blind spots can be your biggest undoing, no matter how prepared you think you are. 
  • Current security teams suffer from legacy security practices in place; leading to high turnover and security incidents.
  • Graph based security methodologies allow overworked and understaffed security teams to “auto-magically” bring into focus what matters for their specific environment. 

Mindset shift 

I’m a DevOps engineer by trade, but I always strive to learn skills and job functions of those teams that I work with, whether it’s on the technical side by learning how applications are built and designed or on the business side such as strategic planning and sales.

Understanding these teams’ point of view on a problem helps shift the way I approach the same issue to make sure it works for the collective and not only my goals. This leads to better comprehension of issues and buy-in from other teams when proposing a solution. 

This orientation on teams within an organization is what security teams need to do when we want to become effective. It was very similar to when DevSecOps began to become a title thrown around in my circles until we realized it was not just a marketing term but something that was a mindset shift about introducing security earlier in the DevOps process.   

Too often I come across security teams whose measure of success is holding a certain percentage “score” against an opinionated compliance standard or staying below a notional threshold of open Common Vulnerabilities and Exposures (CVEs) of a specific severity. These standards of success were often chosen without clear context to the business’ regulatory nor threat environments. Worst yet, those teams who have burn out from tackling these lists only to find out they were false positives, still get breached or find themselves understaffed due to turnover. 

I am not against certain regulatory compliance standards (especially if your business requires it) nor setting Key Performance Indicators (KPIs) and Service Level Agreements (SLA) for certain activities. The warning is against using security tools that only present problems without presenting any thought or enrichment around a team’s own business and personal operational goals. 

Graph to the rescue 

Until recently, most security tools use relational databases to store the information about your environment. That is great until you want to change the way that database stores or searches for data that is “unknown” or that the designer of the relational database did not anticipate for its intended use. Anyone who has designed or used SQL will understand this pain greatly when project direction changes or you’re tasked with writing a SQL query that is so long and contains so many table joins, it pushes the boundaries of becoming its own entity. 

For graph databases, it is possible to find those unknown or unanticipated questions. Property graph databases are a form of NoSQL database that are built around the interconnectedness of your domain’s data. Simply, property graphs revolve around how the data relates to one another, every bit of data is a Node (a virtual machine, a user identity, etc.) and is connects to other nodes via Edges by a shared Property which is the metadata of any given node. A practical example is you have an AWS Cloud EC2 Instance node which is connected to an AWS Virtual Private Cloud (VPC) by the identifier of that VPC. It is also connected to a stateful firewall, named an AWS Security Group, also by the identifier of that security group. 

This means when something new comes up that you want to discover, you are able to pivot your focus and quickly find your answer. This is how social networks are able to understand what advertisements to focus their millions of end users towards or how supply chain mapping is even possible. 

The Lightspin approach 

At Lightspin, any bit of information our platform collects about your environment ends up on a property graph and all insights are surfaced using graph theory, advanced graph algorithms, and bespoke detection use cases. Harnessing the potentials of a property graph database surfaces itself across the following capabilities. 
 
One of the first realizations of new customers of the Lightspin platform, is that Lightspin does not seek to masquerade as a graph by crafting slick visualizations on top of static, relational data stores.  It genuinely provides true context-based facts to support findings, eliminating the guesswork of “could be public” findings, etc. Let’s highlight some of the sections within Lightspin.

Attack Paths

The core value of the Lightspin platform is the ability for us to surface critical attack paths. 

  • These are the culmination of security findings, vulnerabilities and misconfigurations in a cloud environment that contribute to a known attack method such as privilege escalation, data exposure and account compromise to name a few. 
  • With Lightspin you can see attack paths that are more than just 2-3 hops like others who are trying to attempt to copy what we do with Attack Paths because of how we introduce the graph into the very beginning of the process and also find those “unknown” paths in your environment that you don’t know to search for. 
  • Lightspin also provides dynamic built remediation for all of these attack paths that come in the form of CLI based commands, manual step-by-step process or downloadable content such as dynamically built JSON policies or Terraform modules. 
  • By using Lightspin’s proprietary method for automatically findings attack paths within your environment you eliminate the need to wait for days, weeks or even months to build the queries needed to make the tool useful.  You get to enjoy this benefit on DAY ONE! 

Vulnerabilities

  • Lightspin gives you the ability to not only have an agentless CVE scanning tool, but to ingest other tools as well. Such as Tenable, Snyk, Twistlock, and Checkmarx to provide the same context-based prioritization that they are unable to provide with just using their own tools. 
  • The CVE prioritization engine works backwards from your environment looking at assets with elevated permissions and exposed on the network edge. It then accounts for if a fix/patch is available, known exploits, actionable cyber threat intelligence (CTI), and basic scoring heuristics such as the Common Vulnerability Scoring System (CVSS). 

Security Findings

  • With security findings, Lightspin provides Root Cause Analysis to help reduce overwork by showing how multiple security and identity findings are related and can be fixed using one step remediation. 
  • You will only see the security findings that relate to the actual attack path, not every single security finding on the asset which allows you to home in on the actual issue without being bombarded with noise that obfuscates the true issue at hand. 
  • Lightspin has upgraded its core Root Cause Analysis feature with our Remediation Hub which identifies the risks with the most impact on the overall account risk score. This allows the user to reduce the most risk with minimum actions – with remediation able to solve many issues at once (where relevant).  
  • The Remediation Hub provides users the ability to easily apply remediation at scale and take action to improve account health quickly. 

Remidiation Hub- Widgets (Grouping) (1)

Conclusion 

Since joining Lightspin 18-months ago, I’ve gotten to meet security teams from all backgrounds and sizes that were blown away that a cloud security tool had finally gotten to the point that endless lists of CVEs are a thing of the past.  No longer will they have to parse through thousands of findings on a Wednesday after Patch Tuesday or try to scramble through hundreds of “Critical/High” security findings to avoid the incessant pings of missing internal SLO/SLA timelines.  

Lightspin is built on the graph, not bolted on after the fact. It’s why I chose to join Lightspin a little over a year ago, helping hundreds of companies since then. My eyes were opened to the power of the graph by a simple concept called an Attack Path.

Thank you for reading my blog! To continue the conversation please connect with me on LinkedIn:  https://www.linkedin.com/in/michaelsilva2/  

To get hands-on with Lightspin, start for free today!   

Start for Free

*** This is a Security Bloggers Network syndicated blog from Lightspin Blog authored by Michael Silva. Read the original post at: https://blog.lightspin.io/why-security-teams-need-graph-based-security-solutions