Hello and welcome to my first blog article here at Stamus Networks. My name is Phil Owens and I am the director of systems engineering at Stamus Networks. Today I want to give you a brief tour of what’s new in the Stamus update 37 (U37).
But before we get into the exciting new capabilities in U37, I want to provide a brief update on some other changes in how we are now talking about our solutions.
Based on market feedback, we are adjusting our product marketing to more correctly align with how our customers are using our systems and how new customers are discovering us. As such, we are reorganizing and renaming our product family (formerly Scirius) into two primary offerings:
Note: these new product names are NOT reflected in this latest U37 release, but will begin to appear in subsequent product updates, beginning in Q3 of this year. And until then, we may still have a few “Scirius” documents and articles lying around.
Here’s how our old product names (shown on the left below) map to our new product names:
As part of this process, we are simplifying from the three Scirius product tiers shown in the left side of the diagram into two product levels: Stamus ND and Stamus NDR. Both include the Stamus Security Platform and Stamus Network Probes, with different capabilities based on the licensing options (either Stamus ND and Stamus NDR).
As you review the messaging changes on our website and in other materials, please refer to the above diagram if you are having difficulty making sense of it. Of course, feel free to reach out to us if you have any questions or concerns. We’re here to help.
Ok. Now onto the new features in U37.
This feature improves visibility and transparency into the sequence of events that led up to a Stamus NDR declaration of compromise and identifying the asset(s) under attack. There is also an optional Gantt chart view of the event sequence.
This feature gives a great view of an attack sequence by assets as well as by kill chain stage. This view can be found on the Assets tab, on the left hand side, in Stamus NDR. With this timeline you can quickly work your way back to patient zero to help understand how the attack started and you can accelerate remediation with added confidence.
This new capability - in beta form - may be used to add elements to datasets based on traffic metadata. The system can then continuously evaluate connections and traffic patterns for DNS server requests, encrypted connections, hosts, HTTP user agents, usernames, and other protocol attributes in order to identify new values, never encountered. When combined with critical assets, this “newly discovered” event can be used to detect anomalies and otherwise unknown threats.
Here’s a little bit more about the use cases for this new capability:
While this is mostly under the hood in U37, we do have a way to expose this information to the Hunting UI. Once properly configured, this data, associated with network definitions and business context, can be used to spot potential issues, including threats or potential misconfigurations.
For example, servers being monitored usually communicate with the same set of destinations. However, if that server starts communicating with something new, it could signify suspicious activity, like a change in a software update server that your system is communicating with. It may mean nothing but it could be a redirect to someplace malicious as in a supply chain chain attack. (think Sunburst).
This new feature adds JA3S information to the existing tools for uniquely fingerprinting encrypted sessions. Along with the existing JA3, it allows for the identification and correlation of a TLS Server/Client pair to detect common infrastructure and command and control in particular traffic.
For those unfamiliar with JA3 and JA3S, here is a brief overview.
JA3 and JA3S are methods for creating SSL/TLS fingerprints, easily computed, and designed to be shared for threat intelligence purposes.
The first bytes of a SSL/TLS communication are sent in clear text, and those bytes are used to create a unique fingerprint (MD5) that is dependent on the packages and methods used when building the SSL/TLS handshake.
In short, JA3 is a representation of the client request (how it would establish the communication) and JA3S is a representation of the server response. With the combination of the two, JA3 + JA3S, it is possible to fingerprint the entire cryptographic negotiation between the client and its server.
Applied to cybersecurity, and especially malware communication, those fingerprints come very handy.
In fact, typically a given command and control server will consistently respond to the malware client in exactly the same way, it does not deviate. So even though the traffic is encrypted and one may not know the command and control server's IPs or domains as they are constantly changing, we can still identify, with reasonable confidence, the malicious communication by fingerprinting the TLS negotiation between client and server.
You can read out more about JA3 and JA3S here: https://github.com/salesforce/ja3](https://github.com/salesforce/ja3
In the Stamus solution, metadata enrichment, tagging, automated triage classification, and the execution of “Stamus threat” detection logic was performed on Stamus Network Probes. As such these features have not been available to native Suricata sensor deployments.
With U37, we developed a centralized extract, transform and load (ETL) function that allows us to perform nearly the same functions in the Stamus Security Platform (SSP).
When enabled, SSP now performs the enrichment and tagging of alerts from Suricata sensors, delivering some key capabilities previously only provided by the Stamus Network Probes. This capability lets users apply filters and tag events based on domain/DNS server, JA3 enrichment, and geoIP enrichment.
In addition, one of the key Stamus NDR (formerly Stamus Threat Radar) features is the advanced logic for the ultra high-fidelity detection that generate what we call declarations of compromise™ or “Stamus Threats.” This capability was previously unavailable to deployments that use native Suricata sensors. With U37, some of this Stamus NDR capability is now available for Suricata users.
Although deploying Stamus Network Probes is the most complete way to get all the advantages of Stamus Security Platform, these capabilities help those customers that are currently managing Suricata sensors get more visibility from their data. Just keep in mind that this processing is taking place on the SSP server (not on the Suricata sensors), so you will need to account for this performance impact when sizing your system.
In U37, we extend the suite of capabilities available to the user under a single pane of glass by integrating Cyberchef directly into SSP. Cyberchef is a multi-capable toolset that allows for quick encoding, decoding, and transforming of data -- from simple bas64 and XOR, to more advanced algorithms. By adding this toolset to SSP, it means that you no longer need to install multiple tools or access the internet to accomplish decoding during analysis.
You may access Cyberchef along with Evebox and Kibana from the selector icon on the right side of the header in the UI. See the screenshot below.
With this new capability, managed security service providers may isolate integrations with client SOAR or messaging systems via individual webhook connections for each tenant.
Webhook push notifications were introduced in U36, and now SSP allows administrators to choose tenants and add multiple output locations based on those tenants. This gives managed service providers the ability to direct Stamus Threat notifications for each client’s network to the appropriate upstream tool for each client. The webhook notifications may be used to trigger a SOAR to run a playbook, generate an alert message with relevant information in a MatterMost or Slack channel, or open a ticket in ServiceNow or an incident response tool such as TheHive.
In U37, we are enhancing role-based access to improve an organizations’ ability to manage access to various SSP functions. Roles are based on view and configuration access to nine areas of the system. Users may, for example, define an administrator role with access to certain configuration fields, but without a view of the data.
This is essential to allow for separation of duties, so only certain analysts can see all the data and the administrators/engineers can manage the system without access to potentially confidential information.
As always, our team is eager to share more details about this new release. So, please let us know your availability to discuss the U37 upgrade and - if you’d like - to schedule a brief demonstration of these new capabilities.
If you are a current customer, you may visit your My Stamus Networks portal to review the instructions for upgrading your Stamus Security Platform and your Stamus Network Probes to U37.