How we built our latest security domain, Infrastructure Configuration

Big Panaseer product news: we’ve built a new security domain! You can now use Panaseer to help improve your infrastructure configuration programme. Read on to find out more.

Why did we build an Infrastructure Configuration domain?

We already have a Cloud Configuration domain, but many of our customers wanted to apply similar analysis and measurement to their on-prem infrastructure. Thus, the Infrastructure Configuration security domain was born.

Customer challenge

Several of our customers came to us with challenges around being able to effectively report on their configuration, typically at a higher level and within the wider context of their business. They already have tools that run configuration tests to assess whether their devices pass or fail the various configuration items in a given benchmark.

But they liked the idea of applying Panaseer’s capabilities to this area of security measurement and reporting.

They wanted a summary of their infra config programme, combine it with data from elsewhere within their wider security programme, and zoom in on specific things, like critical devices, business areas or processes.

They were also struggling to measure against their own specific configuration standards. They don’t necessarily just take the CIS or other standard benchmarks off the shelf. They will likely rank, modify, add to or amend these to apply their own unique lens on how infrastructure configuration should be managed for their organisation. This could be influenced by their specific infrastructure, other tools, other mitigations, industry standards or expectations, their risk appetite and more. Simply put, they want to focus on what they care about most.

Panaseer was an obvious choice for them because it can layer in multiple data sources that can represent this unique lens. This was challenging with their regular tooling, so it became another factor in choosing to work with Panaseer to get the desired view of their infra config programme.

Isn’t everyone moving to cloud?

Well, yes, but actually no.

We previously built a solution for Cloud Infrastructure Configuration. Does it feel like a bit of a step back to build an on-prem version?

There’s a huge shift towards cloud, but it isn’t a total change. Among our customers, especially those who are more highly regulated, almost no-one is fully cloud native.

This could be for various reasons, whether deliberately for business services that still need to be on-prem perhaps, or simply because it takes time to migrate to cloud native.

Fundamentally, if you’ve got on-prem assets now, you need it to be secure now. So, we built the solution.

The other piece, of course, is user endpoints. However much is in the cloud, you still need a physical system, i.e. your laptop, to access it. Laptops are given to almost every individual in a company, and they aren’t all cybersecurity experts. They’re potentially carrying it around with them, going to different places, particularly remote first workspaces, accessing different systems. You still need to harden these systems appropriately. And the Infra Config module can help you do that.

It’s a current need, so we’ve built a current solution.

What we built

Essentially, we’re bringing in data from a configuration management or compliance tool(s) and leveraging it against our device inventory and business logic.

Here’s a dashboard from our demo to see what it looks like.

The new security domain solution provides an overview of the infra config programme and performance. We also enable customers to bring in their own flavour. They will have specific configuration tests and/or benchmarks that are more important to their unique programme, as well as exceptions, that they can view in a single dashboard.

And ultimately, you can get more nuanced insight into your programme than you’d get from regular config tooling. You can answer questions like:

• Is our configuration management/compliance tool scanning everything we want it to?
• Are misconfigurations being addressed within the agreed time?
• How are we performing against a CIS level one benchmark?
• How are we performing against the specific set of configuration tests that we have classified as critical?
• Which are the configuration failures that crop up most often?
• Is there a part of our business performing less well?

So really, it’s designed to give you that overall assessment of how things are going. But it also gives you insights to see what’s driving the problems you’re having, and in turn either prevent misconfigurations from happening or remediate them more effectively.

How did we do it?

We’re in the process of transforming our delivery approach so we can ship updates more efficiently and without friction.

A solution for the many, not the few

We worked closely with our customers in both the discovery process and during the early build phase. This experience meant we now had real examples of the pain points. We can always take some data and do some analysis. But, to provide a highly valuable solution, we needed to understand the common themes across a range of customers.

The real challenge we face when developing a new security domain is not so much figuring out what analysis is useful for one organization but being able to generalize across many organizations. This is one of the key differences in developing a SaaS solution versus working in an in-house data analysis team for one business.

Working with customers allowed us to explore their needs and cross reference. This helped us piece together a general model of how customers are approaching infrastructure configuration.

That allowed us to build in best practice that is applicable to a wider range of organizations.

The decision-making process

We’ve obviously got tried and tested ways of building security domains. This would be our tenth.

It all starts with data. What data do we need? Where does it come from? What does the data model look like?

For infra config, it’s clear we need data from multiple different compliance or configuration tools. The data model needs to bring this data from multiple disparate tools and combine it so it’s usable. The trouble is that the tools will typically produce the same type of data, but it will be structured and named differently and may not contain all the same information. The data model needs to align all of that. That’s how we ensure that Panaseer remains vendor-agnostic.

Next, we need to decide how to transform and analyse this data, in order to make it suitable to support the metrics our customers need. This includes choosing which other data in our platform to combine it with.

Inventories form the foundations of Panaseer and are key components for every security domain. For each new domain, we must assess which inventories are most important to the controls our customers use. For infra config, it’s our device inventory, so this also gets brought into the data analysis.

We also need to set up control checks to apply to the data that reflect customer policies around infra config. In this case, what’s the SLA for addressing a misconfiguration?

Some of the more unique analysis comes from customers identifying and measuring the configurations that are most important to them. So, we need to add classifications of the configuration tests and the ability to align to exceptions, which goes beyond what is typically available in the existing config tools our customers are using, as well as a mechanism for customers to utilise these.

Designing the data flow

And then it’s about designing a high-level data flow. We map it out on a whiteboard with boxes and arrows as a data flow diagram.

We’re going to start here. The data is going to go here. It’s going to land in this table with this schema. It’s going to move, join, transform. Control checks are going to get applied.

Here’s a dummy data flow to add some visual flavour.

Then we’re going to code that up.

Finally, we need to present the data. That means creating the metrics and dashboards you see in the UI.

We use our own dashboard building tools, the same ones our customers use to build their own additional dashboards.

Release

We release as a closed beta first to, in this case, to, you know, maybe one or two customers. We get initial feedback, we iterate, make some small tweaks and changes. And when we’re confident that we have a version that is working effectively and delivering value, we send it general availability and start writing blogs about it.

The final word

Infrastructure Configuration is the tenth security domain available in Panaseer. It has been built hand-in-hand with our customers. Their challenges, needs and value were constantly in mind. If that resonates with you, so if you feel like you might you want to see more, don’t hesitate to get in touch at success@panaseer.com.