Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

JSA

 

JSA 7.3.3 includes enhancements to performance and user experience.

Performance Optimization

The performance improvements in JSA 7.3.3 include enhanced parsing support for name value pairs and generic list events, the ability to remove reference data when you uninstall a content extension, a faster way to export content from the DSM Editor, and updates to flow records.

Enhanced Parsing Support for Name Value Pair Events in the DSM Editor

In the DSM Editor, you can now easily parse both standard and custom properties from events in the Name Value Pair format without writing regular expressions (regex). When you enable Property autodiscovery for log source types that consume Name Value Pair events, all available fields are parsed as custom properties. With these new capabilities, administrators and users who have permission to create custom properties, can quickly and easily parse these events.

Use the DSM Editor to create a custom log source type to handle Name Value Pair events in JSA. Add custom properties to help parse an existing log source type. Use simple Name Value Pair expressions instead of regex to define how to parse custom properties. The DSM Editor automatically provides expressions for system properties based on their predefined keys in the Name Value Pair specification.

Turn on Name Value Pair property autodiscovery to discover custom properties for all Name Value Pair fields in any events that are received for the log source type. You can also use Name Value Pair expressions in the Custom Event Property Editor and when you manually create log source extensions.

The following figure shows where you parse Name Value Pair events in the DSM Editor.

Figure 1: Name Value Pair Structured Data Type
Name Value Pair Structured Data Type

To learn more about enhanced parsing support for Name Value Pair events, see the Juniper Secure Analytics Administration Guide.

Enhanced Parsing Support for Generic List Events

In the DSM Editor, you can now easily parse both standard and custom properties from events in the Generic List format without writing regular expressions (regex). When you enable Property autodiscovery for log source types that consume Generic List events, all available fields are parsed as custom properties. With these new capabilities, administrators and users who have permission to create custom properties, can quickly and easily parse these events. With these new capabilities, administrators and users who have permission to create custom properties, can quickly and easily parse these events.

Use the DSM Editor to create a custom log source type to handle Generic List events in JSA. You can also add custom properties to help parse an existing log source type in the DSM Editor. Use simple Generic List expressions instead of regex to define how to parse custom properties. The DSM Editor automatically provides expressions for system properties based on their predefined keys in the Generic List specification.

Turn on Generic List property autodiscovery to discover custom properties for all Generic List fields in any events that are received for the log source type. You can also use Generic List expressions in the Custom Event Property Editor and when you manually create log source extensions.

The following figure shows where you parse Generic List events in the DSM Editor.

Figure 2: Generic List Structured Data Type
Generic List Structured Data Type

To learn more about enhanced parsing support for Generic List events, see the Juniper Secure Analytics Administration Guide.

Removing Reference Data when you Uninstall a Content Extension

When you uninstall a content extension in JSA 7.3.3, any reference data that was installed by the content extension is removed or reverted to its previous state. Now when you uninstall a content extension, the reference data is removed, which frees disk space on your system.

Previously, JSA removed applications, rules, custom properties, and saved searches, but did not remove the reference data, which might impact performance.

To learn more about enhanced parsing support for LEEF and CEF events, see the Juniper Secure Analytics Administration Guide.

Export Content Faster in the DSM Editor

JSA 7.3.3 makes it faster to export your custom content in the DSM Editor. Use the Export button to easily export your content from one JSA deployment to another, or to external media. Previously, you could export custom content only by using a content management tool script.

The following figure shows where you export content in the DSM Editor.

Figure 3: Exporting Content from the DSM Editor
Exporting Content from the DSM Editor

To learn more about exporting content from the DSM Editor, see the Juniper Secure Analytics Administration Guide.

Security Enhancements

Stronger security capabilities in JSA 7.3.3 include modifying the inactivity timeout for user accounts.

Inactivity timeout for user accounts

As an administrator, if you have users who require longer periods of inactivity before they are logged out of the system, you can configure their inactivity timeout threshold individually. The default is 30 minutes. For example, a security analyst might need constant access to visual information, such as that available on the dashboard. When you create a user account that always displays a dashboard, set this user's inactivity timeout to 0.

Previously, you configured an inactivity timeout threshold on a global basis, and uniformly applied it to all system users.

The following figure shows where the Override System Inactivity Timeout is enabled and set on the User Details pane.

Figure 4: Override System Inactivity Timeout
Override System Inactivity Timeout

To learn more about configuring inactivity timeout for user accounts, see the Juniper Secure Analytics User Guide and Juniper Secure Analytics Administration Guide.

Flow Improvements

JSA 7.3.3 provides more data to help you analyze network activity in your environment.

Flow aggregation count

A new Flow Aggregation Count field shows the total number of input flow records that were aggregated to create that single flow record.

For most external flow records, such as IPFIX, NetFlow, or J-Flow, the counter is incremented for every data record that contributes to a particular flow.

For internal flow sources, such as sFlow or raw packets that are received from a Technocrat monitoring card or NIC, the counter is incremented for every packet that contributes to a particular flow.

The new field appears on the Flow Information window, and it is populated for all flows that are received after you upgrade to JSA 7.3.3. You can use it in filters, searches, and rules.

To learn more about offense reports, see the Juniper Secure Analytics User Guide.

VXLAN flow information now available

VXLAN information that is present in raw packets that are sent to Flow Processor (through Azure vTap, Technocrat monitoring card, or NIC) is extracted and added to JSA flow records.

The VXLAN Network Identifier (VNI) is extracted in accordance with RFC 7348 (https://tools.ietf.org/html/ rfc7348). The VNI is then used as part of the unique identifier for all VXLAN-aware traffic, ensuring that flows on different VXLAN network segments are not aggregated together.

Flow Processor must be configured to look for VXLAN traffic on the correct ports. By default, Flow Processor listens for VXLAN traffic on UDP port 4789, in accordance with RFC 7348. Listening for VXLAN traffic can also be turned off.

When VXLAN traffic is identified, the VNI appears in the VXLAN Network Identifier field on the Flow Information window. You can use the field for filtering, searching, and rule definition.

To learn more about searching flow data, see the Juniper Secure Analytics User Guide.

Improvements to the Flow ID

Now, you can use the Flow ID field in filters and searches to quickly identify all of the flow records in a particular session.

In earlier versions of JSA, the Flow ID field was populated for IPFIX records that specified flow ID. In JSA 7.3.3 the Flow ID field is populated with the same identifier for all flow records that are part of the same session.

For each session, the Flow ID is based on the unique identifier for the flow and the time that Flow Processor determines that the session began. For all subsequent interval-by-interval flow updates, the Flow ID remains the same until the session completes. For example, a session might be complete when no new traffic is seen in a 60-second interval.

For IPFIX records, the flow ID value that was previously shown in the Flow ID field now appears in a new Vendor Flow ID field. The flow ID is still used as part of the flow's unique identifier so that only flow records with the same flow ID value are aggregated together.

The new Vendor Flow ID field appears on the Flow Details window and can be used in filters, searches, and rules.

To learn more about searching flow data, see the Juniper Secure Analytics User Guide.