Bandura Cyber TIG OS version 2.0
This document provides cumulative release notes and upgrade path information for the Bandura Cyber Threat Intelligence Gateway (TIG) OS 2.0.
The table below lists the Bandura Cyber hardware part numbers that are compatible with TIG OS 2.0 software, as tested with build 32 and later. Each of these can end in C (copper), F (standard reach multi-mode fiber), or S (long reach single-mode fiber):
|Bandura Cyber TIG Part Number|
* certain models only - consult Bandura Cyber Support
NOTE: Upgrading compatible hardware from TIG OS to TIG OS 2.0 will require a physical reimaging of the TIG device. Due to hardware requirements, some legacy Bandura Cyber TIG devices will not support TIG OS 2.0. If you are currently running a version of TIG OS 1.0 (version 3.x or below) and would like to upgrade to TIG OS 2.0, please contact email@example.com or your sales representative to determine upgrade options for your Bandura Cyber TIG.
For upgradeable devices, please note that it is not possible to remotely upgrade from TIG OS to TIG OS 2.0 via remote software download. For compatible devices, users will need to physically upgrade their devices onsite via a USB installation process. To initiate this process, please contact Bandura Cyber support or your sales representative, listed below.
For more information see the TIG OS 2.0 User Manual, located in the Bandura Support Center, located here: https://helpdesk.banduracyber.com/hc/en-us
If you have any questions about these updates, would like to initiate the upgrade path for your compatible TIG device, or have questions regarding your legacy TIG device, please contact the Bandura Support team at firstname.lastname@example.org or by calling +1-855-765-4925.
Release: TIG OS 2.0 Build 48
File Date: 16 September 2020
Purpose of the Release
This is an exciting release, as it finalizes our planned work and improvements for our already exciting syslog export features. Several new features while fixing several important defects, including two serious defects, one of which is a security vulnerability - and thus it is our strong recommendation that all customers upgrade to this release as soon as possible.
New and Improved
- Final planned round of major syslog export improvements (DEV-1974, 1981, 1984, 1996, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2015)
- With this release, we have finished our last planned major round of feature extensions and improvements to our already-powerful syslog export features. We have streamlined the key value pairs, so you may need to update your parsers if you were pulling out connection information from our exported packet logs related to denied lists, allowed lists, and threat lists, especially.
- Furthermore, with this release, we have fully documented our user-facing official RFC-compliant syslog export format as “version 1”. For a detailed descriptive document, feel free to reach out to our Customer Success team. Of course, we will continue to have minor improvements to our syslog export features over time, but we’re really excited since this release contains the last big-ticket items that we had planned.
- For one of these items, we’d like to explicitly thank the good folks at Gravwell, who pointed out that we really ought to consider publishing the RFC-compliant APP-NAME field to uniquely identify our application. Consider it done! Gravwell is a preferred partner of ours for analysis and visualization of our awesome syslog export detail, and we highly recommend you check them out at https://gravwell.io. We also recently partnered with Gravwell to create a built-in “Bandura Cyber Kit” that customers can download directly from the Gravwell ecosystem for out-of-the-box queries and dashboards against our powerful syslog exports.
- Add loose state handling detail to internal logs and syslog exports (DEV-1802)
- We now publish our loose state handling (LSH) connection direction determination data for cases where we were unable to “see” the initial SYN or SYN/ACK packets. Generally, our loose state handler operates by performing high-port-number analysis in real-time. When we leverage LSH (which is rare as usually we can definitively determine the direction), we now show these occurrences with small UI elements on the Internal Logs page. Additionally, when leveraging loose state handling, we also export a new key-value pair “lsh=true” in the associated syslog export, which can be parsed if desired in connected SIEM tools.
- Minor improvements to our administration and recovery menus (DEV-1834, 1873, 1965, 1991)
- These include better software version visibility, a CLI shutdown option, DHCP configuration, and more.
- Other minor internal improvements (DEV-1823, 1894, 1994)
- These are a variety of internal features, wording changes, and behind-the-scenes improvements to performance, towards our perpetual goal of always improving the overall customer experience.
Defect Fix Description(s)
- Allow only TLS 1.2 for secure connections (DEV-2009)
- We consider this a significant security vulnerability and strongly recommend that all customers upgrade to this release as soon as possible.
- We would like to thank one of our customers (you know who you are!) for pointing this out to us; after an independent vulnerability scan, they found that in addition to properly allowing TLS 1.2, we were erroneously allowing TLS 1.0, TLS 1.1, and SSLv3 by default. This is bad since TLS 1.0, TLS 1.1 and SSLv3 all have known security vulnerabilities that can result in insecure communications when exploited by a clever attacker. This is now fixed, and we now only allow TLS 1.2 for secure communications channels.
- Historic session purging was broken, potentially causing UI login lockout (DEV-2022)
- We consider this to be a significant defect and strongly recommend that all customers upgrade to this release as soon as possible.
- This particular problem was discovered internally, and has not been witnessed in the field yet, but it could show up, so we thought it best to get it fixed as soon as possible. There was an internal database contention problem keeping historical session logs from being properly cleared, which, in the worst case, could have resulted in access by either API or the UI being denied. This has been fixed.
- Corrected a potential stale-data condition in system log exports (DEV-2014)
- A minor internal condition existed where a structure was not being cleaned, which could have resulted in stale data being output in some system log export scenarios. This was discovered internally, and has not yet been witnessed in the field. Regardless, it has been fixed.
- The threat category roll-up information sent to GMC needed to be more intuitive (DEV-2017)
- You could argue that this is a feature improvement, but it caused enough questions amongst our customers that we decided to classify this as a defect. We had gotten ahead of ourselves a bit with all of the cool attribution that TIG OS 2.0 has in place, and we over-complicated some of the metrics, which caused some confusion. This is in comparison to our legacy TIG OS software which was very limited in its ability to do attribution, but more intuitively mapped to our GMC security posture dashboards. With this fix, we made sure that the data being rolled up to GMC was as intuitive as it used to be, without sacrificing our ability to do detailed attribution in our awesome syslog exports. What does this mean? Basically, it means that the “Allowed by Category” and “Denied by Category” GMC dashboard graphs will no longer show excessive data/counts. They are now intuitive in that the “Allowed by Category” graph means a category was found but allowed through because its score was below a configured threshold. And “Denied by Category” means a category was found to be associated with a connection that was denied (for any reason). We apologize for getting ahead of ourselves and over-complicating this statistic - and a huge shout out to one of our best customers (you know who you are!) for helping us get our heads around the best way to “solve” this nagging concern!