Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

JSA

 

JSA 7.3.1 family of products includes enhancements to its core capabilities, RESTful APIs, and the Ariel Query Language (AQL).

Improve Performance and Uptime in JSA

These are new features that improve the performance and uptime capabilities of JSA in 7.3.1.

Continuous collection of events during minor patch updates

You can expect fewer disruptions in event collection when you apply future patches to JSA 7.3.1 or later. Minor patches that do not require the system to restart will not restart the event collection service.

Event collection continues when you install or update a protocol RPM

Before JSA 7.3.1, installing or updating a protocol RPM required a full deployment, which caused event collection to stop for several minutes for all installed protocols.

Now, protocols are loaded dynamically when you deploy the changes. Only those protocols that were updated experience a brief outage (in seconds).

Identifying flow direction reversal

As you're viewing a flow in the JSA Console, you might want to know whether JSA modified the flow direction, and whether any processing occurred. This algorithm provides information on how the traffic originally appeared on the network and which traffic features caused it to be reversed, if at all.

When the Flow Processor detects flows, it checks some of the flow properties before it acts. In some cases, the communication or flows between devices is bidirectional (the client communicates with the server and the server responds to the client). In this scenario, both the client and the server operate as though they are the source and the other is the destination. In reality, JSA normalizes the communication, and all flows between these two entities then follow the same convention: "destination" always refers to the server, and "source" always refers to the client.

For more information, see Identifying whether a flow's direction was reversed in the Juniper Secure Analytics User Guide.

Log Source Extensions can extract values events in JSON format by key reference

Log Source Extensions can now extract values by using the JsonKeypath.

For an event data in a nested JSON format, a valid JSON expression is in the form /"<name of top-level field>”/"<name of sub-level field_1>”..../"<name of sub-level field_n>”

The following two examples show how to extract data from a JSON record:

  • Simple case of an event for a flat JSON record: {"action": "login", "user": "John Doe"}

    To extract the 'user' field, use this expression: /"user".

  • Complex case of an event for a JSON record with nested objects: { "action": "login", "user": { "first_name": "John", "last_name": "Doe" } }

    To extract just the 'last_name' value from the 'user' subobject, use this expression: /"user"/"last_name".

More health metrics data

JSA collects up to 60x more health metrics data than before, making it easier for administrators to monitor their deployment and diagnose issues when they occur. You can visualize the new health metrics by using the JSA Deployment Intelligence app, which is available from the IBM Security App Exchange.

The JSA Deployment Intelligence app replaces the System Health information that was previously available on the Admin tab.

The additional health metrics data increases the size of the JSA log files and the disk storage requirements for the data. Administrators who require more control over the disk storage that is required for the accumulated health data can create a retention bucket that uses Log Source Type = Health Metrics as the criteria.

New JSA Data Store offering

A new offering, JSA Data Store, normalizes and stores both security and operational log data for future analysis and review. The offering supports the storage of an unlimited number of logs without counting against your organization’s Events Per Second JSA license, and enables your organization to build custom apps and reports based on this stored data to gain deeper insights into your IT environments.

Enhancements to the routing rules in JSA 7.3.1 require a license for JSA Data Store. After the license is applied and the routing rule enhancement is selected, events that match the routing rule will be stored to disk and will be available to view and for searches. The events bypass the custom rule engine and no real-time correlation or analytics occur. The events can't contribute to offenses and are ignored when historical correlation runs. Some apps will also ignore these events.

For more information about configuring routing rules to forward data, see the Juniper Secure Analytics Administration Guide.

Reduced downtime for event collection services

In earlier versions, deploying changes to your JSA system sometimes resulted in gaps in data collection while the hostcontext service restarted. To minimize these interruptions, the event collection service is now managed separately from other JSA services. The new event collection service, ecs-ec-ingress, listens on port 7787.

With the new separation of services, the event collection service does not automatically restart each time that you deploy changes. The service restarts only when the deployed changes impact the event collection service directly.

This enhancement significantly reduces interruptions in collecting data, and makes it easier for you to comply with your organization's data collection targets.

For more information, see Making changes in your JSA environment in the Juniper Secure Analytics Administration Guide.

Improve workflow in JSA

These are new features that improve the workflow capabilities of JSA in 7.3.1.

Ability to restart only the event collection service

From the JSA product interface, you can restart the event collection service on all managed hosts in your deployment.

This new capability is useful when you want to restart the event collection service without impacting other JSA services. For example, after you restore a configuration backup, you can defer restarting the service to a time that is convenient for you.

For more information about restarting the event collection service, see the Juniper Secure Analytics Administration Guide.

Configuring auto property discovery for log source types and a new Configuration tab in DSM Editor

You can configure the automatic discovery of new properties for a log source type. By default, the Auto Property Discovery option for a log source type is disabled. When you enable the option on the new Configuration tab of the DSM Editor, new properties are automatically generated. The new properties capture all the fields that are present in the events that are received by the selected log source type. The newly discovered properties become available in the Properties tab of the DSM Editor.

For more information about using the DSM Editor, see the Juniper Secure Analytics Administration Guide.

Identifying how application fields are set for flows

As you're viewing a flow in the JSA Console, you might want to know whether JSA modified the flow application name, and whether any processing occurred. You can use this information to gain insight into which algorithm classified the application, and to ensure that algorithms are extracting flow features correctly.

As you're viewing a flow in the JSA Console, you might want to know whether JSA modified the flow application name, and whether any processing occurred. You can use this information to gain insight into which algorithm classified the application, and to ensure that algorithms are extracting flow features correctly.

For more information, see Identifying how application fields are set for a flow in the Juniper Secure Analytics User Guide.

IPv6 support

JSA uses the network hierarchy objects and groups to view network activity and monitor groups or services in your network. The network hierarchy can be defined by a range of IP addresses in IPv6 as well as IPv4 format. In addition to Network Hierarchy, Offense Manager used to only support IPv6 indexing but it now updates and displays all the appropriate fields for an offense with IPv6 data.

For more information about setting password rules, see the IPv6 addressing in JSA deployments topic in the Juniper Secure Analytics Administration Guide.

Two new preinstalled apps in JSA 7.3.1

App Authorization Manager

The App Authorization Manager app provides improved security for app authorization tokens. Users who have the appropriate permissions can delete authorization tokens, or change the assigned user level authorization.

QRadar Assistant App

The QRadar Assistant App provides the following functionality on the Dashboard tab:

  • Recommended apps and content extensions that are based on your configured preferences.

  • JSA Help Center dashboard widget to help you access helpful information about JSA.

  • Content update status is highlighted, and then users can download updates from within JSA.

Strengthen Security in JSA

These are new features that strengthen the security capabilities of JSA in 7.3.1.

Improved security with new password policy

When using local JSA authentication, you can enforce minimum password length and complexity, and control password expiry and reuse. The rules that you set are enforced for administrative and non-administrative users.

For more information about setting password rules, see the Configuring system authentication topic in the Juniper Secure Analytics Administration Guide.

Log source auto-detection configuration

Before JSA 7.3.1, log source auto-detection configuration was controlled by a configuration file that was edited manually on each event processor managed host.

As of JSA 7.3.1, global configuration settings are now available. You can use the JSA REST API or a command line script to enable and disable which log source types are auto-detected. If you use a smaller number of log source types, you can configure which log sources are auto-detected to improve the speed of detection. Log source auto-detection configuration also helps to improve the accuracy of detecting devices that share a common format, and can improve pipeline performance by avoiding the creation of incorrectly detected devices.

Note

You can still enable per-event processor auto-detection settings by using the configuration file method. You can manage the method that is used on each event processor in Admin > System & License Management > Component Management. Upgrades from previous versions do not enable global settings, and retain the use of the local configuration files. Fresh installations of JSA 7.3.1 enable the global auto-detection settings option.

Monitor successful login events by running reports in JSA

Easily monitor successful login events for the time period that you configure by running the Weekly Successful Login Events report template on the JSA Reports tab.

For more information about creating and managing reports, see the Juniper Secure Analytics User Guide.

Protect your JSA instance with strong passwords

When you enable the policy, system authentication passwords must contain a minimum number of characters and optionally must also contain at least 3 of the following attributes: uppercase characters, lowercase characters, special characters, numbers. Users are prompted to change their password if they log in with a password that does not meet the requirements.

The password policy settings apply to administrative and non-administrative user passwords that are managed by JSA (system authentication). These settings do not apply to passwords that are managed by another authentication provider (external authentication) or root passwords.

For more information about configuring system authentication, see the User Management chapter in the Juniper Secure Analytics Administration Guide.

Improve User Experience in JSA

These are new features that improve the user experience in JSA for 7.3.1.

Browser-based system notifications

JSA now uses your browser notification settings to display system notifications. With this enhancement, you can continue to monitor the status and health of your JSA deployment even when JSA is not the active browser window. To show system notifications on your screen, you must configure your browser to allow notifications from JSA.

Browser notifications are supported for Mozilla Firefox, Google Chrome, and Microsoft Edge 10. Microsoft Internet Explorer does not support browser-based notifications. Notifications in Internet Explorer now appear in a restyled JSA notification window.

For more information, see the System notifications topic in the Juniper Secure Analytics Administration Guide.

Create an alias for the User Base DN (distinguished name) that is used for LDAP authentication

When you enter your user name on the login page, the Repository ID acts as an alias for the User Base DN (distinguished name). This use of an alias omits the need for typing a long distinguished name that might be hard to remember.

For more information about configuring LDAP authentication, see the Juniper Secure Analytics Administration Guide.

Edit or create a login message that is displayed to users in JSA

Provide users with important information before they log in to JSA. If needed, you can force users to consent to the login message terms before they can log in.

For more information about creating and editing login messages, see the Juniper Secure Analytics Administration Guide.

New slide-out navigation menu with favorite tabs

As the number of apps that are installed in your deployment grows, so does the number of visible tabs. The new slide-out navigation menu makes it easier for you to find the apps that you use the most by managing which tabs are visible in JSA.

When you upgrade to JSA 7.3.1, all JSA tabs are available from the slide-out menu ( ). Each menu item is marked as a favorite, which also makes it available as a tab. You can control which tabs are visible by selecting or clearing the star next to the menu item.

To access the settings that were on the Admin tab in earlier JSA versions, click Admin at the bottom of the slide-out navigation menu.

Ariel Query Language (AQL)

JSA introduces new AQL functions and enhancements.

AQL-based custom properties

With AQL-based custom event or custom flow properties, you can use an AQL expression to extract data from the event or flow payload that JSA does not typically normalize and display.

For example, you can create an AQL-based property when you want to combine multiple extraction and calculation-based properties, such as URLs, virus names, or secondary user names, into a single property. You can use the new property in custom rules, searches, reports, or you can use it for indexing offenses.

To learn more about creating and using custom properties, see the Juniper Secure Analytics User Guide.

Enhanced support for the AQL subquery

In JSA 2014.8 and 7.3.0, the subquery was accessible only by using API.

The subquery is now available for use in searches from the Log Activity or Network Activity tabs.

For more information, see the AQL subquery topic in the Juniper Secure Analytics Ariel Query Language Guide.

Enhanced support for the SESSION BY clause

In JSA 7.3.0 the SESSION BY clause was accessible only by using API.

The SESSION BY clause is now available for use in searches in JSA.

For more information, see the Grouping related events into sessions topic in the Juniper Secure Analytics Ariel Query Language Guide.

Filter your search by using the ARIELSERVERS4EPID function with the PARAMETERS REMOTESERVERS or PARAMETERS EXCLUDESERVERS to specify Event Processors by ID and their Ariel servers.

You can use the ARIELSERVERS4EPID function with PARAMETERS REMOTESERVERS and PARAMETERS EXCLUDESERVERS to specify Ariel servers that you want to include or exclude from your search.

You can also use the following query to list Ariel servers by Event Processor ID.

SELECT processorid, ARIELSERVERS4EPNAME(PROCESSORNAME(processorid)) from events.

Returns Ariel servers that are associated with an Event Processor that is identified by ID.

Here's an example of the output for the query, which shows the ID of the processor and the servers for that processor:

For more information, see the AQL data retrieval functions topic in the Juniper Secure Analytics Ariel Query Language Guide.

In an AQL query, you can specify Ariel servers that are connected to a named Event Processor by using the ARIELSERVERS4EPNAME function.

Use the ARIELSERVERS4EPNAME function with PARAMETERS REMOTESERVERS or PARAMETERS EXCLUDESERVERS to specify Ariel servers that you want to include or exclude from your search.

You can also use the following query to list Ariel servers by Event Processor name.

SELECT PROCESSORNAME(processorid), ARIELSERVERS4EPNAME(PROCESSORNAME(processorid)) from events

Here's an example of the output for the query, which shows the name of the processor and the servers:

For more information, see the AQL data retrieval functions topic in the Juniper Secure Analytics Ariel Query Language Guide.

PARAMETERS REMOTESERVERS now includes the option to select servers in your search by specifying the ID or name of Event Processors

By using the ARIELSERVERS4EPNAME function with PARAMETERS REMOTESERVERS, you can specify an Event Processor by name in an AQL query; for example,

By using the ARIELSERVERS4EPID function with PARAMETERS REMOTESERVERS; you can specify an Event Processor by ID in an AQL query, for example,

By specifying an Event Processor, or servers that are connected to that Event Processor, you can run AQL queries faster and more efficiently.

When you have multiple servers in your organization and you know where the data that you're looking for is saved, you can fine-tune the search to just the servers, clusters, or specific servers on Event Processors.

In the following example, you search only the servers that are connected to 'eventprocessor104'.

You can significantly reduce the load on your servers, run the query regularly, and get your results faster when you filter your query to search fewer servers.

For more information, see the AQL data retrieval functions topic in the Juniper Secure Analytics Ariel Query Language Guide.

PARAMETERS EXCLUDESERVERS excludes servers from your AQL search

Avoid having to search all AQL servers by using PARAMETERS EXCLUDESERVERS to exclude specific servers:

  • IP address; for example, PARAMETERS EXCLUDESERVERS=’177.22.123.246:32006,172.11.22.31:32006’

  • Event Processor name; for example, PARAMETERS EXCLUDESERVERS=ARIELSERVERS4EPNAME (’<eventprocessor_name>’)

  • Event Processor ID; for example, PARAMETERS EXCLUDESERVERS=ARIELSERVERS4EPID(<processor_ID>)

Searching only the servers that have the data that you require speeds up searches and uses less server resources.

Refine your query to exclude the servers that don't have the data that you're searching for. In the following example, you exclude servers that are connected to 'eventprocessorABC':

If you refine multiple queries by using PARAMETERS EXCLUDESERVERS, you can reduce the load on your servers and get your results faster.

For more information, see the AQL data retrieval functions topic in the Juniper Secure Analytics Ariel Query Language Guide.

PARSETIMESTAMP function parses the text representation of date and time and converts it to UNIX epoch time

Do time-based calculations easily in AQL when you convert time in text format to epoch time.

Include time-based calculations in your AQL queries and use the time-based criteria that you specify to return events that helps to enhance the security of your organization by making it easier to monitor user activity. For example, you might want to find out that the difference between user logout and re-login times is less than 30 minutes. If this timing seems suspicious, you can investigate further.

For more information, see the AQL data calculation and formatting functions topic in the Juniper Secure Analytics Ariel Query Language Guide.

Retrieve information about the location and distance of IP addresses

Use geographical data that is provided by MaxMind to find information about the location and distance between IP addresses in JSA.

The GEO::LOOKUP AQL function returns location data for a selected IP address.

The GEO::DISTANCE AQL function returns the distance, in kilometers, of two IP addresses.

Easily recognize the geographical origin of your data by organizing your data by location such as city or country instead of by IP address, and use the distance between IP addresses to evaluate the relative distance between your JSA locations.

For more information, see the AQL data retrieval functions topic in the Juniper Secure Analytics Ariel Query Language Guide.

Specify the Event Processor ID in an AQL query by using the ARIELSERVERS4EPID function with PARAMETERS REMOTESERVERS or PARAMETERS EXCLUDESERVERS

In an AQL query, you can include or exclude servers connected to an Event Processor by using the ARIELSERVERS4EPID function to specify the ID of an Event Processor in the query.

For example, include servers on the Event Processor that has the ID 101, PARAMETERS REMOTESERVERS=ARIELSERVERS4EPID(101)

For example, exclude servers on the Event Processor that has the ID 102, PARAMETERS EXCLUDESERVERS=ARIELSERVERS4EPID(102)

For more information, see the AQL data retrieval functions topic in the Juniper Secure Analytics Ariel Query Language Guide.

Specify the Event Processor name in an AQL query by using the ARIELSERVERS4EPNAME function with PARAMETERS REMOTESERVERS or PARAMETERS EXCLUDESERVERS

In an AQL query, you can include or exclude the servers that are connected to an Event Processor by using the ARIELSERVERS4EPNAME function to name an Event Processor in the query. For example, use the ARIELSERVERS4EPNAME function with PARAMETERS REMOTESERVERS to include eventprocessor_ABC in the query.

PARAMETERS REMOTESERVERS=ARIELSERVERS4EPNAME(’eventprocessor_ABC’)

For example, you might want the search to exclude all servers on a named Event Processor by using the ARIELSERVERS4EPNAME function with PARAMETERS EXCLUDESERVERS. In the following example eventprocessor_XYZ is excluded in the query.

PARAMETERS EXCLUDESERVERS=ARIELSERVERS4EPNAME (’eventprocessor_XYZ’)

For more information, see the AQL data retrieval functions topic in the Juniper Secure Analytics Ariel Query Language Guide.

Use the COMPONENTID function to retrieve the ID for any named JSA component and return data for that component.

For example, you can retrieve events for a named Event Processor. In the following example you retrieve events from eventprocessor0:

SELECT * from events where processorid = COMPONENTID(’eventprocessor0’)