The California Consumer Privacy Act (CCPA) became effective on January 1, 2020. Enforcement is slated to start by July 1, 2020. CCPA is complex regulation which does bear some similarities with EU GDPR. For more information on how CCPA and GDPR compare, see our webinar. Both regulations deal with how organizations handle PII (Personally Identifiable Information). CCPA intends to empower consumers to give them a choice to disallow onward sales of their PII by organizations that hold that information.  A full discussion of what CCPA entails is out of scope. In this article, I want to focus how our Information Protection Lifecycle (IPLC) and Framework can help organizations prepare for CCPA. 

What is considered PII under CCPA?

Essentially, anything that be used to identify individuals or households of California residents. A summarized list (drawn from the text of the law) includes:

• Identifiers such as a real name, alias, postal address, unique personal identifier, online identifier, IP address, email address, account name, SSN, driver’s license number, passport number, or other similar identifiers.
• Commercial information, including records of personal property, products or services purchased, obtained, or considered, or other purchasing or consuming histories or tendencies.
• Biometric information.
• Internet or other electronic network activity information, including, but not limited to, browsing history, search history, and information regarding a consumer’s interaction with an Internet Web site, application, or advertisement.
• Geolocation data.
• Professional or employment-related information.
• Education information, defined as information that is not publicly available.
• Inferences drawn from any of the information identified in this subdivision to create a profile about a consumer reflecting the consumer’s preferences, characteristics, psychological trends, predispositions, behavior, attitudes, intelligence, abilities, and aptitudes.

The list of data types that are designated as PII by CCPA is quite extensive.

How does a company or organization that is subject to CCPA go about protecting this information from unauthorized disclosure?

The IPLC offers a place to start. Discovery/classification is the first phase in the IPLC. You have to understand what kinds of information you have in order to know if you’re subject to CCPA (or any other pertinent regulations). As with GDPR, a Data Protection Impact Assessment (DPIA) type exercise is a good first step. Organizations that have, sell, or process California resident PII need to conduct data inventories to discover what kinds of PII they may have. There are automated tools that can greatly improve your chances of finding all such data across disparate systems, from on-premise applications and databases to cloud-hosted repositories and apps. Many of these tools can be quite effective, due to the well-known formats of PII. For example, Data Leakage Prevention (DLP) and Data Classification tools have been finding and categorizing data objects such as SSNs, credit card numbers, email addresses, driver’s license numbers, etc. for years.

DLP and classification tools generally provide two ways of applying those classifications to data objects:

• Metadata tagging – adding data about the data to the object itself to signify what type it is and how it should be handled by applications and access control / encryption systems. This method works well for unstructured data objects such as XML, Office documents, PDFs, media files, etc. In some cases, the metadata tags can be digitally signed and encrypted too for additional security and non-repudiation.
• Database registration – adding database elements (additional tables, or columns and rows) to databases to indicate which rows, columns, or cells constitute certain data types. This is usually needed for applications that have SQL or NoSQL back-ends that contain PII, since metadata tagging will not work. This approach is more cumbersome and may require database access proxies (or API gateways) to mediate access and integrate with centralized attribute-based access control (ABAC) systems.

Thus, we see that the first phase in IPLC and the tool types related to that phase (Discovery/Classification) are the way to begin preparing for CCPA enforcement. For additional information on these kinds of tools and more guidance on CCPA and GDPR, see https://plus.kuppingercole.com/. Also, watch our blogs in the days ahead as we will be publishing more about CCPA and how to prepare.

Global Platform announced in 4Q2019 that more than 1 billion TEE (Trusted Execution Environment) compliant devices shipped in 2018, and that is a 50% increase from the previous year. Moreover, 6.2 billion SEs (Secure Elements) were shipped in 2018, bringing the total number of SEs manufactured to over 35 billion since 2010.

This is good news for cybersecurity and identity management. TEEs are commonly found in most Android-based smartphones and tablets. A TEE is the secure area in the processor architecture and OS that isolates programs from the Rich Execution Environment (REE) where most applications execute. Some of the most important TEE characteristics include:

• All code executing in the TEE has been authenticated
• Integrity of the TEE and confidentiality of data therein is assured by isolation, cryptography, and other security mechanisms
• The TEE is designed to resist known remote and software attacks, as well as some hardware attacks.

See Introduction to Trusted Execution Environments for more information.

A Secure Element (SE) is a tamper-resistant component which is used in a device to provide the security, confidentiality, and multiple application environments required to support various business models. Such a Secure Element may exist in any form factor such as UICC, embedded SE, smartSD, smart microSD, etc. See Introduction to Secure Elements for more information.

Global Platform has functional and security certification programs, administered by independent labs, to ensure that vendor products conform to their standards.

These features make TEEs the ideal place to run critical apps and apps that need high security, such as mobile banking apps, authentication apps, biometric processing apps, mobile anti-malware apps, etc. SEs are the components where PKI keys and certificates, FIDO keys, or biometrics templates that are used for strong or multi-factor authentication apps should be securely stored.

The FIDO Alliance™ has partnered with Global Platform on security specifications. FIDO has three levels of authenticator certification, and using a TEE is required for Level 2 and above. For example:

• FIDO L2: UAF implemented as a Trusted App running in an uncertified TEE
• FIDO L2+: FIDO2 using a keystore running in a certified TEE
• FIDO L3: UAF implemented as a Trusted App running in a certified TEE using SE

See FIDO Authenticator Security Requirements for more details.

KuppingerCole recommends as a best practice that all such apps should be built in to run in a TEE and store credentials in the SE. This architecture provides for the highest security levels, ensuring that unauthorized apps cannot get access to the stored credentials, interfere with operation of the trusted app; and this combination presents a Trusted User Interface (TUI) which prevents other apps from recording or tampering with user input, as in cases where PIN authentication is included.

In recent Leadership Compasses, we have asked whether vendor products for mobile and IoT can utilize the TEE, and if key and certificate storage is required, whether vendor products can store those data assets in the SE. To see which vendors use SEs and TEEs, see the following Leadership Compasses:

• Consumer Authentication
• Cloud-based MFA Solutions
• Adaptive Authentication

In addition to mobile devices, Global Platform specifications pertain to IoT devices. IoT device adoption is growing, and there have been a myriad of security concerns due to the generally insecure nature of many types of IoT devices. Global Platform’s IoTopia initiative directly addresses these security concerns as they work to build a comprehensive framework for designing, certifying, deploying and managing IoT devices in a secure way.

KuppingerCole will continue to follow developments by Global Platform and provide insights on how these important standards can help organizations improve their security posture.

The great non-event of Y2K happened twenty years ago. Those of us in IT at that time weren’t partying like it was 1999, we were standing by making sure the systems we were responsible for could handle the date change. Fortunately, the hard work of many paid off and the entry into the 21^st century was smooth. Many things have changed in IT over the last 20 years, but many things are pretty similar.

What has changed?

• Pagers disappeared (that’s a good thing)
• Cell phones became smartphones
• IoT devices began to proliferate
• The cloud appeared and became a dominant computing architecture
• CPU power and storage has vastly increased
• Big data and data analytics
• More computing power has led to the rise of Machine Learning in certain areas
• Cybersecurity, identity management, and privacy grew into discrete disciplines to meet the exponentially growing threats
• Many new domain- and geographic-specific regulations
• Attacker TTPs have changed and there are many new kinds of security tools to manage
• Businesses and governments are on the path to full digital transformation

What stayed (relatively) the same?

• Patching is important; for security rather than Y2K functionality
• Identity as an attack and fraud vector
• Malware has evolved dramatically into many forms, and is a persistent and growing threat
• IT is still a growing and exciting field, especially in the areas of cybersecurity and identity management
• There aren’t enough people to do all the work

What will we be working on in the years ahead?

• Securing operational tech and IoT
• Using and securing AI & ML
• Blockchain
• Cybersecurity, Identity, and Privacy

What are the two constants we have to live with in IT?

• Change
• Complexity

Though we may not have big significant industry-wide dates like Y2K to work toward, cybersecurity, identity, and privacy challenges will always need to be addressed. Thanks to methodologies like Agile, DevOps, and SecDevOps, these challenges will continue to accelerate.

Check KC Plus for regular updates on our research into these ever-changing technologies, and please join us for EIC (The European Identity and Cloud Conference) in Munich in May 2020.

The Information Protection Life Cycle (IPLC) and Framework describes the phases, methods, and controls associated with the protection of information. Though other IT and cybersecurity frameworks exist, none specifically focus on the protection of information across its use life. The IPLC documents 3 stages in the life of information and 6 categories of controls which can be applied as controls to secure information.

Stages in the life of information

Information is created, used, and (sometimes) disposed of when it is no longer needed or valid. Information can be actively created, such as when you start a new document, add records to a database, take photos, post blogs, etc. Information is also passively created when users and devices digitally interact with one another and with applications. Passively generated information often takes the form of log files, telemetry, or records added to databases without the explicit action of users. During its use life, information can be analyzed and modified in various ways by users, devices, and applications.  After a certain point, information may cease to be useful, perhaps due to inaccuracies, inconsistencies, migrations to new platforms, incompatibility with new systems, and/or the regulatory mandates to store it has passed. When information is no longer useful, it needs to be disposed of by archival or deletion, depending on the case.

The types of controls applicable to information protection at each phase are briefly described below.

Discovery and classification

To properly protect information, it must be discovered and classified. The company picnic announcement is not as sensitive and valuable as the secret sauce in your company’s flagship product. Information can be discovered and classified at the time of creation and a result of data inventories. Thanks to GDPR’s Data Protection Impact Assessments (DPIAs), such inventories are more commonly being conducted.

Classification schemes depend on the industry, regulatory regimes, types of information, and a host of other factors. Classification mechanisms depend on the format. For structured data in databases, tools may add rows/columns/tables for tracking cell-level sensitivity. For unstructured data such as documents in file systems, metadata can be applied (“tagged”) to individual data objects.

Access Control

Access to information must be granular, meaning only authorized users on trusted devices should be able to read, modify, or delete it. Access control systems can evaluate attributes about users, devices, and resources in accordance with pre-defined policies. Several access control standards, tools, and token formats exist. Access control can be difficult to implement across an enterprise due to the disparate kinds of systems involved, from on-premise to mobile to IaaS to SaaS apps. It is still on the frontier of identity management and cybersecurity.

Encryption, Masking, and Tokenization

These are controls that can protect confidentiality and integrity of information in-transit and at-rest. Encryption tools are widely available but can be hard to deploy and manage. Interoperability is often a problem.

Masking means irreversible substitution or redaction in many cases. For personally identifiable information (PII), pseudonymization is often employed to allow access to underlying information while preserving privacy. In the financial space, vaulted and vaultless tokenization are techniques that essentially issue privacy-respecting tokens in place of personal data. This enables one party to the transaction to assume and manage the risk while allowing other parties to not have to store and process PII or payment instrument information.

Detection

Sometimes attackers get past other security controls. It is necessary to put tools in place that can detect signs of nefarious activities at the endpoint, server, and network layers.  On the endpoint level, all users should be running current Endpoint Protection (EPP, or anti-malware) products. Some organizations may benefit from EDR (Endpoint Detection & Response) agents. Servers should be outfitted similarly as well as dump event logs to SIEMs (Security Incident and Event Management). For networks, some organizations have used Intrusion Detection Systems (IDS), which are primarily rule-based and prone to false positives. Next generation Network Threat Detection & Response (NTDR) tools have advantages in that they utilize machine learning (ML) algorithms to baseline network activities to be able to better alert on anomalous behavior. Each type of solution has pros and cons, and they all require knowledgeable and experienced analysts to run them effectively.

Deception

This is a newer approach to information protection, derived from the old notion of honeypots. Distributed Deception Platforms (DDPs) deploy virtual resources designed to look attractive to attackers to lure them away from your valuable assets and into the deception environment for the purposes of containment, faster detection, and examination of attacker TTPs (Tools, Techniques, and Procedures). DDPs help reduce MTTR (Mean Time To Respond) and provide an advantage to defenders. DDPs are also increasingly needed in enterprises with IoT and medical devices, as they are facing more attacks and the devices in those environments usually cannot run other security tools.

Disposition

When information is no longer valid and does not need to be retained for legal purposes, it should be removed from active systems. This may include archival or deletion, depending on the circumstances. The principle of data minimization is a good business practice to limit liability.

Conclusions

KuppingerCole will further develop the IPLC concept and publish additional research on the subject in the months ahead. Stay tuned! In the meantime, we have a wealth of research on EPP and EDR, access control systems, and data classification tools at KC PLUS.

As cybercrime and concerns about cybercrime grow, tools for preventing and interdicting cybercrime, specifically for reducing online fraud, are proliferating in the marketplace. Many of these new tools bring real value, in that they do in fact make it harder for criminals to operate, and such tools do reduce fraud.

Several categories of tools and services compose this security ecosystem. On the supply side there are various intelligence services. The forms of intelligence provided may include information about:

• Users: Users and associated credentials, credential and identity proofing results, user attributes, user history, behavioral biometrics, and user behavioral analysis. Output format is generally a numerical range.
• Devices: Device type, device fingerprint from Unified Endpoint Management (UEM) or Endpoint Mobility Management (EMM) solutions, device hygiene (operating system patch versions, anti-malware and/or UEM/EMM clients presence and versions, and Remote Access Trojan detection results), Mobile Network Operator carrier information (SIM, IMEI, etc), jailbreak/root status, and device reputation. Output format is usually a numerical range.
• Cyber Threat: IP and URL blacklisting status and mapped geo-location reputation, if available. STIX and TAXII are standards used for exchanging cyber threat intel. Besides these standards, many proprietary exchange formats exist as well.
• Bot and Malware Detection: Analysis of session and interaction characteristics to assess the likelihood of manipulation by bots or malware. Output format can be Boolean, or a numerical range of probabilities, or even text information about suspected malware or botnet attribution.

Risk-adaptive authentication and authorization systems are the primary consumers of these types of intelligence. Conceptually, risk-adaptive authentication and authorization functions can be standalone services or can be built into identity and web access management solutions, web portals, VPNs, banking apps, consumer apps, and many other kinds of applications.

Depending on the technical capabilities of the authentication and authorization systems, administrators can configure risk engines to evaluate one or more of these different kinds of intelligence sources in accordance with policies. For example, consider a banking application. In order for a high-value transaction (HVT) to be permitted, the bank requires a high assurance that the proper user is in possession of the proper registered credential, and that the requested transaction is intended by this user. To accomplish this, the bank’s administrators subscribe to multiple “feeds” of intelligence which can be processed by the bank’s authentication and authorization solutions at transaction time.

The results of a runtime risk analysis that yields ‘permit’ may be interpreted as “yes, there is a high probability that the proper user has authenticated using a high assurance credential from a low risk IP/location, the request is within previously noted behavioral parameters for this user, and the session does not appear to be influenced by malware or botnet activity.”

This is great for the user and for the enterprise. However, it can be difficult to implement by the administrators because there are few standards for representing the results of intelligence-gathering and risk analysis. The numerical ranges mentioned above vary from service to service. Some vendors provide scores from 0 to 99 or 999. Others range from -100 to 100. What do the ranges mean? How can the scores be normalized across vendors? Does a score of 75 from intel source A mean the same as 750 from intel source B?

Perhaps there is room for a little more standardization. What if a few attribute name value pairs were introduced and ranges limited to improve interoperability and to make it easier for policy authors to implement? Consider the following claims set, which could be translated into formats such as JWT, SAML, XACML, etc :

The above example* shows an Issuer of “IntelSource”, with timestamp and expiry, Audience of “RiskEngine”, Subject (user ID), and 3 additional attributes: “UserAssuranceLevel”, “DeviceAssuranceLevel”, and “BotProbability”. These new attributes are composites of the information types listed above for each category. Ranges for all 3 attributes are 0-99. In this example, the user looks legitimate. Low user and device assurance levels and/or high bot probability would make the transaction look like a fraud attempt.

KuppingerCole believes that standardization of a few intelligence attributes as well as normalization of values may help with implementation of risk-adaptive authentication and authorization services, thereby improving enterprise cybersecurity posture.

*Thanks to http://jwtbuilder.jamiekurtz.com/ for the JWT sample.

The EU European Banking Authority issued clarifications about what constitutes Strong Customer Authentication (SCA) back in late June. The definition states that two or more of the following categories are required: inherence, knowledge, and possession. These are often interpreted as something you are, something you know, and something you have, respectively. We have compiled and edited the following table from the official EBA opinion:

The list and details about implementations are subject to change. Check the EBA site for updates. KuppingerCole will also follow and provide updates and interpretations.

The EBA appears to be rather generous in what can be used for SCA, especially considering the broad range of biometric types on the list. However, a recent survey by GoCardless indicates that not all consumers trust and want to use biometrics, and these attitudes vary by country across the EU.

Although KBA is still commonly used, it should be deprecated due to the ease with which fraudsters can obtain KBA answers. The acceptance of smart cards or other hardware tokens is unlikely to make much of an impact, since most consumers aren’t going to carry special devices for authenticating and authorizing payments. Inclusion of behavioral biometrics is probably the most significant and useful clarification on the list, since it allows for frictionless and continuous authentication.

In paragraph 13, the EBA opinion opened the door for possible delays in SCA implementation: “The EBA therefore accepts that, on an exceptional basis and in order to avoid unintended negative consequences for some payment service users after 14 September 2019, CAs may decide to work with PSPs and relevant stakeholders, including consumers and merchants, to provide limited additional time to allow issuers to migrate to authentication approaches that are compliant with SCA…”

Finextra reported this week that the UK Financial Conduct Authority has announced an extension to March 2021 for all parties to prepare for SCA. The Central Bank of Ireland is following a similar course of delays. Given that various surveys place awareness of and readiness for PSD2 SCA on the part of merchants between 40-70%, it is not surprising to see such extensions. In fact, it is likely that the Competent Authorities in more member states will likely follow suit.

While these moves are disappointing in some ways, they are also realistic. Complying with SCA provisions is not a simple matter: many banks and merchants still have much work to do, including modernizing their authentication and CIAM infrastructures to support it.

For more information, see our list of publications about PSD2. This is also a featured topic at our upcoming Digital Finance World conference, which will be held in Frankfurt, Germany in September.

Account Takeover (ATO) attacks are on the rise. The 2019 Forter Fraud Attack Index shows a 45% increase in this type of attack on consumer identities in 2018. ATOs are just what they sound like: cybercriminals gain access to accounts through various illegal means and use these take over accounts to perpetrate fraud. How do they get access to accounts? There are many technical methods that bad actors can use, such as consumers responding to phishing emails; grafting through fake websites; collection of credentials from keyloggers, rootkits, or botnets; harvesting cookie data using spyware; credential stuffing; brute force password guessing, or perusing compromised credential lists on the dark web. However, they don’t even have to use sophisticated means. Sometimes account information can be found on paper, so variations of “dumpster diving” still works.

Once cybercriminals have account information, depending on the type of account, they can use it for many different kinds of fraud. Of course, financial fraud is a top concern. A banking overlay is a type of mobile malware that looks like a legitimate banking site but is designed to capture bank customer credentials. Banking overlays usually pass on user interaction to the underlying banking app, but also pass on the captured credentials to the malicious actors. Some are sophisticated enough to grab SMS OTPs, thereby defeating that form of 2FA. This problem is more acute on Android than iOS. Using mobile anti-malware and ensuring that users get apps from trusted app stores can help prevent this kind of attack.

Consumer banking is not the only kind of financial industry targeted by cybercriminals. B2B banks, mortgage brokers, investment banks, pension fund managers, payment clearing houses, and cryptocurrency exchanges are also under attack. From the cybercriminals’ point of view, it is easier to attack the end user and the often-less-secured apps they use than to attack financial industry infrastructure.

Just about any online site that exchanges anything of value has become a target for fraudsters. Airline frequent flyer programs and other kinds of travel/hospitality loyalty programs made up 13% of all accounts for sale on the dark web as of the end of 2018. Other consumer rewards programs that can be monetized are also being stolen and brokered. Digital goods, such as in-game purchases, can be highly sought-after, so there are black markets for gamer credentials.

ATO fraud has hit the insurance sector in a big way in recent years. Fraudsters use ATO methods to get insurance customer credentials to submit claims and redirect payouts. Some malicious actors go after insurance agent credentials to facilitate claims processing and get even bigger gains.

Though these stories have been circulating for years, real estate and escrow agents are still occasionally getting ATO’d, such that the home buyers are deceived into transferring large sums to fraudsters during real estate closing deals.

Consumer-facing businesses need to take two major steps to help reduce ATO fraud.

This week Skylight Cyber disclosed that they were able to fool a popular “AI”-based Endpoint Protection (EPP) solution into incorrectly marking malware as safe. While trying to reverse-engineer the details of the solution's Machine Learning (ML) engine, the researchers found that it contained a secondary ML model added specifically to whitelist certain types of software like popular games. Supposedly, it was added to reduce the number of false positives their "main engine" was producing. By dumping all strings contained in such a whitelisted application and simply appending them to the end of a known piece of malware, the researchers were able to avoid its detection completely, as shown in their demo video.

This finding is just another confirmation of inherent challenges of designing ML-based cybersecurity products. Here are some issues:

1. The advantages that ML-enhanced cybersecurity tools provide can be easily defeated if overrides are used to eliminate false positives rather than proper training of ML algorithms. ML works best when fed as much data as possible, and when products are implemented using the right combination of supervised and unsupervised ML methods. It’s possible that whitelisting would not have been necessary if sufficient algorithmic training had been performed.
2. ML can be gamed. Constraining data sets or simply not having enough data piped through the appropriate mix of ML algorithms can lead to bias, which can lead to missed detections in the cybersecurity realm. This can be either intentional or unintentional. In cases of intentional gaming, malicious actors select subsets of data with which to train the discriminator, while purposely omitting others. In the unintentional case, software developers may not have access to a full sample set or may simply choose to not use a full sample set during the construction of the model.  
3. Single-engine EPP products are at a disadvantage compared to multi-engine products. Using “AI” techniques in cybersecurity, especially in EPP products, is an absolute necessity. With millions of new malware variants appearing monthly, human analysts can’t analyze and build signatures fast enough. It is infeasible to rely on signature-based AV alone, and this has been true for years. However, just because signature-based engines are not completely effective doesn’t mean that products should abandon that method in favor of a different single method. The best endpoint protection strategy is to use a mixture of techniques, including signatures, ML-enhanced heuristics, behavioral analysis, sandboxing, exploit prevention, memory analysis, and micro-virtualization. Even with an assortment of malware detection/prevention engines, EPP products will occasionally miss a piece of malicious code. For those rare cases, most endpoint security suite vendors have Endpoint Detection & Response (EDR) products to look for signs of compromise.
4. Marketing ML-enhanced tools as an “AI” panacea has drawbacks.  ML tools are a commodity now. ML techniques are used in many cybersecurity tools, not just EPP. ML is in most data analytics programs as well. It’s a necessary component to deal with enormous volumes of data in most applications. The use of the term “AI” in marketing today suggests infallibility and internal self-sufficiency. But such tools can make mistakes, and they don’t eliminate the need for human analysts.   

KuppingerCole is hosting an AImpact Summit in Munich in November where we’ll tackle these very issues. The Call for speakers is open.

For an in-depth comparison of EPP vendors, see our Leadership Compass on Endpoint Security: Anti-Malware.

This week, Facebook announced details about its cryptocurrency project, Libra. They expect it to go live for Facebook and other social media platform users sometime in 2020. The list of initial backers, the Founding Members of the Libra Association, is quite long and filled with industry heavyweights such as Coinbase, eBay, Mastercard, PayPal, and Visa. Other tech companies including Lyft, Spotify, and Uber are Founding Members, as well as Andreesen Horowitz and Thrive Capital.  

Designed to be a peer-to-peer payment system, Libra will be backed by a sizable reserve and pegged to physical currencies to defray wild currency floats and speculation. The Libra Association will manage the reserve, and it will not be accessible to users. The Libra Association will mint and destroy Libra Coins in response to demand from authorized resellers. Founding Members will have validator voting rights. As we can see from the short list above, Libra Founding Members are large organizations, and they will have to buy in with Libra Investment Tokens. This investment is intended to incentivize Founding Members to adequately protect their validators. Libra eventually plans to transition to a proof-of-stake system where Founding Members will receive voting rights proportional (capped at 1%) to their Investment Tokens. They expect this to facilitate the move to permissionless blockchain at some point in the future. Libra blockchain will therefore start off as permissioned and closed. The Libra roadmap can be found here.

Let’s look at some of the interesting technical details related to security that have been published at https://libra.org. Libra protocol takes advantage of lessons learned over the last few years of blockchain technologies. For example, unlike Bitcoin, which depends on the accumulation of transactions into blocks before commission, in Libra, individual transactions compose the ledger history. The Consensus protocol handles aggregation of transactions into blocks. Thus, sequential transactions and events can be contained in different blocks.  

Authentication to accounts will use private key cryptography, and the ability to rotate keys is planned. Multiple Libra accounts can be created per user. User accounts will not necessarily be linked to other identities. This follows Bitcoin and Ethereum model for pseudonymity. Libra accounts will be collections of resources and modules. Libra “serialize(s) an account as a list of access paths and values sorted by access path. The authenticator of an account is the hash of this serialized representation. Note that this representation requires recomputing the authenticator over the full account after any modification to the account... Furthermore, reads from clients require the full account information to authenticate any specific value within it.”  

Transaction fees in Libra will adhere to an Ethereum-like “gas” model: senders name a price they are willing to pay, and if the cost to the validators exceeds the number of units at that price, the transaction aborts. The ledger won’t be changed, but the sender will still be charged the fee. This is designed to keep fees low during times of high transaction volumes. Libra foresees that this may help mitigate against DDoS attacks. It also will prevent senders from overdrawing their accounts, because the Libra protocol will check to make sure there is enough Libra coin to cover the cost of the transaction prior to committing it.

The Libra Protocol will use a new programming language, called Move, which will be designed to be extensible to allow user-defined data-types and smart contracts. There will be no copy commands in Move, only create/destroy, to avoid double-spend. Programmers will be able to write in higher level source and intermediate representation languages, which will be output to a fairly simple and constrained bytecode which can be type- and input-verified for security. Transactions are expected to be atomic, in that each should contain a single operation. In Libra, modules will contain code and resources will have data, which is in contrast to Ethereum, where a smart contract contains both code and data.  

Another interesting concept in Libra is the event. An event is defined as a change of state resulting from a transaction. Each transaction can cause multiple events. For example, payments result in corresponding increases and decreases in account balances. Libra will use a variant of the HotStuff consensus protocol called LibraBFT (Byzantine Fault Tolerance), which is architected to withstand multiple malicious actors attempting to hack or sabotage validators. The HotStuff consensus protocol is not based on proof-of-work, thereby avoiding performance and environmental concerns. Libra intends to launch with 100 validators, and eventually increase to 500-1,000 validator nodes.

Libra Core code will be written in Rust and open sourced. Facebook and Libra acknowledge that security of the cryptocurrency exchange depends on the correct implementation of validator node code, Move apps, and the Move VM itself. Security must be a high priority, since cryptocurrency exchanges are increasingly under attack.  

Facebook’s new subsidiary Calibra will build the wallet app. Given that Coinbase and others in the business are on the board, it’s reasonable to expect that other cryptocurrency wallets will accept Libra too. Facebook and other cryptocurrency wallet makers must design security and privacy into these apps as well as the protocol and exchange. Wallets should take advantage of features such as TPMs on traditional hardware and Secure Elements / Trusted Execution Environment and Secure Enclave on mobile devices. Wallets should support strong and biometric authentication options.

Users will have no guarantees of anonymity due to international requirements for AML and KYC. Facebook claims social media profile information and Libra account information will be kept separate, and only shared with user consent. Just how Facebook will accomplish this separation remains to be seen. The global public has legitimate trust issues with Facebook. Nevertheless, Facebook, WhatsApp, and Instagram have 2.3B, 1.6B, and 1.0B user accounts respectively. Despite some overlap, that user base is larger than a couple of the largest countries combined.

The moral argument in favor of cryptocurrencies has heretofore been that blockchain technologies will benefit the “unbanked”, the roughly 2B people who do not have bank accounts. If Libra takes off, there is a possibility that more of unbanked will have access to affordable payment services, provided there is sizable intersection between those with social media accounts and who are unbanked.  

Much work, both technical and political, remains to be done if Libra is to come to fruition. Government officials have already spoken out against it in some areas. Libra will have to be regulated in many jurisdictions. An open/permissionless blockchain model would help with transparency and independent audit, but it could be years before Libra moves in that direction. While Libra runs as closed/permissioned, they will face more resistance from regulators around the world.  

Facebook and the Libra Association will have to handle not only a mix of financial regulations such as AML and KYC, but also privacy regulations like GDPR, PIPEDA, CCPA, and others. There was no mention in the original Libra announcement about support for EU PSD2, which will soon govern payments in Europe. PSD2 mandates Strong Customer Authentication and transactional risk analysis for payment transactions. Besides the technical and legal challenges ahead, Facebook and Libra will then have to convince users to actually use the service.

Initiating payments from a social media app has been done already: WeChat, for example. So it’s entirely possible that Libra will succeed in some fashion. If Libra does take off in the next couple of years, expect massive disruption in the payments services market. It is too early to accurately predict the probability of success or the long-term impact if it is successful. KuppingerCole will follow and report on relevant developments. This is sure to be a topic of discussion at our upcoming Digital Finance World and Blockchain Enterprise Days coming up in September in Frankfurt, Germany.  

 

It seems almost every week in cybersecurity and IAM we read of a large company buying a smaller one. Many times, it is a big stack vendor adding something that may be missing to their catalog, or buying a regional competitor. Sometimes it’s a medium-sized technology vendor picking up a promising start-up. In the olden days (15+ years ago), start-ups hoped for going IPO. IPOs are far less common today. Why? Mostly because it’s an expensive, time-consuming process that doesn’t achieve the returns it once did. Many times, going IPO was an interim step to getting acquired by a large vendor, so why not just skip ahead? 

Mergers are not common for a few reasons. Merger implies a coming together of near-equals, and executives and boards of directors don’t usually see it this way. So even when mergers happen, they’re often spun as simply acquisitions, and one brand survives while the other fades away. Mergers also mean de-duplication of products, services, and downsizing of the workforces. Mergers can be difficult for customers of both former brands to endure as well.

In the last few years, we’ve increasingly seen equity firms purchase mature start-ups and assemble portfolios of tech vendors. I say “mature start-up” because, instead of the “3 years and out” that occasionally worked in the early 2000s, now vendors are often taking investment (Series A, B, C, D, etc.) 5-7 years or more after founding. When equity firms pick up such companies, the purchased vendor generally retains their brand in the marketplace. The equity firms typically have 3-5 year plans to streamline the operations of the components in their portfolios, make each company profitable, build value, and then sell again.

Other times large companies spin off divisions that are “not part of their core competencies”.  Maybe those divisions are not doing well under current management and might fare better in the market where they can have some brand separation and autonomy.

What motivates acquisitions? There are four major reasons companies merge with or buy others:

1. To acquire technology
2. To acquire customers
3. To acquire territory
4. Unknown

Getting a new technology to integrate into an existing suite is very straightforward. Picking up a smaller competitor to access their customer base is also a common strategy, provided it doesn’t run afoul of anti-trust laws. Large regional vendors will sometimes buy or merge with similar companies in other regions to gain overall market share. These can often be smart strategies toward building a global footprint in the market.  

Every now and then, however, we read about deals that don’t make sense in the industry. This is the unknown category. Sometimes big companies do acquire smaller competition, but do not integrate, extend, or service the purchased product. Dissatisfied customers leave. Overall brand reputation suffers. These deals turn out to be mistakes in the long run, only benefitting the owners of the purchased company. A better plan is to out-compete rather than buy-out the competition.  

Customers of vendors that are being bought or divested have questions: what will happen to the product I use? Will it be supported? Will it go away? Will I have to migrate to combined offering? If so, is now the time to do an RFP to replace it?

IT executives in end-user organizations may hold conflicting views about M&A activities. On the one hand, consolidation in the market can make vendor and service management easier: fewer products to support and fewer support contracts to administer. On the other hand, innovation in large companies tends to be slower than in smaller companies. It’s a momentum thing. As an IT manager, you need your vendor to support your use cases. Use cases evolve. New technical capabilities are needed. Depending on your business requirements and risk tolerance, you may occasionally have to look for new vendors to meet those needs, which means more products to support and more contracts to manage. Beware the shiny, bright thing!

Recommendation: executives in companies that are acquiring others or are being divested need to 

1. Quickly develop, or at least sketch, roadmaps of the product/services that are being acquired or divested. Sometimes plans change months or years after the event. When they do, let customers know.
2. Communicate those roadmaps as well as known at the time of acquisition or divestiture. Explain the expected benefits of the M&A activity and the new value proposition. This will help reduce uncertainty in the market and perhaps prevent premature customer attrition.

In summary: there will always be mergers, acquisitions, and divestitures in the security and identity market. Consolidation happens, but new startups emerge every quarter in every year with new products and services to address unmet business requirements. IT managers and personnel in end-user organizations need to be aware of the changes in the market and how it may impact their businesses.  

Likewise, executives in vendor companies, investors, VCs, and equity firms need to be cognizant of current market trends as well as make predictions about the impact and success of proposed ventures. This can help to avoid those deals that leave everyone scratching their heads wondering why did they do that? At KuppingerCole, we understand the cyber and IAM markets, and know the products and services in those fields. Stay on top of the latest security and identity product evaluations at www.kuppingercole.com.