Ordr Announces Integration with ServiceNow Service Graph Connector Program! Read more here!

Ordr

Request a Demo Search

Month: September 2019

It’s an unassailable reality for today’s enterprise organizations:  security and network teams must continue to do more to address the rapidly growing mass of devices that are being connected to their networks.  And they absolutely must keep up with this increased device scale without the benefit of analogous scale to their resources, neither human nor capital.  This undeniable trend is not new, but in our interactions with enterprise teams we continue to see an increased push towards a Zero Trust network topography.  This comes up more frequently in meetings that our teams are having, so I wanted to share some background, common themes and best practices we are seeing around this topic.  And away we go.

To start, we need to establish a clear definition.  I will spare you from the endless pages of search results [and vendor-specific opinions and positions] that googling ‘Zero Trust Architectures’ will produce.  I like this one from CSO Online…it’s concise and straightforward; from it you will learn that the Zero Trust concept was created by John Kindervag in 2010, and is growing in popularity.

I think that this line sums it up best:

Zero Trust is a security concept centered on the belief that organizations should not automatically trust anything inside or outside its perimeters and instead must verify anything and everything trying to connect to its systems before granting access.

Sounds great, let’s do that.  Let’s get the CISO to implement this and report her progress during the next Board of Directors meeting.

Let’s be honest, it’s not that simple.  What isn’t stated, but rings from the words in the statement above, is that you simply cannot build a trust model for ANYTHING inside or outside your network, without complete visibility of the devices in your environment.  Not just mac and IP address visibility, but contextual visibility of all of the assets coming in and out of the environment.  You have to know your environment and devices completely, to even start.  Oh, and that isn’t a onetime visibility, it is going to have to be continuous since the environment is constantly changing and systems, devices, people are attaching to and detaching from your network at a head-spinning rate.

But simply knowing isn’t enough.  The second piece of this puzzle is the verifying exactly what every device and system is before you give it access.  Behavior is key.  You can’t trust something about which you don’t have complete understanding.  Which means it’s imperative to add behavioral context – and dynamic and continual adjustment of that context – on top of the already important continuous visibility.  You have to know exactly with what devices inside and outside of your network each device communicates.   More importantly, you have to know with what devices – internal and external – each device SHOULD communicate.  You have to be able to do this across the campus, data center, remote offices/branches and you have to be able to do it across traditional IT, OT, IoT, medical…you name it.

So now I see the device, I understand the behavior of the device, I am always watching, learning, seeing communications, placement on the network…..etc. Now I know what I have, what it’s doing, with whom it’s doing it, and whether or not it’s operating in the way I want it to operate.

Next step – Enforce/Regulate/Control/Take Action….whatever you call it, this is the implement and control phase.  This is where the rubber meets the road.  This is where we don’t necessarily worry about trusting the device, this is where we basically make sure the device only does what you want it to do.  That it only does what you allow it to do, no trust needed.

The good news is you probably already have the infrastructure in place to achieve this.  Most organizations have invested in enterprise switch infrastructure, next generation Firewall technology, Network Access Control systems, etc.  With intelligent and dynamic policy generation, Ordr gives you the power to utilize your existing infrastructure for enforcement; this is truly proactive protection for the hyper-connected enterprise.

Want to see this in action?  We would love to show you.

Reach out in the comments, email me, or request a demo here.

The Numbers Game

Today, virtually every device connects to the enterprise network. From simple function IoT devices to multi-million-dollar operational systems, modern devices utilize data connectivity to perform highly specialized tasks much more intelligently. The sheer heterogeneity of these devices is growing exponentially.

Effectively regulating these devices, in terms of what it can and cannot do inside the enterprise, requires a significant amount of knowledge on each, since you simply cannot control what you don’t know. In an effort to build the necessary repositories of device intelligence, vendors create – with varying levels of detail – device profile libraries.  At Ordr we see these libraries as a starting point, a base on which to deliver a comprehensive suite of control capabilities that effectively protect devices and relevant business critical information. We believe that developing a large profile library is nice – organizing in a way to keep it relevant and up to date is crucial.

There are enormous challenges in organizing the library relevant and up to date.  A set of printers that are classified as a set of profiles in an enterprise installation will look slightly different in another customer installation – perhaps because of configuration, operational behavior, network connectivity – and will result in an entirely new set of device profiles. Any firmware or software update will necessitate a new profile in order to keep it up to date.  At the same time, just like a traditional library, there are too much material that are irrelevant since nobody can ever use them. Profiles with irrelevant information will do more harm than good.  To search through all the myriad of uncorrelated and out of date information in a library to get what you need is a difficult task.

Profile Library vs Profile Generator

At Ordr, we believe that the only way to keep the device profiles relevant and up to date is to develop a profile generator.  Being able to report millions of device profiles in a library is fundamentally unimportant. What is important is the efficiency with which the profiles can be used in an underlying multi-vendor networking and security infrastructure – and automate such infrastructure to control these devices in terms of access control and policy enforcement.  We need a real-time Profile Generator for those devices actually deployed in an enterprise and produces the relevant parameters for automated control.

In order to achieve this goal, we deploy a number of sophisticated Machine Learning (ML) techniques for our Profile Generator.  Our Deep Neural Network (DNN)model ingests all the relevant attributes identified to create a sophisticated machine learning engine for comprehensive device classification. Each unique set of device attributes are collected and fed into the engine, which learns and organizes it.  When new devices are added to the network or when their software is updated, the learning engine can add or update the device profile. Moreover, it has the intelligence to determine that multiple devices, while they may have slight differences in individual attributes, are essentially the same type and class of device. It filters out irrelevant details and focus on important attributes.

Instead of creating a new profile for each of these devices and each variant of it, the DNN enhances the main device profile to better predict the behavior of the device regardless of its enterprise-specific attributes. When we feed a set of attributes of a device, DNN engine models the non-linear relationship on data for more generalized learning. This way we arrive at an “inference engine” that can predict the classification the devices of that it has never seen before.

Along with DNN, we also use carefully crafted ensembles of Random Forest and SVM algorithms to influence prediction performance. Such techniques have a significant positive impact on the classification accuracy of our inference engine.

For instance, with Ordr, a printer profile hierarchy would be organized as a logical tree beginning for example with manufacturer, make, model, firmware, and other attributes which may vary from enterprise to enterprise.  Ordr intentionally organizes this structure in a way that enables increasing granularity of detail with each tier, while other approaches would create a different profile for each variation in any level of attribute.  Not only is it an efficient way to store the profiles, the hierarchical method delivers an ever-increasing level of intelligence and accuracy, while maintaining the relationship among the devices in an efficient manner. As the number of devices identified to be within a group increases, the predictive engine becomes increasingly efficient in future classifications, all without the need for any manual intervention or personnel resources.  The Profile Generator is a Learning Tree that continues to produce new branches and grow new leaves, while shedding dead branches and dropping dry leaves.

Our ultimate goal is to effectively offer automated protection to the myriad of connected devices that access the enterprise network.  To do this, we generate and enforce granular policies that utilize the existing network and security infrastructure.  It is absolutely essential to scale profiling efficiency to many hundreds of thousands of devices in a single enterprise, and finish this process within hours. Without understanding the relevant details of the relationship among these profiles properly organized in a hierarchical way – this policy generation would be untenable, if not impossible.

Taking Control with Actionable Profiles

In summary, we use the most sophisticated data extraction techniques to collect data using methods like DPI (Deep Packet Inspection) and application level transaction analysis. The inference engine from the learning model gives us an enormous advantage to classify the unseen devices in the customer setup without additional interventions. Our AI/ML models make it possible to not only detect anomalies but also come up with actionable auto-generated policies ready to apply in the existing networking and security infrastructure.  Our real-time Profile Generator can keep the information relevant and up to date, with continuous improvement in coverage and accuracy.

It may sound impressive and exciting to hear about many millions of device profiles. Big numbers get attention.  But growing a tree is more than collecting thousands of leaves.