- Unsupervised Learning
- Posts
- Universal Daemonization as Asset Management
Universal Daemonization as Asset Management
I’ve written a decent amount about Universal Daemonization—the idea that objects such as humans and restaurants and office buildings can be interacted with in a standardized way, using standardized protocols.
So Siri could send a temperature increase request to the /climate API for a restaurant on your behalf and the building would adjust to your preference automatically. Or Siri could parse the /professional interface for a person they’re walking by, then notifying the user that they’re in the same subfield.
That’s for big things, like people. And buildings. And businesses.
But what about small things? And virtual things. Couldn’t (and shouldn’t) we use this model for everything? That’s the idea that I’ve not been able to shake for over a year now.
The enterprise
Think about what’s in an enterprise that needs to be tracked, but usually isn’t (or at least not well).
Server hardware
Operating systems
Applications
Patches
Vulnerabilities
Etc.
What if all these things were available through a service architecture, and linked to each other through relationships.
So you have a server, which is an object, which you can query through HTTP and REST. It has attributes. You know where it is, you know when it was installed, you know who installed it, you know the work order that allowed it. All these are objects too, which can also be queried.
So server 10289 has an operating system of type 334556, which has attributes. It has a version, which as specific features and bug fixes, which also have attributes. And all of those items are also objects, also queryable via REST, and are linked from the original object.
So now we can say that when a security scan is run, against an application in an environment, there are findings. Findings contain vulnerabilities. Vulnerabilities might contain CVEs, or whatever. And those CVEs might affect this operating system and that application.
It’s a fabric. A web of related objects, all of which are being constantly being updated by various tools and processes.
And that’s what makes up your asset management system. It’s just a series of interlinked objects that are updated and queried by a series of tools using a common protocol and language.
Filtering and authentication
What’s cool about this is that you can have one protocol for not only querying and updating the system, but also for performing authentication and authorization.
A scanning tool finds a bunch of vulnerabilities in application 100142 sitting on host 33445 running OS 9900023 that has patches 10223 and 22221, and it wants to update the /vulnerabilities attribute in that application.
Well, the scanner has to have authorization to write to that application’s object. It uses a central identity granted to it by the enterprise to POST the updates to that service and make that change.
But the request had to go through one or more filters. A broker. To ensure that the input was valid. That a similar request had not already been performed. That the user is still valid. Etc.
And this is happening billions of times a minute, all throughout the enterprise.
Challenges
It’s going to be a lot of requests, and performance will become an issue pretty quickly.
There will probably be update intervals. Caching at certain chokepoints that gets updated only when things change behind that point.
There will be optimizations so that the same exact queries aren’t being made when nothing has changed.
Value
But let’s say we can get through those obstacles. Let’s say we’re able to solve the performance issues through some combination of hardware, software, optimized protocols, smart algorithms for caching responses, etc., and let’s say that it works.
Think of what the enterprise starts to look like.
It’s a set of universally interactive objects.
Everyone knows how to interact with them. Every object has a UDDI description right in it, telling you exactly what you can do with the service (you get different answers based on who’s asking).
And everyone knows how to make the requests and handle the responses.
IT systems simply become combinations of these objects in different ways. Servers have operating systems. Operating systems have versions, and patches, and filesystems. Vulnerability reports have findings, which have vulnerabilities, which have CVEs, which have publish dates.
Vulnerabilty management systems become a simple series of queries and reports given the systems you have in place and their current status, which is easy to determine.
Unsupervised Learning — Security, Tech, and AI in 10 minutes…
Get a weekly breakdown of what's happening in security and tech—and why it matters.
What about now?
But don’t we already have this?
No.
What we have today is one hundred products, each with their own database. And moving data between these products requires intermediary formats, such as emails, and PDFs, and CSV, and worse.
Vulnerabilities in one system aren’t linked to vulnerabilities in another because they’re on different operating systems, found by different tools, stored in different formats, being accessed by different reporting applications.
It’s much worse than apples and oranges. One group is using fruit, the other group is using vegetables, and the business model is to only communicate by notching a tree. Manually. And independently. Because the fruit people are competing with the vegetable people.
It’s ridiculous.
This is why you can go into 85% of enterprises today and ask them where their assets are and have them laugh in your face.
Unification
So maybe Universal Daemonization is the answer not only for big things, but for small and virtual things as well. Maybe it can be our unified interaction model for all objects. Big, small, virtual, and physical.
People, cars, virtual switches, IP addresses, vulnerabilities, findings, operating systems, patches, data types, file shares, and restaurants.
Everything is an object
Every object gets an API
The objects are linked through relationships
There is a single query and interaction language
All requests require a federated ID
A broker system validates all requests
Think about queries. Reports. Analytics.
It’s all there, in one system. One architecture. You’re just writing logic in the unified language according to what you want, and building interfaces to display the results.
Exploring ideas
Maybe this is the dumbest idea ever. Maybe it will never scale. Maybe nobody will cooperate enough to make it practical.
But those seem like surmountable problems when the potential of success is so great.
It seems to me like the ideal model for describing and interacting with objects. And if it is…if it is the purest form of representing and manipulating things in our world, then I don’t see how it won’t be achieved eventually.
Until I am shown that it’s impossible, or that it’s not worth wanting, I’m staying with the idea. I want to help build it.
Notes
I say asset management because I’m thinking about enterprises. But really what I’m talking about is every object in the world being managed in this way, both big and small—virtual and physical. Cats, dogs, printers, flu outbreaks, coffee makers, semi trucks, office buildings, stoplights, park benches, relationships, etc.
Image from unknown author. If you know who created it, please let me know so I can seek permission and/or give credit.