OWASP Tactical Access Defense Series: Broken Object Property Level Authorization and BIG-IP APM
AUTHOR NOTE: Unauthorized access to private/sensitive object properties may result in data disclosure, data loss, or data corruption. Under certain circumstances, unauthorized access to object properties can lead to privilege escalation or partial/full account takeover. In this article we are going through API3 item from OWASP top 10 API Security risks exploring BIG-IP Access Policy Manager (APM) role in our arsenal. Identifying Vulnerable APIs In order to identify the API endpoint is vulnerable to Broken Object Property Level Authorization, Sensitive properties exposure of certain object for non-intended user (Excessive Data Exposure). import requests # Assuming the API endpoint for retrieving user data is /api/users api_endpoint = "https://example.com/api/users" # Sending a GET request to the API endpoint response = requests.get(api_endpoint) # Checking if the request was successful (status code 200) if response.status_code == 200: # Printing the response content (which could contain excessive data) print(response.json()) else: print("Failed to retrieve data from the API") API allow to change, add or delete sensitive object property for non-intended user (Mass assignment). import requests # Assuming the API endpoint for updating user information is /api/users api_endpoint = "https://example.com/api/users" # Malicious payload containing additional fields malicious_payload = { "username": "malicious_user", "password": "password123", "isAdmin": True # Malicious user attempts to elevate privileges } # Sending a POST request with the malicious payload response = requests.post(api_endpoint, json=malicious_payload) # Checking if the request was successful (status code 200) if response.status_code == 200: print("User information updated successfully") else: print("Failed to update user information") Object Property Level Authorization involves controlling access to specific properties or attributes of an object within a system. Instead of granting blanket access to an entire object, this approach enables fine-grained control, allowing administrators to restrict or permit access to individual properties based on user roles or permissions. While implementing protection against such security risk involves different aspects, one is making sure the user is authorized to access object property, and here BIG-IP APM plays crucial role. Mitigating Risks with BIG-IP APM BIG-IP APM per-request granularity. With per-request granularity, organizations can dynamically enforce access policies based on various factors such as user identity, device characteristics, and contextual information. This enables organizations to implement fine-grained access controls at the API level, mitigating the risks associated with Broken Object Property Level Authorization. Key Features: Dynamic Access Control Policies: BIG-IP APM empowers organizations to define dynamic access control policies that adapt to changing conditions in real-time. By evaluating each API request against these policies, BIG-IP APM ensures that only authorized users can access specific resources and perform permitted actions. Granular Authorization Rules: BIG-IP APM enables organizations to define granular authorization rules that govern access to individual objects or resources within the API ecosystem. By enforcing strict authorization checks at the object level, F5 APM prevents unauthorized users from tampering with sensitive data or performing unauthorized actions. Conclusion In conclusion, BIG-IP APM per-request granularity is a powerful tool for defending against Broken Object-Level Authorization vulnerabilities in APIs. By enforcing fine-grained access controls at the API level, organizations can mitigate the risks associated with unauthorized access to sensitive data. Additionally, proactive security assessments and vulnerability scans are essential for identifying and addressing vulnerabilities in APIs, thereby strengthening overall security posture in the digital ecosystem. Related Content F5 BIG-IP Access Policy Manager | F5 Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10 API Protection Concepts OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10 OWASP Tactical Access Defense Series: Broken Object Level Authorization and BIG-IP APM F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller) OWASP Tactical Access Defense Series: Broken Authentication and BIG-IP APM
How to limit access by time?
Dear community, I need to handle requests for a particular domain in a different way. I usually apply a few simple conditions, for example, requests must arrive with the xpto.com header to be forwarded to the pool. I use a BIG-IP LTM 13.0.0. Now I need a particular domain, if it is called more than 50 times in 10 minutes by a same IP, block this IP for 30 minutes. From what I've been researching I believe that the FLOW_INIT function helps me with what I need, but I still can not reach my goal. Below is a simple example of what I use to test: when HTTP_REQUEST { if {[HTTP::host] equals "drop.test:8080"} { switch -glob [HTTP::uri] { "/test/*" { log local0. "/test/ - accept - source: [IP::remote_addr] - uri: [HTTP::host][HTTP::uri]" HTTP::respond "Test ok!" } "/drop/*" { log local0. "/drop/ - accept - source: [IP::remote_addr] - uri: [HTTP::host][HTTP::uri]" HTTP::respond "Drop ok!" } default { log local0. "reject - source: [IP::remote_addr] - uri: [HTTP::host][HTTP::uri]" reject } } } }
Is blocking all HTTP-HEAD requesta a bad idea?
We think about blocking all HTTP Head requests for our Web-Applications (not REST or SOAP) via ASM, by returning a html response page with HTTP-code 200 OK, because most of them are requests from crawlers. Are there experiences concerning client behavior? Since HTTP-200 is returned, the client thinks that the request ist valid, even if the site doesn't exists. For Office-Doks, which constain invalid web links the user doesn't get a info popup which tells him that the ressource doesn't exists, instead the web-client is opened which then sends a HTTP-GET to a non existing ressource. For me it doesn't sound like a major drawback. Are there any other pitfalls known?
Inspect POST Request for Existence of Username Parameter
Is it possible to to check if a username has been provided in a POST request? Could this be done via HTTP::username command or would a HTTP::collect be needed to inspect the payload of the request? Would you be able to provide an example of how this might be done via an Irule.
Access allowed when it should be denied
Hi guys I'm implementing APM in a customer environment and now we caught in a problem that the customer has an URL that I use APM to authenticate and then check the group, if the group is approved the access will be permitted. It's working as expected too. But, if another user try to log in to the application using the same machine the access is allowed even the user isn't inside the permitted group. Is possible to check this again ?ICSA Certified Network Firewall for Data Centers
The BIG-IP platform is now ICSA Certified as a Network Firewall. Internet threats are widely varied and multi-layered. Although applications and their data are attackers’ primary targets, many attackers gain entry at the network layer. Internet data centers and public-facing web properties are constant targets for large-scale attacks by hacker/hactivist communities and others looking to grab intellectual property or cause a service outage. Organizations must prepare for the normal influx of users, but they also must defend their infrastructure from the daily barrage of malicious users. Security administrators who manage large web properties are struggling with security because traditional firewalls are not meeting their fundamental performance needs. Dynamic and layered attacks that necessitate multiple-box solutions, add to IT distress. Traditional firewalls can be overwhelmed by their limited ability to scale under a DDoS attack while keeping peak connection performance for valid users, which renders not only the firewalls themselves unresponsive, but the web sites they are supposed to protect. Additionally, traditional firewalls’ limited capacity to interpret context means they may be unable to make an intelligent decision about how to deliver the application while also keeping services available for valid requests during a DDoS attack. Traditional firewalls also lack specialized capabilities like SSL offload, which not only helps reduce the load on the web servers, but enables inspection, re-encryption, and certificate storage. Most traditional firewalls lack the agility to react quickly to changes and emerging threats, and many have only limited ability to provide new services such as IP geolocation, traffic redirection, traffic manipulation, content scrubbing, and connection limiting. An organization’s inability to respond to these threats dynamically, and to minimize the exposure window, means the risk to the overall business is massive. There are several point solutions in the market that concentrate on specific problem areas; but this creates security silos that only make management and maintenance more costly, more cumbersome, and less effective. The BIG-IP platform provides a unified view of layer 3 through 7 for both general and ICSA required reporting and alerts, as well as integration with SIEM vendors. BIG-IP Local Traffic Manager offers native, high-performance firewall services to protect the entire infrastructure. BIG-IP LTM is a purpose-built, high-performance Application Delivery Controller designed to protect Internet data centers. In many instances, BIG-IP LTM can replace an existing firewall while also offering scale, performance, and persistence. Performance: BIG-IP LTM manages up to 48 million concurrent connections and 72 Gbps of throughput with various timeout behaviors, buffer sizes, and more when under attack. Protocol security: The BIG-IP system natively decodes IPv4, IPv6, TCP, HTTP, SIP, DNS, SMTP, FTP, Diameter, and RADIUS. Organizations can control almost every element of the protocols they’re deploying. DDoS prevention capabilities: An integrated architecture enables organizations to combine traditional firewall layers 3 and 4 with application layers 5 through 7. DDoS mitigations: The BIG-IP system protects UDP, TCP, SIP, DNS, HTTP, SSL, and other network attack targets while delivering uninterrupted service for legitimate connections. SSL termination: Offload computationally intensive SSL to the BIG-IP system and gain visibility into potentially harmful encrypted payloads. Dynamic threat mitigation: iRules provide a flexible way to enforce protocol functions on both standard and emerging or custom protocols. With iRules, organizations can create a zero day dynamic security context to react to vulnerabilities for which an associated patch has not yet been released. Resource cloaking and content security: Prevent leaks of error codes and sensitive content. F5 BIG-IP LTM has numerous security features so Internet data centers can deliver applications while protecting the infrastructure that supports their clients and, BIG-IP is now ICSA Certified as a Network Firewall. ps Resources: F5’s Certified Firewall Protects Against Large-Scale Cyber Attacks on Public-Facing Websites F5 BIG-IP Data Center Firewall – Overview BIG-IP Data Center Firewall Solution – SlideShare Presentation High Performance Firewall for Data Centers – Solution Profile The New Data Center Firewall Paradigm – White Paper Vulnerability Assessment with Application Security – White Paper Challenging the Firewall Data Center Dogma Technorati Tags: F5, big-ip, virtualization, cloud computing, Pete Silva, security, icsa, iApp, compliance, network firewall, internet, TMOS, big-ip, vCMPIn 5 Minutes or Less Video - BIG-IP APM & Citrix XenApp
Watch how F5 customers can now simply use BIG-IP Access Policy Manager or BIG-IP Edge Gateway to consolidate access control in a central location, keeping infrastructure administration concerns to a minimum. With BIG-IP solutions, customers enjoy the flexibility and scalability needed to extend Citrix applications to both local and remote users without changing local XenApp deployments or requiring STA to provide secure remote access to applications. Highlights of deploying Citrix and F5 technologies together include: Reduced Management Time and OpEx – By simplifying and centralizing local and remote access authentication, BIG-IP solutions eliminate the need for customers to add separate Citrix STA infrastructure or make changes to existing Web Interface servers, resulting in an environment that is less expensive to deploy and requires less time to manage. Simplified Configuration and Deployment – With BIG-IP solutions, administrators can support users of Citrix applications with fewer devices, configure deployments to support flexible access models, and easily scale the environment. This fully integrated functionality makes it quick and easy for customers to set up and deploy local and remote access capabilities for Citrix applications, keeping users productive. Centralized and Comprehensive Access Control – Unlike the separate Citrix products required to adequately support applications for remote users, BIG-IP solutions provide centralized application access control and use a single access policy to support all types of users securely, so IT teams can be confident that application access is aligned with the organizations’ specific business priorities and security policies. &amplt;/p&ampgt; &amplt;p&ampgt;ps&amplt;/p&ampgt; &amplt;p&ampgt;Resources:&amplt;/p&ampgt; &amplt;ul&ampgt; &amplt;li&ampgt;&amplt;a href="http://www.f5.com/news-press-events/press/2010/20101214.html" _fcksavedurl="http://www.f5.com/news-press-events/press/2010/20101214.html"&ampgt;F5 Simplifies and Centralizes Access Management for Citrix Applications&amplt;/a&ampgt; &amplt;/li&ampgt; &amplt;li&ampgt;&amplt;a href="downloads.f5.com" _fcksavedurl="downloads.f5.com"&ampgt;BIG-IP v10.2.1 Download (Log in required)&amplt;/a&ampgt; &amplt;/li&ampgt; &amplt;li&ampgt;&amplt;a href="http://www.f5.com/products/big-ip/access-policy-manager.html" _fcksavedurl="http://www.f5.com/products/big-ip/access-policy-manager.html"&ampgt;BIG-IP Access Policy Manager&amplt;/a&ampgt; &amplt;/li&ampgt; &amplt;li&ampgt;&amplt;a href="http://www.f5.com/products/big-ip/edge-gateway.html" _fcksavedurl="http://www.f5.com/products/big-ip/edge-gateway.html"&ampgt;BIG-IP Edge Gateway&amplt;/a&ampgt; &amplt;/li&ampgt; &amplt;li&ampgt;&amplt;a href="https://www.youtube.com/user/f5networksinc" _fcksavedurl="https://www.youtube.com/user/f5networksinc"&ampgt;F5 YouTube Channel&amplt;/a&ampgt; &amplt;/li&ampgt; &amplt;/ul&ampgt; &amplt;table border="0" cellspacing="0" cellpadding="2" width="325"&ampgt;&amplt;tbody&ampgt; &amplt;tr&ampgt; &amplt;td valign="top" width="200"&ampgt;Connect with Peter: &amplt;/td&ampgt; &amplt;td valign="top" width="123"&ampgt;Connect with F5: &amplt;/td&ampgt; &amplt;/tr&ampgt; &amplt;tr&ampgt; &amplt;td valign="top" width="200"&ampgt;&amplt;a href="http://www.linkedin.com/pub/peter-silva/0/412/77a" _fcksavedurl="http://www.linkedin.com/pub/peter-silva/0/412/77a"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_linkedin[1]" border="0" alt="o_linkedin[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_linkedin.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_linkedin.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt; &amplt;a href="https://devcentral.f5.com/s/weblogs/psilva/Rss.aspx" _fcksavedurl="https://devcentral.f5.com/s/weblogs/psilva/Rss.aspx"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_rss[1]" border="0" alt="o_rss[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_rss.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_rss.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt; &amplt;a href="http://www.facebook.com/f5networksinc" _fcksavedurl="http://www.facebook.com/f5networksinc"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_facebook[1]" border="0" alt="o_facebook[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt; &amplt;a href="http://twitter.com/psilvas" _fcksavedurl="http://twitter.com/psilvas"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_twitter[1]" border="0" alt="o_twitter[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt; &amplt;/td&ampgt; &amplt;td valign="top" width="123"&ampgt; &amplt;a href="http://www.facebook.com/f5networksinc" _fcksavedurl="http://www.facebook.com/f5networksinc"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_facebook[1]" border="0" alt="o_facebook[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_facebook.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt; &amplt;a href="http://twitter.com/f5networks" _fcksavedurl="http://twitter.com/f5networks"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_twitter[1]" border="0" alt="o_twitter[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_twitter.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt; &amplt;a href="http://www.slideshare.net/f5dotcom/" _fcksavedurl="http://www.slideshare.net/f5dotcom/"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_slideshare[1]" border="0" alt="o_slideshare[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_slideshare.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_slideshare.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt; &amplt;a href="https://www.youtube.com/f5networksinc" _fcksavedurl="https://www.youtube.com/f5networksinc"&ampgt;&amplt;img style="border-right-width: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px" title="o_youtube[1]" border="0" alt="o_youtube[1]" src="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_youtube.png" _fcksavedurl="https://devcentral.f5.com/s/weblogs/images/devcentral_f5_com/weblogs/macvittie/1086440/o_youtube.png" width="24" height="24" /&ampgt;&amplt;/a&ampgt;&amplt;/td&ampgt; &amplt;/tr&ampgt; &amplt;/tbody&ampgt;&amplt;/table&ampgt; &amplt;p&ampgt;Technorati Tags: &amplt;a href="http://technorati.com/tags/F5" _fcksavedurl="http://technorati.com/tags/F5"&ampgt;F5&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/in+5+minutes" _fcksavedurl="http://technorati.com/tags/in+5+minutes"&ampgt;In 5 Minutes&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/integration" _fcksavedurl="http://technorati.com/tags/integration"&ampgt;integration&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/bigip" _fcksavedurl="http://technorati.com/tags/bigip"&ampgt;big-ip&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/Pete+Silva" _fcksavedurl="http://technorati.com/tags/Pete+Silva"&ampgt;Pete Silva&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/security" _fcksavedurl="http://technorati.com/tags/security"&ampgt;security&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tag/business" _fcksavedurl="http://technorati.com/tag/business"&ampgt;business&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tag/education" _fcksavedurl="http://technorati.com/tag/education"&ampgt;education&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tag/technology" _fcksavedurl="http://technorati.com/tag/technology"&ampgt;technology&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/application+delivery" _fcksavedurl="http://technorati.com/tags/application+delivery"&ampgt;application delivery&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/citrix" _fcksavedurl="http://technorati.com/tags/citrix"&ampgt;citrix&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/cloud" _fcksavedurl="http://technorati.com/tags/cloud"&ampgt;cloud&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/context-aware" _fcksavedurl="http://technorati.com/tags/context-aware"&ampgt;context-aware&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/xenapp" _fcksavedurl="http://technorati.com/tags/xenapp"&ampgt;xenapp&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/automation" _fcksavedurl="http://technorati.com/tags/automation"&ampgt;automation&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/web" _fcksavedurl="http://technorati.com/tags/web"&ampgt;web&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/video" _fcksavedurl="http://technorati.com/tags/video"&ampgt;video&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/blog" _fcksavedurl="http://technorati.com/tags/blog"&ampgt;blog&amplt;/a&ampgt;, &amplt;a href="http://technorati.com/tags/F5+APM" _fcksavedurl="http://technorati.com/tags/F5+APM"&ampgt;APM&amplt;/a&ampgt;&amplt;/p&ampgt;&amplt;/body&ampgt;&amplt;/html&ampgt; ps Resources: F5 Simplifies and Centralizes Access Management for Citrix Applications BIG-IP v10.2.1 Download (Log in required) BIG-IP Access Policy Manager BIG-IP Edge Gateway F5 YouTube ChannelBYOD Policies – More than an IT Issue Part 1: Liability
#BYOD or Bring Your Own Device has moved from trend to an permanent fixture in today's corporate IT infrastructure. It is not strictly an IT issue however. Many groups within an organization need to be involved as they grapple with the risk of mixing personal devices with sensitive information. In my opinion, BYOD follows the classic Freedom vs. Control dilemma. The freedom for user to choose and use their desired device of choice verses an organization's responsibility to protect and control access to sensitive resources. While not having all the answers, this mini-series tries to ask many the questions that any organization needs to answer before embarking on a BYOD journey. Enterprises should plan for rather than inherit BYOD. BYOD policies must span the entire organization but serve two purposes - IT and the end users. The policy must serve IT to secure the corporate data and minimize the cost of implementation and enforcement. At the same time, the policy must serve the employees to preserve the native user experience, keep pace with innovation and respect the user's privacy. A sustainable policy should include a clear BOYD plan to employees including standards on the acceptable types and mobile operating systems along with a support policy showing the process of how the device is managed and operated. Some key policy issue areas include: Liability, Device choice, Economics, User Experience & Privacy and a trust Model. Today we look at Liability. Liability In addition to IT, an organization's Legal department needs to be involved with any BYOD policy creation to make sure the liability risk for both the user and company is contained and managed. While employees are an organization's greatest asset (other than Intellectual Property, potentially), they are often the culprits of data exposure, intentional or not. Organizations need to consider employee actions and the corresponding liability. If the employee owns the device, does the liability increase or decrease? Even if liability stays neutral, the overall business risk increases any time corporate data is accessed from personal employee devices, mobile or not. What happens if personal data on a personal Smartphone is damaged? What happens if it's remotely wiped by corporate IT, if it is lost? These are some areas that must be resolved with the BYOD policy. Some organizations are very clear about lost/stolen policy and users have the choice of opting out. That's just the personal liability. From a financial liability standpoint, what happens when monthly charges are reimbursed? Often, financial responsibility may dictate legal obligation. A recent Ponemon Institute and Websense survey showed that mobile devices can be a double-edge sword for enterprises. 77% of the 4640 responses said that the use of mobile devices in the workplace is important to achieving business objectives but almost the same percentage - 76% - believe that these tools introduce a "serious" set of risks. While organizations understand the risks, the survey showed that only 39% have security controls in place to mitigate them. As a result, 59% of respondents said they’ve seen a jump in malware infections over the past 12 months due, specifically, to insecure mobile devices including laptops, Smartphone, and tablets while 51% said their organization has experienced a data breach due to insecure devices. As part of the BYOD Policy the Liability Checklist, while not inclusive, should: · Define baseline security requirements · Assess liability of personal web and app usage · Evaluate legal ramifications of reimbursement · Quantify the costs of monitoring and enforcement · Assess the risk and liability of damaging personal data There are probably a ton more Liability questions that should be answered but this was intended as a starting point. What other areas should legal be concerned about? ps Related BYOD–The Hottest Trend or Just the Hottest Term Will BYOL Cripple BYOD? Freedom vs. Control What’s in Your Smartphone? SmartTV, Smartphones and Fill-in-the-Blank Employees Evolving (or not) with Our Devices The New Wallet: Is it Dumb to Carry a Smartphone? Bait Phone BIG-IP Edge Client 2.0.2 for Android BIG-IP Edge Client v1.0.4 for iOS New Security Threat at Work: Bring-Your-Own-Network Legal and Technical BYOD Pitfalls Highlighted at RSAWill BYOL Cripple BYOD?
Don’t ya love all the acronyms we have? So by now, you’ve probably heard that BYOD means Bring Your Own Device – a topic that is getting lots of press these days. The concept of allowing employees to use their own personal device, often mobile, for work related tasks. This could reduce the overall expenditure for IT issued devices and many organizations feel users are happier and more productive when they are using the device of their desire. There could be a snag however when it comes to licensing. Does BYOD also require Bring Your Own License? In many instances, this is an area that IT needs to keep an eye on and often the answer is yes. Some of the most common enterprise software licensing agreements require licensing any device used "for the benefit of the company" under the terms of the enterprise agreement. That often means that all those BYO devices will require a license to access common corporate applications. This also means that even if the user already has a particular license, which they purchased on their own or it came with the device, the organization might still need to license that device under their enterprise software agreement. This could diminish any cost savings from the BYOD initiative. There are solutions to such as using alternative products that are not restricted by licensing but, those may not have the key features required by your workforce. Another idea is to move primarily to virtualization for provisioning apps with restrictive client access licenses. Some software licenses require one CAL per concurrent connection, some require one CAL for each unique client regardless of concurrency and some do not require CALs at all. IT needs to understand if their situation is per-user or per-device and what impact that may have on a BYOD policy. ps
