JSA

JSA 7.3.2 includes enhancements to performance, workflow, security, and user experience.

Performance Optimization

The performance improvements in JSA 7.3.2 include increased speed when you load assets, enhanced event parsing, and added report customization options.

Asset information loads faster

Your assets on the Assets tab is designed to load faster than in previous versions, which makes the monitoring process faster and saves you time.

To learn more about the Assets tab, see the Juniper Secure Analytics Administration Guide.

CSV file format added for exporting reports

JSA 7.3.2 provides a CSV file format for reports that use single table templates.

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

Enhanced parsing support for CEF and LEEF events

In the DSM Editor, you can now easily parse both standard and custom properties from events in CEF and LEEF format without writing regular expressions (regex). When you enable Property autodiscovery for log source types that consume CEF and LEEF events, all available fields are parsed as custom properties.

Many products can generate events in CEF and LEEF format. With these new capabilities, both administrators and users, who have permission to create custom properties, can quickly and easily parse these events.

You can use the DSM Editor to create a custom log source type to handle CEF and LEEF events in JSA. You can also add custom properties to help with the parsing of an existing log source type in the DSM Editor. Use simple CEF or LEEF expressions to define any property parsing instead of regex. The DSM Editor automatically provides expressions for system properties based on their predefined keys in the CEF or LEEF specification.

Turn on CEF or LEEF property autodiscovery, which discovers custom properties for all CEF and LEEF fields in any events that are received for the log source type. You can also use CEF and LEEF expressions in the Custom Event Property Editor and when you manually create log source extensions.

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

Improved currency of searches, filters, and rules

In JSA 7.3.2, you can reduce the lag time of expired reference data to as little as 1 minute to improve the currency of JSA searches, filters, and rules.

There’s a brief time lag before expired reference data is removed from the reference set. During the lag time, expired reference data is still seen by JSA searches, filters, and rule test conditions. By default, expired reference data remains for up to 5 minutes.

To learn more about configuring system settings, see the Juniper Secure Analytics Administration Guide.

More detailed visualization of rule performance

Rule performance visualization extends the current logging around performance degradation and the expensive custom rules in the JSA pipeline. In previous releases, it was cumbersome to identify rules that performed in a suboptimal way. With rule performance visualization in JSA 7.3.2, you can easily determine the efficiency of rules in the JSA pipeline directly from the Rules page.

When events or flows are routed to storage, JSA begins collecting metrics-enabled rules to track for efficiency. Metrics are collected on all event, common, and flow rules. When you save rule updates, the metrics are cleared to avoid any confusion around performance and updated rules. This option is also configurable.

Use rule performance visualization to help you monitor any expensive rules and ensure that they do not cause future performance issues. Sort rules by their performance metrics and identify the more expensive rules. When you review the rules, you can adjust the tests to optimize each rule, and reduce the load on the system. When rules run efficiently, the workload on the system can decrease. Over time, this efficiency helps JSA avoid any performance degradations around rules, which cause rules to bypass rule correlation. Bypassing rule correlation means that potential suspect activity might not trigger a notification, potentially missing future security-related issues.

To learn more about visualization of rules performance, see the Juniper Secure Analytics User Guide and Juniper Secure Analytics Administration Guide.

More template options for offense reports

In JSA 7.3.2, you can choose extra options when you create offense reports. These new options give you more visibility into the offenses that are in the report.

You can choose to include modified offenses and the full name of the offense in your report.

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

Improved management of backup files

Backup files are now detected and flagged in JSA. If your external storage becomes unavailable for a period, the risk of inadvertently deleting backup files is reduced.

Previously, when you backed up JSA files to an external file system, an issue with the external mount might cause files to become unavailable. If this issue occurred, references to the files were removed from the database. If the file system connection was later restored, JSA flagged the returned backup files as invalid. These files were not automatically deleted, and could be inserted into the system by using the upload feature or inbound directory.

Now, the backups that are listed on the Backup and Recovery page are flagged as missing if they are not found. If files were intentionally deleted by a JSA administrator, they can remove backups that are listed on the Backup and Recovery page.

For example, you might have an external file mount set up that stores your backup files. A failure of the mount causes the mount to disconnect, and JSA can no longer detect the backup files. On the Backup and Recovery page, the backups in the table display a warning to notify you that they are missing.

You can delete any of the backup entries in the table. Also, you can wait for the external mount connection to be restored. After the restoration and a page refresh, JSA rediscovers the backup files and removes the warnings on the Backup and Recovery page.

To learn more about backup files, see the Juniper Secure Analytics Administration Guide.

Rules and custom properties removed when content extensions are uninstalled

When you uninstall a content extension, any rules and custom properties that were installed by the content extension are removed or reverted to their previous state.

Previously, when a content extension was uninstalled, only applications were removed with it. Rules and custom properties were left behind and might have impacted performance.

If you want to remove a content extension that is not useful or is adversely impacting the system, click Uninstall. JSA 7.3.2 checks which applications, rules, and custom properties were installed by the content extension that can be removed. Some content might not be able to be removed because it was edited since the installation, or because another content item depends on it. If any content cannot be removed, you are prompted to decide how to proceed.

To learn more about content extensions, see the Juniper Secure Analytics Administration Guide.

Workflow Enhancements in JSA

Improvements to workflow in JSA for 7.3.2 decrease the amount of time that you spend running your processes. Some new features include saved searches and automatic detection for log sources.

Easy monitoring with consolidated audit events

By default, each expired reference data element is logged as a separate audit event when it’s removed from the reference set. Large numbers of expired elements can clutter the qradar.log file.

In JSA 7.3.2, you can log expired reference data elements that are removed at the same time as one audit event, or choose not to log them at all. Fewer audit events make it easier to monitor other important changes that are made to JSA.

To learn more about reference set options, see the Juniper Secure Analytics Administration Guide.

Enhanced support for autodetection of custom log source types

You can enable and disable log source autodetection for log source types in the DSM Editor, and tune how autodetection works. These enhancements also apply to custom log source types.

If you create a custom log source type that has many instances in your network, turn on autodetection in the Configuration tab of the DSM Editor. By enabling autodetection, you do not need to manually create a log source for each instance.

In JSA 7.3.2, upgrades from previous versions enable global configuration settings. The global settings are taken from the TrafficAnalysisConfig.xml file in /opt/qradar/conf/ on the JSA Console, so if this file has been customized before upgrading to 7.3.2, those customizations are not lost, but if different customizations exist on other managed hosts in the deployment, those will not be carried over to the global settings. You can still enable per-event processor autodetection settings by using the configuration file method.

If you choose to revert to the file-based (non-global) settings, you can configure only autodetection by using the config file. The DSM Editor and REST API work only with global settings. Migrate any custom autodetection configuration to global settings and to the DSM Editor.

In JSA 7.3.2, you can also tune the autodetection engine to prevent autodetection from incorrectly detecting a log source as a wrong type. This happens when the events from a log source type for which there is no DSM are similar enough to the events of another log source type for which there is a DSM, and that DSM incorrectly recognizes the events as its own. The autodetection engine creates a log source that is not of the correct type. To ensure effective configuration, you can increase the minimum number of events that are needed for autodetection, or increase the successful parsing percentage.

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

Manage multiple log sources simultaneously

It is now faster and easier to edit log sources in bulk with the new ability to build scripts, tools, or apps to add, edit, or delete log sources in bulk.

For example, as a JSA administrator, you might want to add 100 new log sources without using autodetection. In JSA 7.3.2, you can now write a script, or define a single REST API request to add all of them at the same time.

To learn more about REST APIs, see the Juniper Secure Analytics API Guide.

More comprehensive monitoring with audit events for new offenses

When an offense is created, it triggers an audit event with QID 28250369, which can be used by JSA searches, filters, and rule test conditions.

For example, you can schedule a daily report showing offenses that were created in the last 24 hours.

To learn more about logged actions, see the Juniper Secure Analytics Administration Guide.

Saved search enhancements

In JSA 7.3.2, you can convert a saved search to an AQL string, and modify the string to create your own searches to quickly find the data you want.

Now you can create searches faster than by typing the search criteria. You can also save the search for future use. From the Log Activity or Network Activity tab, select a saved search and click Show AQL. JSA converts the saved search to an AQL string. Use this AQL string to create your own searches.

Also, you can now run a saved search by using the ID of the search. Previously, you ran a saved search only with an AQL query.

To learn more about saved search enhancements, see the Juniper Secure Analytics User Guide.

Enhanced support for VLAN information in network activity flow records

JSA 7.3.2 retains Virtual Local Area Network (VLAN) information that is exported in external flow records (IPFIX, NetFlow V9, sFlow V5, or J-Flow V9 or viewed in internal flows (Napatech and Network Interface Card). Users can then query, filter, search, or write custom rules with this VLAN information.

All flows with VLAN information contain two new Juniper-specific fields that can be used to define unique domains in JSA:

• Enterprise VLAN ID

• Customer VLAN ID

For example, a UDP flow is sent from 10.0.0.1:123 to 10.0.0.2:456 on VLAN 10. Another UDP flow is sent from 10.0.0.1:123 to 10.0.0.2:456 on VLAN 20. Previously, flows were incorrectly aggregated together, resulting in a loss of information. In JSA 7.3.2, the unique identifier for each flow includes the nested VLAN fields (including post fields). The flows are treated independently, each with their own VLAN definition.

To learn more about VLAN information in network activity flow records, see the Juniper Secure Analytics User Guide.

Assign domains to flows with VLAN information

Domain management in JSA is enhanced for flows with VLAN information. With domain support for VLAN flows, you can define your domains in JSA based on the VLAN information in your network.

In JSA 7.3.2, you can assign domains to incoming flows based on the VLAN information that is contained in the flow. The incoming flows are mapped to domains that contain the same VLAN definition. You can also filter and query the domains for the VLAN-based domain.

As in previous versions, you can assign tenants to domain definitions to achieve multi-tenancy. In JSA 7.3.2, the new VLAN-based domain definitions enable multi-tenancy across different VLANs, if required.

For example, two domain definitions are created and mapped to two network tenants:

• For tenant ABC, traffic is sent on Enterprise VLAN ID = 0, and Customer VLAN ID = 10.

• For tenant DEF, traffic is sent on Enterprise VLAN ID = 0, and Customer VLAN ID = 20.

The first domain definition is created for tenant ABC, which contains a flow VLAN definition of Enterprise VLAN ID = 0 and customer VLAN ID = 10.

A second domain definition is created for tenant DEF, which contains a flow VLAN definition of Enterprise VLAN ID = 0 and customer VLAN ID = 20.

Now, incoming flows with Enterprise VLAN ID and Customer VLAN ID fields set to 0 and 10 are viewed only by tenant ABC. Similarly, incoming flows with Enterprise VLAN ID and Customer VLAN ID fields of 0 and 20 are only viewed by tenant DEF. This reflects the traffic ownership for each tenant in the network.

To learn more about assigning domains to flows with VLAN information, see the Juniper Secure Analytics Administration Guide.

Enhanced visibility into MPLS flows received from IPFIX data

Internet Protocol Flow Information Export (IPFIX) is a common protocol that allows exporting of flow information from network devices. Multiprotocol Label Switching (MPLS) is a routing technique that runs on any protocol.

With MPLS support for IPFIX flow records in flow processor, you can filter and search for IPFIX flows in JSA 7.3.2 that contains MPLS fields and write rules based on the values of these MPLS fields. In JSA 7.3.2, MPLS information about the IPFIX flow is no longer lost.

For example, an IPFIX flow is exported from a switch on a network that uses MPLS. The IPFIX flow that is exported from the router contains information about the MPLS stack, which is now saved as part of the flow in JSA. The MPLS stack can contain up to 10 layers where each layer shows information about the flow routing. These MPLS fields are included in rules, searches, and filters.

To learn more about enhanced visibility into MPLS flows received from IPFIX data, see the Juniper Secure Analytics User Guide.

Security Enhancements

Stronger security capabilities in JSA 7.3.2 include upgrades to the Red Hat Enterprise Linux operating system and the ability to monitor unauthorized log-in attempts to your account.

Data obfuscation configured per domain or tenant

In JSA 7.3.2, you can configure obfuscation for each domain or tenant.

Data obfuscation prevents unauthorized access to sensitive or personal identifiable information that is stored in JSA.

Previously, obfuscation was not configured for a log source type per domain or tenant. The work-around was to configure obfuscation for each individual log source, which became impractical if you had many log sources.

To learn more about creating data obfuscation expressions, see the Juniper Secure Analytics Administration Guide.

Detection of unauthorized access to user accounts

The login history shows you the past successful and failed login attempts to your user account.

Previously, this information was available only to administrators or users who had access to the audit logs and queries.

When you log in, you can view the history of login attempts that are made with your user name. You can also view the number of failed attempts since your last successful login and the IP addresses where the attempts were made.

To learn more about detection of unauthorized access to user accounts, see the Juniper Secure Analytics Administration Guide.

More secure operating system

JSA 7.3.2 runs on Red Hat Enterprise Linux version 7.5. The update to RHEL V7.5 is necessary to continue receiving security updates from Red Hat Enterprise Linux.

Single sign-on authentication with SAML 2.0

7.3.2 includes support for the Security Assertion Markup Language (SAML) 2.0 single sign-on format.

By using the SAML authentication feature, you can easily integrate JSA with your corporate identity server to provide single sign-on. SAML eliminates the need to maintain local users for JSA.

With SAML single sign-on authentication, users who are authenticated to your identity server can automatically authenticate to JSA. These users don't need to remember separate passwords or type in credentials every time they access JSA.

To learn more about SAML in JSA, see the Juniper Secure Analytics Administration Guide.

Support added for multi-domain Microsoft Active Directory authentication

In JSA 7.3.2, you can now use multiple Active Directory IDs, which requires a change in login credential format. Previously, you logged in with your userid, but starting with 7.3.2, you use the Domain\user or Repository_ID\user login formats.

The Repository ID is an identifier or alias that uniquely represents the server that is entered in the Server URL field and the domain from the Domain field. Use the Repository ID when you enter your login details. For example, you might use AD_1 to represent server_A on Domain_A in one Active Directory Repository, and AD_2 to represent server_B on Domain_A in your second repository.

Users can log in by using the Domain\user or Repository_ID\user login formats. The login request that uses Repository_ID\user is attempted on a specific server that is linked to a specific domain. For example, Server A on Domain A, which is more specific than the Domain\user login request format.

The login request that uses the Domain\user format is attempted on servers that are linked to the specified domain until a successful login is achieved. For example, there might be more that one server on a specific domain.

To learn more about configuring multi-domain Active Directory IDs, see the Juniper Secure Analytics Administration Guide.

Easier to Manage and Customize JSA

In JSA 7.3.2, you can now customize whether you have administration settings on a tab and manage users and user preferences with greater precision.

New managed host for apps

JSA 7.3.2 introduces the App Host, which is designed specifically to store and manage your applications. By using the new App Host in your JSA deployment, you can manage the appliance in the same way as other managed hosts. As an added benefit, JSA manages all updates to the operating system, and you can include the App Host in your high-availability deployments. You no longer have to upgrade the App Node separately from your managed hosts because JSA is now managing it for you.

Earlier versions of JSA used an external App Node to provide extra storage, memory, and CPU resources for JSA applications. The App Host replaces the App Node.

To learn more about App Hosts, see the Juniper Secure Analytics Administration Guide.

Convenient access to admin settings

In JSA 7.3.2, you can mark the admin settings as a favorite. When a navigation menu item is marked as a favorite, you can conveniently access the item from JSA as a tab.

Enhanced management of users and user preferences

Enhancements to the User Management and User Preference pages help you to better manage JSA users and help JSA users to easily edit their preferences.

Use the new User Management pages to create and update user accounts. In the new User Preference page, users can update their account information, including changing their password.

Improved filtering enables faster searches of user data.

This new ability also adds an option to allow system authentication fallback. This option is configured on a per-user basis. Previously, this option was available only to administrators.

To learn more about enhanced management of users and user preferences, see the Juniper Secure Analytics Administration Guide.

Enhanced Users API

The Users API supports apps and external integrations to manage users in JSA by using a REST API. App developers and developers of external integrations with JSA can use a REST API to automate the creation of users. The REST API is a documented and supported method of allowing external integrations to manage users.

This API also adds the allow_system_authentication_fallback option. This option is configurable on a per-user basis. Previously, this ability was available only to administrators.

To learn more about REST APIs, see the Juniper Secure Analytics Administration Guide.

New health check framework

DrQ is an extensible health check framework for JSA. Run DrQ before major events, such as upgrades, to determine whether there are any issues that need to be addressed first. You can also run DrQ routinely to monitor the health of your system.

To learn more about health checks, see the Juniper Secure Analytics Troubleshooting and System Notifications Guide.