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?
- Janrain SIEM Integration: Technical Specifications
- Setting Up and Configuring Janrain SIEM Integration
- Janrain SIEM Integration Event Types
- Janrain SIEM Integration Data Formats
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:
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.
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.
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.
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:
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=18.104.22.168 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:
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:
|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:
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:
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:
|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.||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=22.214.171.124 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=126.96.36.199||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=188.8.131.52 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=184.108.40.206||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).|