This blog was originally distributed on Amazon's Database Blog.
Most organizations take a linear, list-based approach to security operations. It's a two-dimensional process. First, identify resources. Second, manage their configurations. Ideally the tools and technologies for management also alert security analysts about changes in the environment and help with remediation.
The problem with this two-dimensional approach is that it doesn't connect the relationships of the different components of your environment: Endpoints, vulnerability management tools, DevOps and Cloud tools, and your security policies and procedures. Without this context, you can't tell if changes in your environment are important, critical, or expected. The result is that preventing attacks requires you to wade through each of the planned changes and the false positive alerts in order to get to the issue.
For example, you know that you need to protect critical resources in your production environment. When a designated administrator obtains access to that resource via an approved mechanism, there is no issue. But how do you determine if the device has the required security controls to avoid chasing down non-issues? The relationship mapping makes all the difference and that is where stopping at two dimensions falls short.
With JupiterOne, we saw a clear opportunity to build-in context by mapping the relationships in an organization's environment. We built a graph model by using the Amazon Neptune graph database service. The graph model drastically shortens the time between knowing what has happened and knowing if it's a problem.
Enter the graph model
For organizations to level the playing field, they must switch from viewing their environment in two dimensions to three. To do that means changing the way data and relationships are mapped. A graph, not a checklist, is the only way to represent this complexity in a meaningful way.
With JupiterOne, we built a graph-based reference data model that fully captures an organization's digital environment. The data model is defined by a set of Entities and their Relationships. An Entity is a node or vertex in the graph that represents a resource within your digital infrastructure. A Relationship is the edge between two Entity nodes in the graph. Each Entity and Relationship has its own class, type, and properties.
When you connect the dots between the entities and their relationships, you can unearth extremely valuable, context-rich insights. For example, the example graph here makes it easy to quickly spot any active Amazon EC2 instances that are truly exposed to the internet:
Another example would be to highlight cross-account, assumed role trusts from within your AWS accounts to external accounts.
Some siloed services and tools can give you insight into their exclusive data. However, the Entity-Relationship graph is designed to cover an organization's entire infrastructure. This can include network, server, endpoints, data repositories, cloud services, the suite of applications and software development tools, users and identities; as well as security controls and their findings, such as vulnerabilities, events and alerts. The data is stored in Amazon Neptune's graph database.
Leveraging Amazon Neptune
Developing JupiterOne, we had the opportunity to evaluate Neptune while it was still in preview. It was quickly apparent that Neptune was going to enable us to focus on developing JupiterOne, not on negotiating licenses and managing infrastructure. As is common with other AWS services, Neptune's usage-based model would keep our costs low while we were in development and scale with our business as we continue to grow. Neptune was key in enabling us to get JupiterOne to market and we are highly confident in its ability to scale as our business continues to grow.
Navigate the graph database with search
After this graph is built, you can see the vastness and complexity of relationships that exist. Traditional alerts or reports fall short when it comes to gaining insight and deep understanding of your complete environment because they are lacking context. We saw an opportunity for an operation that can incorporate context and relationships: Search.
Instead of alerts, simply query the graph database to gain robust, actionable insights. You can ask questions like "Who has admin access to a particular AWS environment or resource?" or "Which server instances are truly exposed to the internet?" or "What changed in my environment in the last 24 hours?" These questions analyze many layers of details and complex connections and provide a clear answer.
Building the graph and maintaining it
Now you've seen the power of this graph data model and an implementation that transforms security from vague assumptions to data-driven questions and answers. But how was this graph built? There are unique challenges in ingesting the data, especially to get it right when building the relationships and keeping track of ongoing changes.
JupiterOne uses Neptune at its core and a number of other AWS services including:
- AWS Lambda functions for serverless computing
- Amazon API Gateway
- Amazon S3
- Amazon Cognito
- Amazon DynamoDB
- Amazon Kinesis
- Amazon CloudWatch
- Amazon Elasticsearch Service
JupiterOne uses various APIs to ingest the data directly, avoiding painfully dull and error-prone data entry. After the data is ingested, items are automatically classified and maintained using your specific data model. This data is kept up-to-date by automatic and scheduled fetches of the data. It is not a trivial task. A technical walkthrough is seen below.
Day-to-day security workflows
The graph data model allows you to shift your day-to-day security and compliance management to pinging the graph for what you need to know. We built our own query language, dubbed JupiterOne Query Language (J1QL) to search the graph. Security analysts can ask a simple question like "What resources don't have an IAM policy associated with them?" It will return specific, actionable results based on the relationships that are mapped. It's what you really need to know and how to correct the problem.
Think about a security analyst trying to perform user access reviews and understand the effect of a non-compliant device. After the data is ingested and the relationships are mapped among the users, resources, and access, the security analyst can search for users without approved security endpoint monitoring in place, or that the endpoint agents are reporting non-compliant status. Because of the third-dimension relationships, it is easy to see what resources those users and devices have access to. You could also see the potential impact to systems and data they may have if the users and devices were compromised.
With JupiterOne we were also able to tag and package those questions into various buckets. This is where streamlining the compliance process comes into play. One of the most useful is the ability to search the graph database for areas that align with various security frameworks, providing an instant glimpse into your environment as well as providing compliance evidence during an audit.
Taken a step further, we also built a graph visualizer that makes it easy to see the relationships in the graph after the search. You can continue to narrow your search with additional filters but it can be easier to spot anomalies when you are simply looking at the relationships that exist on a single plain versus a table.
Conclusion
By shifting to a graph versus list model, you are able to more accurately visualize the entirety of your digital environment. Automating the data ingestion means less time on error-prone entry and more on analysis. All of this enables you to quickly understand the relationships between users, resources, and devices. It also allows you to easily spot whether a change in the environment is a problem.
This shift to the graph model is critical to gain context of your environment's complex relationships.
