Janrain SIEM Integration

Cybersecurity and data security have become major priorities for organizations, and for good reason. In just the past two years, there have been scores of major data breaches affecting organizations such as:

  • Yahoo!, which compromised personal information for as many as 3 billion user accounts.
  • Equifax, which exposed names, social security numbers, driver’s licenses, and credit card numbers for an estimated 143 million people.
  • Edmodo, where hackers made off with approximately 78 million customer names, email addresses, and hashed passwords. That data was eventually listed for sale online for just over $1,000.

Sadly, the list goes on. And on.

So what can organizations do to prevent, or to at least minimize, cyber-attacks? One important tool in the battle to keep networks, computers, and data safe is SIEM: Security Information and Event Management. SIEM systems (such as Splunk Enterprise Security, IBM Security QRadar SIEM, and ArcSight Enterprise Security Manager) are designed to:

  • Import log files from multiple devices (with “devices” meaning anything from computers to software to other types of hardware).
  • “Normalize” these disparate log files into a single standardized format.
  • Provide tools for real-time (or near real-time) incident detection and trend analysis, and to do so across an organization’s entire spectrum of devices.

For example, by analyzing log files a SIEM system might detect an out-of-the-ordinary flurry of login attempts, an unusual occurrence that might signal the onset of a denial of service attack. By itself SIEM software cannot prevent the attack. However, by alerting you to the situation in near real-time, SIEM enables you to take action that does prevent the attack, or at least enables you to stop the attack and limit any damage.

With the release of Janrain SIEM Integration, Janrain joins the list of vendors that export SIEM events and SIEM event data. As you know, Janrain’s Customer Identity and Access Management (CIAM) solutions revolve around user activities such as logins, registrations, user profile updates, and password resets. Because of this, Janrain is uniquely positioned to report not just on the fact that a person has logged on to the system, but that a specific person, from a specific IP address, and using a specific web browser, has logged on to the system. Is that a problem in and of itself? Of course not. But if someone from a specific IP address is in the process of creating multiple accounts, one right after another, well, that could be a very different story. That’s the kind of problem that Janrain SIEM Integration can identify. Janrain SIEM helps provide protection against such problems as:

  • Credential compromise
  • Account takeovers
  • Stolen identity
  • Spoofed identity
  • Fraudulent account creation
  • Brute force attacks
  • Data scraping
  • Inappropriate or excessive use

This documentation introduces you to Janrain SIEM Integration. To that end, the documentation explores the following topics:

What Exactly is SIEM and SIEM Integration

Security Information and Event Management is a standardized way of collecting and aggregating security and event information. For Janrain customers, SIEM works like this:

  1. Janrain constantly monitors the Janrain SIEM event stream, looking for Janrain-related activities such as logins, registrations, password changes, etc. Each time one of these events occurs (for example, each time a user successfully logs in) information about the event (who logged on, when they logged on, where they logged, etc.) is recorded.

  2. Event information is then forwarded to one of two places, in one of two ways. If an organization wants real-time delivery of events (that is, they want to know about each event as soon as it occurs), event information is forwarded to a webhook, then delivered to the organization. (Webhooks, also known as user-defined HTTP callbacks, provide a way for information to be delivered any time a specified event takes place.)

    Alternatively, organizations can have event information delivered at regularly-scheduled intervals. For example, an organization might decide to receive SIEM events every 10 minutes. In that case, all the Janrain-related events that occur in the next 10 minutes are stored in an SFTP server queue. When the 10 minutes are up, those events are delivered, the queue is cleared, and Janrain SIEM Integration begins storing the next batch of events.

  3. Events are received by the customer. The exact mechanism for event receipt will vary depending on both the delivery method (webhook or batch) and on the organization’s SIEM software. Real-time event delivery (webhooks) usually involves an API server, a message queue, or an HTTP server. Batch delivery (scheduled delivery) typically relies on an SFTP server or a file receiver. Organizations will work with their Janrain representative to determine their optimal delivery method.

  4. Events are imported into your SIEM software and analyzed. Organizations use the data in the way that works best for them: for example, you determine the things you want to look for, you determine what does and does not represent anomalous behavior, and you determine what triggers an alert and what does not.

The entire process is summarized in the following diagram:

 The Janrain SIEM Process


Keep in mind that Janrain does not provide tools for importing and analyzing SIEM events; for that, you will need third-party tool software as Splunk or QRadar. What Janrain provides is detailed information about activities such as logins, registrations, password or email changes, etc. For example, for each “traditional” login (i.e., a user logging on with a username and password) Janrain issues an event notification similar to this:

LEEF:2.0|Janrain|Universal SIEM Integration|1.2|traditional_signin|
sev=5 proto=HTTPS cat=admin url=https://myapp.janrain.com/oauth/auth_native_traditional src=1.1.1.1 
userAgent=Mozilla/5.0 (X11; Fedora; Linux x86_64) usrName=2b565a0c-a863-11e7-abc4-cec278b6b50a devTime=Jan 01 1979 18:00:00 
devTimeFormat=MMM dd yyyy HH:mm:ss

That file can then be imported into a SIEM analysis tool such as Splunk:

 SIEM Software Example


Janrain SIEM Integration supports two standard SIEM file formats: the Common Event Format (CEF) and the Log Event Extended Format (LEEF). Data can be retrieved in near real-time by using webhooks, or can be scheduled for regular deliveries using a secure FTP (SFTP) server. Depending on your needs and on your SIEM platform, Janrain’s SIEM integrations can use various delivery mechanisms such as message queues, APIs, HTTP receivers, or file receivers.

Janrain SIEM Integration Technical Specifications

Technical specifications for Janrain SIEM Integration are summarized as follows:

Specification Description
Protocol SFTP (Secure File Transfer Protocol). SFTP uses Secure Shell (SSH) to authenticate and establish secure network connections.
Supported Formats Format of the data payload sent to client-provided endpoint. Allowed values are: Common Event Format (CEF) Version 0; and, Log Event Extended Format (LEEF) Version 2.
Character Encoding UTF-8, a standard method for encoding Unicode characters.
Minimum Log Upload Interval Minimum interval at which SIEM event log files are uploaded to an SFTP server. The default value is 1 minute.
Maximum Log Upload Interval Maximum interval at which SIEM event log files are uploaded to an SFTP server. The default value is 1 day.
Filename Format Filename pattern for event log files uploaded to SFTP server.

The filename pattern looks like this:

JANRAIN_SIEM_APP_ID_TIME_STAMP.log

In this pattern, TIME_STAMP is the number of UTC milliseconds since the Unix epoch. In the case of batch delivery, this value is derived from the timestamp of the first message in the batch.

In case you’re wondering, the Unix epoch represents the number of seconds that have elapsed since midnight on January 1, 1970 UTC (Coordinated Universal Time). For example, shortly before 8:00 AM on December 14, 2017 (Pacific Standard Time) the Unix epoch stood at 1513266008000 seconds. To determine the number of milliseconds in the Unix epoch, multiply the number of seconds by 1000: 1513266008000 x 1000 = 1513266008000000 milliseconds.

Assuming you have the application ID htb8fuhxnf8e38jrzub3c7pfrr, that means that the log file for December 14, 2017 would have this name:

JANRAIN_SIEM_htb8fuhxnf8e38jrzub3c7pfrr_1513266008000000.log

Setting Up and Configuring Janrain SIEM Integration

You will work with your Janrain representative to determine the optimal way to deploy SIEM Integration; this determination will be based on both your needs and your infrastructure. As a general rule, you configure your SIEM software; meanwhile, Janrain support personnel will configure the SIEM implementation and set up an SFTP server for your organization’s exclusive use.

Each organization will have a separate SIEM Integration project and configuration file; the configuration file is used to manage event delivery. At the present time, the configuration file is not exposed to organizations: if you want to make a change to your configuration file you will need to ask Janrain to make that modification. The file itself contains the following settings:

Setting Name Description Default Value Required
remote_host Remote hostname or IP address. Yes
remote_port Remote host TCP port. 22 No
remote_username Remote host username. No
remote_password Remote host password. No
rsa_key Private RSA key for authentication with Janrain’s SFTP server. Yes
remote_dir Local path where log files will be uploaded. / No
upload_interval Time interval (in minutes) for logs to be uploaded to the SFTP server. 15 No
event_format Data format for SIEM events (can be CEF or LEEF). CEF 15

Contact your Janrain representative for more information.

Janrain SIEM Integration Event Types

Janrain SIEM Integration reports the events shown in the table that follows. Additional event types are likely to be added in future releases of the product; for example, a future release might report logoffs as well as logins.

All Janrain events have a Severity rating of 5. That’s because Janrain events are, for the most part, neutral: by itself, a user logging on by using social sign-in simply means that, well, a user has logged on by using social sign-in. Janrain SIEM events only become important when viewed in aggregate. A user logging on to the system is not a problem; you probably want users to log on the system. But the same user UUID logging on to the system 100 times in the past few minutes could be a different story. Similarly, 300 password changes in the last hour – when, on a typical day, you would expect 1 or 2 password changes per hour – could indicate another problem. With Janrain, there is no single event – Core reactor breached! – that sets off warning bells. Instead, you will look for anomalous patterns of behavior and unusual trends in activity.

Note, too that Janrain SIEM Integration focuses on successful events: a user successfully registered by using social login, a user successfully logged on by using a user name and password. For now, Janrain SIEM Integration does not report on unsuccessful events: the SIEM report will not tell you that, in the past half hour, 1,000 people have unsuccessfully tried to log on to the system. Janrain does monitor for that type of activity, and takes measures to prevent brute force and denial of service attacks. But that type of monitoring, and that type of reporting, is separate from SIEM Integration.

Here are the current Janrain SIEM event types:

Event ID Description Category Severity
traditional_signin An end user or administrator successfully authenticated by using Janrain-stored credentials (email address and password). identity 5
social_signin An end user or administrator successfully authenticated by using a third-party identity provider (IDP). identity 5
traditional_register An end user or administrator successfully registered by using Janrain-stored credentials. identity 5
social_register An end user or administrator successfully registered by using a third-party identity provider. identity 5
sso_signin An end user was automatically authenticated by using single sign-on (SSO). This would occur because the user either (1) visited a new website within the collection of sites using SSO; or, (2) had their SSO access token refreshed by a previously-visited site. identity 5
profile_create A new user profile database record was created. This event is fired with registration events. profile 5
profile_update A user profile database record was updated. This event is fired with numerous other events; for example, each successful login updates the lastLogin attribute of a user profile. profile 5
profile_delete A user profile database record was deleted. profile 5
config_change A customer configuration value was changed by using Janrain’s configuration APIs. admin 5
password_reset An end user or administrator successfully reset their password. identity 5
email_verified An end user or administrator successfully verified their email address. identity 5
email_sent A system-generated email was sent in response to end user activity such as password reset, email verification, or registration. email 5

Janrain SIEM Integration Data Formats

Janrain SIEM Integration supports two standard formats for information delivery: the Common Event Format (CEF) and the Log Event Extended Format (LEEF). Most SIEM platforms support at least one of these file formats. If your’s does not, and if you are still interested in Janrain SIEM Integration, contact your Janrain representative.

Common Event Format (CEF)

The Common Event Format (CEF) was developed by ArcSight as a way to standardize event logging. A CEF file generated by Janrain SIEM Integration looks similar to this:

CEF:0|Janrain|Universal SIEM Integration|1.2|traditional_signin|Traditional Sign In|
5|app=HTTPS cat=admin request=https://myapp.janrain.com/oauth/auth_native_traditional src=1.1.1.1 shost=host.domain.com requestClientApplication=Mozilla/5.0 (X11; Fedora; Linux x86_64)
 suid=2b565a0c-a863-11e7-abc4-cec278b6b50a rt=Jan 01 1979 18:00:00

In turn, that file can be parsed as shown in the following table:

File Data CEF Field Name Description
CEF:0 CEF Version Common Event Format version number used to construct the data file. Analytics programs use the CEF Version when uploading and parsing a file.
Janrain Device Vendor Vendor responsible for producing the CEF file. The combination of the device vendor and the device product must be unique. In this case, the unique identifier is Janrain Universal SIEM Integration (Janrain + Universal SIEM Integration).
Universal SIEM Integration Device Product Product that produced the CEF file. The combination of the device vendor and the device product must be unique. In this case, the unique identifier is Janrain Universal SIEM Integration (Janrain + Universal SIEM Integration).
1.2 Device Version Version number of the product.
traditional_signin Signature ID Unique identifier for the event. For a complete list of Janrain event types, see Janrain SIEM Event Types.
Traditional Sign In Name Human readable – and understandable – name for the event. A Signature ID can be anything, even a UUID (8553193a-9f6c-4cc4-8ac2-8326b6aec5bf). By comparison, the Name is simple and easy to understand: Traditional Sign In.
5 Severity Importance of the event. Severities can be any integer value from 0 to 10 (inclusive), with 0 representing the least important event and 10 the most important event. Severities are commonly grouped as follows: Severities 0-3 = Low; Severities 4-6 = Medium; Severities 7-8 = High; Severities 9-10 = Very High.
app=HTTPS applicationProtocol Application level protocol associated with the event; for example, HTTP, HTTPS, Telnet, POP, IMAP, etc.
cat=admin deviceEventCategory Category assigned to the event by the product. There is no universal standard for event categories; categories are typically product-specific.
request=https://myapp.janrain.com/oauth/auth_native_traditional requestURL URL accessed at the time that the event occurred.
src=1.1.1.1 sourceAddress IP address of the computer where the event occurred.
shost=host.domain.com sourceHostName Fully qualified domain name of the computer where the event occurred.
requestClientApplication=Mozilla/5.0 (X11; Fedora; Linux x86_64) requestClientApplication User agent for the client application employed when the event occurred. For Janrain events, the user agent typically identifies the web browser in use when the event took place.
suid=2b565a0c-a863-11e7-abc4-cec278b6b50a sourceUserId UUID of the user responsible for the event.
rt=Jan 01 1979 18:00:00 receiptTime Date and time when the event occurred. The datetime value is expressed using the format MMM DD YYYY HH:MM:SS (Month Day Year Hour:Minute:Seconds).

Log Event Extended Format (LEEF)

The Log Event Extended Format (LEEF) was developed for use with IBM’s QRadar analytics software; however, LEEF is an open standard that can be, and is, used by other SIEM platforms. A Janrain-generated LEEF file looks similar to this:

LEEF:2.0|Janrain|Universal SIEM Integration|1.2|traditional_signin|sev=5 proto=HTTPS cat=admin 
url=https://myapp.janrain.com/oauth/auth_native_traditional src=1.1.1.1 userAgent=Mozilla/5.0 (X11; Fedora; Linux x86_64) 
usrName=2b565a0c-a863-11e7-abc4-cec278b6b50a devTime=Jan 01 1979 18:00:00 devTimeFormat=MMM dd yyyy HH:mm:ss

The LEEF file is explained in the following table:

File Data LEEF Field Name Description
LEEF:2.0 LEEF Version Log Event Extended Format version number used to construct the data file. Analytics programs use the LEEF Version when uploading and parsing a file.
Janrain Vendor Vendor responsible for producing the LEEF file. The combination of the vendor and the product name must be unique. In this case, the unique identifier is Janrain Universal SIEM Integration (Janrain + Universal SIEM Integration).
Universal SIEM Integration Product Name Name of the product that produced the LEEF file. The combination of the vendor and the product name must be unique. In this case, the unique identifier is Janrain Universal SIEM Integration (Janrain + Universal SIEM Integration).
1.2 Product Version Version number of the product.
traditional_signin EventID Unique identifier for the event. For a complete list of Janrain event types, see Janrain SIEM Event Types.
sev=5 sev Importance of the event. Severities can be any integer value from 0 to 10 (inclusive), with 0 representing the least important event and 10 the most important event. Severities are commonly grouped as follows: Severities 0-3 = Low; Severities 4-6 = Medium; Severities 7-8 = High; Severities 9-10 = Very High.
proto=HTTPS proto Application level protocol associated with the event; for example, HTTP, HTTPS, Telnet, POP, IMAP, etc.
cat=admin cat Category assigned to the event by the device product. There is no universal standard for event categories; categories are typically product-specific.
url=https://myapp.janrain.com/oauth/auth_native_traditional url URL accessed at the time that the event occurred.
src=1.1.1.1 src IP address of the computer where the event occurred.
userAgent=Mozilla/5.0 (X11; Fedora; Linux x86_64) userAgent User agent for the client application employed when the event occurred. For Janrain events, the user agent typically identifies the web browser in use when the event took place.
usrName=2b565a0c-a863-11e7-abc4-cec278b6b50a usrName UUID of the user responsible for the event.
devTime=Jan 01 1979 18:00:00 devTime Date and time when the event occurred.
devFormat=MMM dd yyyy HH:mm:ss devTimeFormat Format used when expressing datetime values. For Janrain Universal SIEM Integration, the datetime format is MMM dd yyyy HH:mm:dd (Month Day Year Hour:Minute:Seconds).
Scroll ↓