Security
Security is top-of-mind, especially right here where Juniper experts share their insights on the latest security trends and breakthroughs
Juniper Employee , Juniper Employee Juniper Employee
Security
Junos Space Security Director - acumen to network management
Jun 21, 2016

The Junos Space Security Director (Event Module) is a combination of a Log Collector Virtual Machine and a Junos Space Application. The components receive and store syslog generated by JUNOS devices, and provides mechanism to do high level queries on the them. The syslog collection and storage happens with the use of Logstash and Elasticsearch. The space application, builds an abstraction over the Log Collector (ElasticSearch) cluster. It also provides mechanism to manage and monitor the Log Collector cluster.

ips-1.jpgf.JPGJunos Space Security Director Dashboad

The Log Collector, works with structured syslog messages from the JUNOS devices. The key value paired information in structured logs are stored and indexed in the Elasticsearch database. The information which JUNOS sends outside of the structured section are dropped.

The Log Collector, exposes RESTful API though Junos Space, the details of the APIs can be found in the REST API reference https://forums.juniper.net/t5/Network-Management/How-To-Junos-Space-Security-Director-Logging-API-re....

The current User Interface exposed through Junos Space Security Director, uses these APIs to visualize important data coming in from the SRX devices. However, the REST interface can directly be access by any other REST client in order to gather and generate information that you are interested in. Some of the example use of the REST are

  1. It can be used to present data coming from syslog in any other space application
  2. To use with a North Bound System, which gathers concise information about attacks on SRX. Though, the Security Director Event Module itself, would be able to provide the responses to aggregated queries on large data, the storage of complete logs has a very high disk space requirement. There may be a case where users may be interested in storing concise information, for example information on spam sources on per day basis. Which can be polled daily and stored in an external high level systems.
  3. It can be useful in tests where in a test scripts can look at the outputs from Security Director, instead of processing on Raw syslogs, APIs can return sum and counts based on criteria
  4. Gather statistics on the with augmented data from syslog, i.e. geo-ip information

Let’s take an example where I want to gather all Attacks or exploits detected, in the network during a given time. The following query would give us information about all attacks with their source and the destination country. 
Here is what we are looking for

  • Event Type: IDP_ATTACK_LOG_EVENT
  • Query: attack-name, source and destination
  • Target: Host in network
  • Request Body: (Refer to the API section)
        {
             "request":{ 
                 "aggregation":"COUNT", 
                 "aggregation-attributes":["attack-name", "src-country-code2", "dst-country-code2"],
                 "time-interval": "2015-07-26T00:00:15+05:30/2015-07-27T20:30:15+05:30",
                 "size":"10",
                 "order":"ascending" 
             }
        }

The system is dependent on device structured logging capabilities. As long as proper structured logs are being fed to the system, it can be utilized to run meaningful queries on data.

Top Kudoed Members