Teleseer processes network collection files containing 802.3 or 802.11 headers. In addition to network collection files, Teleseer processes bro/zeek logs (with more log support to come!).
When uploading files, we highly recommend processing 802.3 or 802.11 (beta) collection files as opposed to logs because a more enriched topology will be generated. View the Demo Projects to compare a topology generated with PCAP vs a topology generated with bro/zeek logs.
See Supported File Types for more information.
Yes! We process 802.11/Wi-Fi wireless collections.
The analytics engine distinguishes devices behind the NAT and provides a summary of the different devices observed within network topology.
The analytics engine will fingerprint the encrypted devices and provide contextual awareness about the encrypted session(s) if available. This information will appear within the Timeline.
We just do it. And we do it well.
Teleseer utilizes a custom graph database. The graph is completed constructed in memory for maximum performance within any web browser.
In the near future, we will be implementing secure access to cloud shares to allow users to directly upload content from their cloud environment.
There are two types of data that we store: (1) uploaded data and (2) project data.
(1) Uploaded data gets stored encrypted at rest in GCP buckets.
Your data is fully purged 30 days after deleting it from your account. This grace period lets us support undeletion requests. We delete everything immediately if you close your account.
(2) Your project data contains metadata we extracted from your uploaded data and gets stored in a separate database. This database has high-availability replications across multiple datacenters, and is snapshotted hourly and stored for 30 days.
We secure data via industry standard best practices: data at rest encryption, SSL connections for all Teleseer interactions, and secure authentication providers.
We sure can! You can take a look here at the files we currently support. We will be supporting more file types in the future. Please let us know which logs are most valuable to you!
Actively scanning devices is no doubt a very helpful way to determine what's running on your network, but this also requires the installation and maintenance of these "agents" on every connected device. As you can guess, this not only takes a large amount of time to achieve but also these agents may take up valuable resources on your end users' machines.
Passively analyzing a network allows us to identify what's running on your network without the need to install and maintain these agents.
So what's the catch? There's always a catch. As a result of no agents being installed on end user devices, we rely solely on the traffic that is going across the wire. If the traffic doesn't traverse the network, we will not know much about the device(s) in question. The more traffic that traverses the network, the more we will know about the devices on the network.
See the table below for more comparisons between active and passive network monitoring:
|Active Analysis||Passive Analysis|
|Real-time view of network performance||Analyze network at a specific point in time|
|Requires agents to be installed on end user devices||Does not require agents to be installed on end user devices|
|Data is transient||Data exists so long as collection file exists|
|Adds additional traffic to network||Does not add additional traffic to network|
|Provides minimal insight into network as a whole||Provides vast insight into network as a whole|
|Receive alerts immediately||Receive alerts after the fact|
The analytics engine is able to unpack tunnels of various types as long the tunnel(s) are not encrypted. The edges between endpoints will have a specific demarcation within the network topology.
The analytics engine is able to fingerprint SCADA traffic and display the corresponding protocols within the Timeline.
We will have a self-hosted option for select users. Stay tuned!
VMs are handled with fingerprinting technologies and to the best of our ability we connect them to the host they are on.
Teleseer will soon have the ability to correlate a collection file and a tap point. This allows the user to gain different viewpoints into the network under assessment. If the tap point is not identified, then the resulting network topology may require manual modification.
"cooked" collections occur when a user collects data from "any" device. As a result, the generated collection file does not contain any layer 2 (MAC address) content.
We do not currently support cooked PCAPs. Good news! We will in the near future.
See https://wiki.wireshark.org/SLL.md for more information on supported files.
To determine if your capture is cooked, you can run the capinfos application.
On Linux, the application should be on your path if Wireshark is installed.
On Windows, the application will exist in your Wireshark directory.
Within Wireshark, users can determine if a pcap is cooked by selecting Statistics > Capture File Properties.
Yes! Click on the Import tab within the Inspector panel to import additional files.
Did you know you only need a few MB of PCAP data to map the network? You may not need to such a large number of collection files.
Additionally, we process bro/zeek logs, which are a lot smaller than PCAP.
If you still want to upload large files, create a compressed archive (if possible) with the desired files you'd like to upload.
Down the road we're going to provide a binary that you can drop at different tap points no your network that will sample data every few hours or so to keep the map updated.
At this time, users can download the topology assets as a CSV file. Support for downloading the topology as an image is coming soon.
Follow the steps at Download Asset Inventory to download the topology as CSV.
Support can be reached via email at [email protected] or via the Live Chat option on the bottom right of the screen (after you've logged in).
Updated about 1 month ago