What are the differences between Device ID and device ID+?
Hi everyone, Am reading about Device ID+ recently and I want to know the difference between existing device id on F5 and new device id+ from Shape. Does both works based on Java Script What is there in Device id+ and not in Device ID. Regards SamHow to implement Device ID+ with BIG-IP ASM/AWAF
Hello Everyone, I'm trying to test out Device ID+ with BIG-IP AWAF, I followed this: Clickherefor more information on comprehensive BIG-IP iApp deployment and configuration options. i configured all required firewall rules to allow BIG-IP to connect to (us.gimp.zeronaught.com) Note: i have ASM/AWAF lic only I tired to access the website many times to check if the BIGIP will inject the JS and get the Device ID, before i allow the BIGIP to connect to (us.gimp.zeronaught.com) the script was failing, now status code is 200 This is ASM event log Still Device ID field is N/A, Device ID+ configuration should reflect to Device ID field?? Anyone can help what's wrong? I tired Online verification tool from F5 Thanks, Mohanad
Building a Fraud Profile with Device ID+ (Part 1)
Overview End-to-end architecture for IT fraud and security systems is an opaque space and best practices are usually held within the silos of large corporate cybersecurity teams - and for good reason. Cyber vendors are often the only ones who can connect the dots across customers and find pain points that need to be solved. Luckily for me, I have been able to sit down with security experts across all major industry verticals to discuss those pain points. For years, I have assisted their usage of cybersecurity point solutions (e.g., WAF, Bot, Fraud, etc.) from the perspective of API security, server-side exploits, client-side vulnerabilities, and so on. One piece of technology that is common across all cybersecurity architectures is some form of end user or device identifier. It is the single thread that runs across the entire technology stack and each organization uses it to drive fraud prevention and critical business analytics. Creation of an identifier starts when users interact with an application and provide input to it. Normally this happens when the user logs in, creates a new account, or creates a post or comment. This identifier is typically a traditional cookie from a browser fingerprinting solution created in-house or supplied by a third-party service. It is the way organizations identify and track their users and ultimately how they improve their business. At F5, we help security teams across the world’s top organizations understand their users better. Are they lying about their identity? Are they a known good user? Are they committing fraud, or do they appear to be malicious? We have made a large investment (see Shape Security) in creating an identifier that is based on unique signals and, most importantly, trusted by the security and fraud teams who use it. This identifier is known as Device ID+ and it is now available as a free service to anyone who wants to use it. Device ID+ Device ID+ was created to address the following problems with existing web-based identifiers and fingerprinting solutions: Over 30% of users cannot be tracked due to cookie churn. Frequent changes due to the likelihood that one browser will create multiple identifiers. Identifiers are reset after users clear the cache or go into incognito mode. Device ID+ leverages JavaScript to create an identifier that solves the issues of traditional user tracking through cookies. Developers can include a simple JavaScript tag (as shown in the example code) and use it in their application to determine if a user account is good, bad, encountering a bad user experience, has been compromised, and more. One of the major strengths of Device ID+ is that it persists across users who clear or reset their browser and you’ll have an opportunity to see this in action below. The purpose of this article is to give you a quick rundown on what Device ID+ is, why it’s important, and how to use it within your application. As a demonstration, I am going to inject Device ID+ into an existing login form that uses Google’s reCAPTCHA service. Google reCAPTCHA Google reCAPTCHA is the service that shows you pictures of things to verify that you are human. I am not going to address some of the most critical shortcomings of the reCAPTCHAapproach but since it’s a free service and many websites use it to manage bots, I thought it would make a great example on how Device ID+ can be used to strengthen any existing bot or WAF solution. In later articles we’ll trace Device ID+ from its creation to its consumption in fraud analytics. Preventing Application Abuse Since all users are born or recognized at login, I’m going to start with a simple login form. Login is where most of the fraud and malicious activity start and that’s why reCAPTCHA has been used over the years as a free service to try to prevent abuse. Today we are going to create what’s known as a Fraud Profile with Device ID+ and we’ll use it in later articles to super charge our fraud analytics and gain visibility into things like: Fraudulent behavior of automated bots Fraudulent or malicious posts and commenting Fraudulent user account creation Good user friction and unnecessary CAPTCHA challenges About the Demo Application This is a very simple demo application that shows how to layer Device ID+ into an existing application. See it in action at https://deviceid.dev/v3 If you wish to run this example locally as a Docker container, you can deploy it with the following command after installing Docker: docker run -d -p 80:8000 wesleyhales/deviceid.dev Open a browser and visit: http://localhost/v3 Demo Walkthrough For starters, go ahead and login to the application with your email address or any made-up value for the username. There’s no need to enter a password. Fig. 1-1 After you click Submit, you will see a description of the data that was captured. This is our Fraud Profile (Fig 1-2) that we have created for our users. It uses Device ID+ to encapsulate the reCAPTCHA score along with a timestamp of when the transaction took place. Fig. 1-2 Fraud Profiles are viewed differently across the cybersecurity industry. Some security teams build Fraud Profiles around credit card transaction data and others build them throughout specific flows across web pages. Device ID+ can be applied to any Fraud Profile and is built to be used on every page of the application. The more you use it, the more you can enhance good user experiences and/or eliminate actual fraud. The following JSON shows how the example app adds a reCAPTCHA signal to our Device ID+ Fraud Profile: Example of Device ID+ based Fraud Profile Fig. 1-3 Normally, developers would simply capture the score returned from the server side reCAPTCHA API and take action (0.9 in Fig 1-3 above). This score might be used in the authentication logic within the application, simply allowing the user to login if it’s above 0.7. It might also be sent downstream with additional user data to be recorded in a SIEM. The Device ID+ based Fraud Profile provides a structure around existing “scores” or data. This gives us an extendable framework that is decoupled from existing solutions and makes the identifier technology abstract. In our Fraud Profile, the Device ID+ information is located immediately following the username for a couple of reasons: Now we can identify how many different devices a single username is using. Is this account being shared? Is it compromised? Does it violate our terms of service? All of this can be answered by using Device ID+ under the system wide unique identifier (usually this is the username, or an email address as seen in the example). It also brings visibility to important user experience unknowns. Is this a good user who spends money regularly but is encountering too many reCAPTCHA challenges? It is a way to keep your current bot or fraud verification system in check to ensure friction is removed for your good user interactions. The Differentiator As users log in, they will acquire a new Device ID+ cookie which contains the following values. Fig. 1-4 diA is known as the “residue-based identifier”. It is the main identifier used directly after the username in our example. This value is stored locally on the device and may be deleted if the user clears their local storage or cookies. diB is known as the “attribute-based identifier”. This value will remain the same even when the user clears local storage. Keep in mind, it can change if the user upgrades their browser version as it is based on environment signals that remain consistent across browser versions. One easy way to test this feature is to log into the demo application with the same email address twice but using two different browser sessions. Login once in your regular browser and login again with the same browser in incognito mode. Fig. 1-5 In Figure 1-5, we see that the Device ID+ residue values are different for a single username, but the Device ID+ attribute is the same. Conclusion and Next Steps Now that we understand what makes the Device ID+ identification service unique, we can begin to craft ways to take advantage of it in our business analytics. In part 2 of this article series, we are going to analyze the user data from the live demo at https://deviceid.dev/v3 to visualize anomalies and areas where user friction might be occurring. Device ID+ usage spans a broad set of use cases across the enterprise and is complementary to any existing fraud or bot solutions. If you have input or ideas on how you’d like me to extend this article series, please mention them in the comments below. For more information regarding the technical details around Device ID+, see the documentation here. If you’d like to add Device ID+ to your own application, you can sign up for a free account here.Enhancing Silverline with F5 Device ID+
Setting the Scene If you haven’t heard already, F5 closed out the year of 2020 by announcing a new and completed free of charge service called F5 Device ID+. The free service is available for all F5 customers with up to 20 million devices. This number of 20 million, refers to the number of unique customer devices that visit your Websites, Applications, and Web based Services. The concept of a Device ID isn’t exactly a new thing, but the way it’s delivered by F5, and the fact that it’s offered at no cost, does make it a unique and revolutionary offering. We have already published a board range of information relating to the service, including a Video Introduction, and Introductory page on F5.com, as well as the getting Started documentation on F5 Cloud Docs. There are multiple ways to configure and consume the new F5 Device ID+ service, and the one we wanted to talk about today, was how and why to combine this new capability through the F5 Silverline Security-as-a-Service solution. What is F5 Device ID+? F5 Device ID+ is a real-time, high-precision device identifier that utilizes advanced signal collection and proven machine learning algorithms to assign a unique identifier to each device visiting your site. Deployment is simple, with immediate benefits for the security, networking, fraud, and digital teams. Never has understanding the unique devices visiting your applications been so easy. When each user visits your website, F5 Device ID+ leverages JavaScript to collect information about the browser, device’s OS, hardware, and network configuration. These attributes feed into F5 Device ID+ service built on F5 Shape’s industry-recognized AI and machine learning capabilities. The data is processed in real time, and a unique identifier is assigned to the device, unless it is already a known device. For returning devices, behaviour, actions, and other properties can be recorded, learned, and studied to facilitate the reduction of fraud and a smooth experience for known good users. Further information on the Use Cases for F5 Device ID+ can be found on the Product overview Datasheet What is F5 Silverline? F5 Silverline is a cloud-based security-as-a-service platform. That can be deployed in front of any application or app infrastructure no matter where they reside across the multi cloud world. It can deliver a broad range of services to secure those applications from emerging and sophisticated threats. F5 Silverline is a fully managed service that combines a 24 by 7 security operations center. With an industry leading technology platform. The SOC is populated with over 150 security experts on hand to facilitate policy lifecycle management and to analyze logs with you to look at threats and the mitigation actions instigated to block them. The Service is managed through an Easy to use customer Portal, which provides rich contextual dashboards, and a comprehensive knowledge base for customers wishing to be self-sufficient and maximise their return on investment. At present the Silverline service can be consumed as 3 primary standalone solutions, or combined together for holistic application and infrastructure protection. F5 Silverline DDoS Protection service, provides comprehensive, high performance protection from Distributed Denial of Service (DDoS) attacks, with real-time cloud scrubbing services. F5 Silverline Shape Defense solution, prevents a broad range of online automated fraud to keep your applications and digital assets safe, and Bot Free. F5 Silverline Web Application Firewall service, will help defend your application capital from emerging and sophisticated threats, to ensure business continuity for critical applications and your digital presence. We also have an additional Add on Service for F5 Silverline Threat Intelligence, which integrates dynamic lists of threatening addresses based on IP reputation to give additional context for policy decisions. All of these Services are designed to help organisations tackle the challenges of their digital transformation journey. And as of December 2020, we now also offer the F5 Device ID+ service to all F5 Silverline Customers, in order for the Silverline Cloud to inject the required Javascript in to all HTTPS traffic flow to Applications secured through the Silverline Service. Why enable F5 Device ID+ for F5 Silverline? F5 is the industry leader in Application Delivery and Application Security Services. F5 Silverline is the simplest and most cost effect way to deploy and operated a globally dispersed Application Services solution, and F5 Shape provides the most innovative and comprehensive range of anti-bot and anti-fraud solutions, with a laser focus on effectively identifying devices and their intentions. F5 Silverline provides a zero-effort way to activate and consume the F5 Device ID+ service, powered by the machine learning analysis of Device, Browser, network and environmental signals and telemetry discovered by the F5 Shape Cloud AI engine. Bringing these two great services together is a bit of a no brainer, and existing F5 Silverline customers, can simply flip a Toggle switch to get the HTTPS enabled applications provisioned to start processing traffic in real time, and assigning a unique identifier to every device interacting with your websites and Apps. If you're new to F5 and want to take advantage of this unique combination of Fully Managed Services, you can request a free trial of the F5 Silverline WAF or F5 Silverline Shape Defense at F5.com. How to Onboard Your Silverline Protected Applications with Device ID+ Device ID+ can only be configured on HTTPS services for Applications provisioned as an Application Proxy within the Silverline system. Application proxies are the recommended way to deploy HTTP & HTTPS Services to your protected Web Applications and allow you to take advantage of the Silverline Regional POPs and newer services such as Multi-FQDN configuration and Silverline Shape Defense. More information on the configuration and Application Proxies can be found on the support knowledge base HERE Navigate to the Application Proxy you wish to enable for Device ID+ and follow these steps to activate the configuration: 1.Navigate to the HTTPS Service on the Application Proxy 2.Navigate to the Shape Security Tab 3.Switch the DeviceID+ Toggle to the ON position 4.Fill in the Javascript Insertion Service Configuration section: a.Define the Shape Javascript Path – create a name for the Javascript you want to insert on to the pages i.Must be unique and cannot already be in use in your Application ii.Do Not Use a name that indicated Shape or Silverline in the path b.Define the Javascript Insertion Location – to indicate where you want the Javascript to be inserted in the page i.Before <script> ii.After <head> (our preferred option) iii.After <title> iv.Other – Customer-configured c.Specify any Excluded Paths – Define any HTTP Paths where you do NOT want to insert the F5 DeviceID+ Javascript If you are not able to locate the Shape Security Tab, or the Device ID+ Toggle switch, please contact the Silverline SOC for assistance. Working with an F5 Device ID+ Deployment In order for you to then be able to leverage the F5 Device ID+ identifiers, there will be some work that you need to do in your Application logic. Full details on how to work with this solution can be found on the F5 Cloud Docs website HERE You will find the details of the two unique identifiers the solution creates. residue-based identifier and an attribute-based identifier. The residue-based identifier is based on local storage and cookies. The attribute-based identifier is based on signals collected on the device. The two identifiers always have different values. The residue-based identifier will change whenever local storage is deleted, such as when a user clears cookies. We expect this identifier will have lower persistence and hence high divisions, that is, the same device might appear to have different residue-based identifiers over time. On the other hand, because the residue-based identifier is a sufficiently long random string, there is nearly no chance of collision (that is, when one identifier is shared by more than one device). The attribute-based identifier, based on signals collected from the device, is more persistent in that it will remain the same even when the user clears local storage. However, the attribute-based identifier could change when certain events occur such as a browser update, configuration change, or hardware change. Device ID+ continuously strives to base the identifier on the most persistent of signals, those least likely to change. The attribute-based identifier, however, does not guarantee persistence. It is possible for two devices to share an attribute-based identifier if the devices are sufficiently similar. Again, F5 performs continuous research to collect signals that will minimize collisions. Maximising the use of F5 Device ID+ Your initial thoughts may well be that the solution seems limited in its current form, and that we are asking your development teams to do the heavy lifting, to actually start to leverage the Device identifiers. In some ways this is true, however it’s likely that you are already using some kind of session tracking or device identifier, such as cookies. All we are providing is a more reliable and tamper proof alternative identifier, as part of this free service. This service will enhance your visibility and awareness of the users and devices traversing your websites and application, but the story doesn’t end there. F5 does offer several additional Security solutions that leverage this fundamental Device ID+ to provide advanced Bot Detection, and other anti-fraud capabilities. The F5 Device ID+ service should be seen as a foundational element to your overall security posture. As such, in the very near future, we will be enhancing the F5 Silverline Customer Portal with some additional Dashboard charts built on the Device ID+ Analytics. Future Visibility for Device ID+ in F5 Silverline In the next phase of development, we will be adding additional visibility and analytics gathered from DeviceID+ into the Silverline Dashboards, charts and Statistics. Existing customers can get details as they are released by subscribingto our release notes by following the details in this Support Knowledge Base Article What this means for you The F5 Silverline Portal already provides a very rich set of analytics, performance and security related dashboards, statistics and charts. All aimed at increasing your situational awareness of your Application Security posture. Adding F5 Device ID+ to this already powerful set of analytics, will further enhance your awareness of application traffic, and any potential risks to your infrastructure, Websites, and Services. F5 Silverline delivers Industry leading protection for multi-cloud hosted applications and services. It ensures that Applications stay online and available to improve the end user experience, while delivering business continuity for critical application and digital assets. The Service will help you reduce operating costs in the time and management of Application security, as well as the operational overhead on in-house IT resources and skills, by leveraging the Silverline SOC cyber security experts to augment IT security staff 24x7 The comprehensive mitigation techniques implemented through the F5 Silverline Web Application Firewall service help drive efficiencies in your application security and deliver complete visibility and insight into application attacks. F5 Silverline Shape Defense has been a huge hit with our customers so far, as the zero impact deployments really help demonstrate a rapid return on investment, while reducing the time to achieve and the cost of managing Bot and automate fraud prevention. Adding Device ID+ Dashboard charts will provide unparalleled visibility and reporting for all human, automated and/or bot traffic, while ensuring your applications and digital assets are online and available.
Improving Log Analysis with Device ID Ratios inside Elasticsearch
Overview Ratios Power Context - Log analysis is less about raw numbers than ratios. Ratios put numbers in context. A security analyst follows multiple ratios andgains a sense of what is a healthy range for each ratio, and follows the trend of the ratio over time, knowing that certain changes indicate trouble. As an additional data field in a SIEM system, F5 Device ID+ adds tremendous security value not so much as a raw number, that is how many Device IDs appear in a log over a period,but rather because it factors into so many useful ratios, which we’ll cover in this article. Moreover, these ratios are actionable. You can use F5 Device ID+ to identify the network requests that require further investigation. Within the context of your organization and your apps, each of these ratios will have an organic range of values within which it fluctuates, likely a narrow range. Changes in these ratios, especially sudden changes over hours or days, should raise alerts and trigger further investigation. Goal & Architecture While I was already using HSL (High Speed Logging) to log BIG-IP LTM / AWF related information to ELK Stack and did correlation with help of different Dashboards, the goal was to enrich that log information with a unique Device Identifier to create simple ratios, that can provide strong intel on sudden fluctuations. Simple ratios that can provide strong intel with sudden fluctuations The overall Architecture - where Device ID+ has been onboarded to BIG-IP using the following documented process: Getting started with F5 Device ID+ Building Ratios Example: Single Device accessing unauthorized accounts - Sudden fluctuations in Users per Device ID In this example, the context to create is the number of times a single device accessing unauthorized accounts. Basically, we measure the login success rate for a single device. The login success rate refers to the percentage of login attempts that succeed out of the total of all login attempts. Applications that offer a login can be instrumented to track this metric. If this is not possible, you might be able to make the determination of success versus failure through the web log looking at the request path and the response status code and headers. The login success rate is quite significant. Every app will have an organic rate. A decline in that rate indicates either an attack, either a credential stuffing or brute force attack, or increased login friction. Analyzing the login success rate per Device ID is even more helpful. Investigating requests from Device IDs with particularly low login success rates is likely to uncover attacks. In other words, the success rate itself tells us whether there is an attack while Device ID helps us to locate the source of attack. The visualization within ELK is showing a Unique Device Identifier as well as a Unique IP Address, however, this single device tried to access multiple accounts on an application. Example: Deliberate use of proxy networks - Sudden fluctuations in IPs per Device ID We expect the ratio of IP address per Device ID to be low for desktop computers, higher forlaptops, and highest for mobile devices. Overall, the ratio across all user devices will not varysignificantly over time, especially not suddenly. A sudden change over a short duration, suchan hour or a day, may indicate that some users are deliberately changing their IP addressesthrough the use of proxy networks, a likely signal of an attack. If discovered, investigate thenetwork requests from Device IDs with high numbers of IP addresses. The visualization within ELK is showing a Unique Device Identifier associated with different IP Addresses, however, this single device tried to access multiple accounts on an application. Example: Unusual Devices accessing user accounts - Sudden fluctuations in Device IDs per User We would expect that many users access our site from more than one device. Like the ratio of IPs to Device ID, we would expect the ratio of Device IDs per user to remain fairlystable. Likewise, a sudden change is a red flag. If suddenly more devices than expected areaccessing a user account, it likely indicates an attack. Most likely, not all of those devicesbelong to real users. The visualization within ELK is showing multiple Device Identifier behind a single IP Address trying to access an application unauthorized by using a user account called "OttoGood". Conclusion By collection data into an ELK Stack and by using F5 Device ID+ to enhance your data, you can build ratios and correlations, which are helping to increase your security posture. If you want to onboard F5 Device ID+ and build your own ratios, please visit Getting started with F5 Device ID+
Deploy APM per-request policy and Application Traffic Insight(former Device ID+)
Hi F5 Community, I tried to deploy Application Traffic Insight to APM Zero Trust environment using the JavaScript Tag. But I couldn't find "login.inc" file in per-request policy customization screen on GUI. <Question> Is there any JavaScript Tag insert method in per-request policy? <Test environment> -BIG-IP : v16.1.1 -Module : only APM -Application Traffic Insight deployment method: JavaScript Tag -Zero Trust config name: IAP-single-proxy <Test procedure> 1. Deploy a Zero Trust configuration using Guided Configuration 2.modify "logon.inc" page in per-request policy to add JavaScript Tag But, I couldn't find "logon.inc" page in per-request policices customization menu and APM local directory. # find / -name 'logon.inc' /var/sam/www/client/customization-source/Common/standard/logon/default_logon/de/logon.inc /var/sam/www/client/customization-source/Common/standard/logon/default_logon/zh-tw/logon.inc --- snip --- /opt/.sdm/var/config/rest/iapps/f5-iappslx-access-exchange/nodejs/logon.inc I found out "logon.inc" in "per-SESSION policy" and I could insert a JavaScript Tag and get a correct test result. Thanks, Kenji OmoriBuilding a Fraud Profile with Device ID+ (Part 2 - Analytics and Reporting)
Overview Today there are at least 4.9 million websites using reCAPTCHA, including 28% of the Alexa top 10,000 sites. Google’s reCAPTCHA service is a free offering and developers have been using it for years to try and defend against automation. Many cyber security vendors embed it in their core offering where customers pay subscription service fees for these vendors to “manage” reCAPTCHA and the data it produces. TL;DR - reCAPTCHA is probably causing revenue leakage, false positives and allowing abuse of the web properties that it’s deployed on. How do I know? Watch this demo video I put together the other day. The link is time bookmarked to start at 5:13. The video shows me logging in across 2 different browser sessions and reCAPTCHA returning false positives. Additionally, a simple search on Google or Github reveals the problems that developers face when using reCAPTCHA. reCAPTCHA is embedded into the web’s top sites because it’s free and seems to work. Or does it? What do I mean by “seems to work”? It depends on the business and the type of website, but “works” in this context typically means making the bot or automation problem go away. While developers have been laser focused on solving problems around bot nets, fraudulent users, and overall noise hitting the system, they’ve forgotten about user friction and revenue. In fact, revenue and user friction may be an afterthought for most developers because they don’t see the opportunity to remove friction and again, they have tunnel vision on fixing one particular problem. (For the record I’m not blaming developers, just stating the reality of most engineering organizations and how tasks are managed.) Let’s take a step back. Fraud detection is a framework within web applications and the creation and ongoing maintenance warrants a good bit of architecture and thought. That’s why I’ve been on a pursuit to research and expose the development of a “Fraud Framework” or “Fraud Profile” across the cybersecurity industry. I want to give developers a resource for greenfield projects and rewrites. A place that is open and information flows freely to make the web a safer place. That’s why I started the conversation in Part 1 and I plan on writing as many articles as possible to open up this well-kept secret across the industry. Experienced security engineers are highly sought after because they have been through the pains of developing these systems and architectures. Not only creating them, but making use of the fraud data that they generate. My goal is to make this knowledge freely accessible through this series of articles. This article and video serve as a stepping-stone in my research. In Part 1, we reviewed a simple NodeJS web application that implements a device identifier service to keep the existing fraud system in check, remove user friction and defend against fraudulent activity. The article demonstrates how to add F5’s Device ID+ to an existing application that already uses a basic bot defense or fraud scoring system – in this case reCAPTCHA. Let’s take a look at the live data from our example application deployed at deviceid.dev/v3 to: Analyze user login and transactional scoring data. Understand how well our fraud scoring system is working by looking at good user data. Gain insight into how Device ID+ improves Fraud analytics. Find areas to make changes to our application to remove user friction. Conclusion and Next Steps The example analysis of our Fraud Profile is just the beginning of what can be accomplished with a trustable device identifier. Analytics around user behavior and malicious intent can now be uncovered in new ways in fraud reporting. Device ID+ usage spans a broad set of use cases across the enterprise and is complementary to any existing fraud or bot solutions. If you have input or ideas on how you’d like me to extend this article series, please mention them in the comments below. For more information regarding the technical details around Device ID+, see the documentationhere. If you’d like to add Device ID+ to your own application, you can sign up for a free accounthere.
