Tadesse Misiker
email: misiker@umich.edu

Colton Aga

Todd Holoday
email: choloday@umich.edu

Austin
email: austin@umich.edu

Wrangling in the Power of Code Pointers with ProxyCFI

Keywords: CFG mimicry attacks, CFI, Pointer proxy

Despite being a more than 40-year-old dark art, control flow attacks remain a significant and attractive means of penetrating applications. Control Flow Integrity (CFI) prevents control flow attacks by forcing the execution path of a program to follow the control flow graph (CFG). This is performed by inserting checks before indirect jumps to ensure that the target is within a statically determined valid target set. However, recent advanced control flow attacks have been shown to undermine prior CFI techniques by swapping targets of an indirect jump with another one from the valid set. In this article, we present a novel approach to protect against advanced control flow attacks called ProxyCFI. Instead of building protections to stop code pointer abuse, we replace code pointers wholesale in the program with a less powerful construct -pointer proxies. Pointer proxies are random identifiers associated with legitimate control flow edges. All indirect control transfers in the program are replaced with multi-way branches that validate control transfers with pointer proxies. As pointer proxies are uniquely associated with both the source and the target of control-flow edges, swapping pointer proxies results in a violation even if they have the same target, stopping advanced control flow attacks that undermine prior CFI techniques. In all, ProxyCFI stops a broad range of recently reported advanced control flow attacks on real-world applications with only a 4% average slowdown.

Introduction

For more than four decades, control flow attacks, in which attackers force programs into executing code sequences not anticipated by the developer, have played an important role in the infiltration of vulnerable systems. These attacks are particularly attractive to attackers because they immediately give them the agency necessary to deploy attack payloads, leak important information, embed a rootkit, launch an additional attack such as privilege escalation, etc. As such, there has been much attention paid to reducing a system's vulnerability to control flow attacks.

Early measures to stop control flow attacks include StackGuard [START_REF] Cowan | Stackguard: Automatic adaptive detection and prevention of buffer-overflow attacks[END_REF], data execution prevention (DEP) [2] [1] and address space layout randomization (ASLR) [START_REF]Windows isv software security defenses[END_REF]. However, subsequent attacks have skirted this defenses [START_REF] Strackx | Breaking the memory secrecy assumption[END_REF] [27] [START_REF] Shacham | On the effectiveness of address-space randomization[END_REF]. CFI [START_REF] Abadi | Control-flow integrity[END_REF] follows a principled approach to mitigating control flow attacks by enforcing the runtime execution path of a program to adhere to the statically determined CFG. It does these by checking if the target of an indirect jump is within a valid set of targets. However, prior proposed CFI solutions are either impractical or ineffective. Some, which strictly follow a program's CFG [START_REF] Jose Mashtizadeh | Ccfi: cryptographically enforced control flow integrity[END_REF], have high overheads that render them impractical to production systems. Others attempt to reduce overheads by approximating the CFG with limited classes of targets (e.g., two classes for function pointers and return addresses) [41] [42] [6] [START_REF]Control flow guard (windows) -msdn -microsoft[END_REF], but these do not protect against control flow attacks that swap targets while remaining on the CFG [START_REF] Gktas | Out of control: Overcoming control-flow integrity[END_REF] [14] [START_REF] Evans | Control jujutsu: On the weaknesses of fine-grained control flow integrity[END_REF] [START_REF] Schuster | Counterfeit object-oriented programming: On the difficulty of preventing code reuse attacks in C++ applications[END_REF].

In this work, we make the key observation that many of the vulnerabilities in control flow stem from the excessive power inherent in code pointers. To stop the tide of control flow attacks, we propose a novel approach to control flow integrity, called ProxyCFI, that replaces all code pointers in the program with pointer proxies. A pointer proxy is a unique random identifier (64-bits in our implementation), which represents a forward or backward control flow edge in the program. Consequently, all indirect jumps in the program (e.g., returns and jumps-through-register) are replaced with multi-way branches that implement a direct jump to the address associated with the pointer proxy. As pointer proxies are a function of both the source and the target of an edge, swapping pointer proxies results in a violation even if they have the same target.

To ensure that all execution flows stay on the program CFG for even thirdparty ProxyCFI compliant code, a binary-level program verifier first validates at load-time that programs and libraries have CFGs that are fully discoverable, use only pointer proxies, and avoid all indirect jumps/returns. Finally, to thwart attacks based on binary analysis, the verifier re-randomizes pointer proxies at load time. In addition, the loader marks code sections unreadable, to protect from active-read attacks that gather pointer proxies using memory leaks. More importantly, ProxyCFI has a number of powerful features to deter attacks that mimic legitimate control flow (i.e., control flow attacks that seemingly remain on legitimate control flow edges), such as control flow bending (CFB) [START_REF] Carlini | Control-flow bending: On the effectiveness of control-flow integrity[END_REF]. These attacks exploits the fact that existing CFI techniques allow executions to maliciously divert indirect branches if the target address is still in the valid set of targets. ProxyCFI thwarts this as a pointer proxy is unique to a particular source and target address which makes a pointer proxy used in one function context invalid in another even if they share the same target addresses.

Table 1 lists the comparative capabilities of traditional code pointers versus pointer proxies. As shown in the table, pointer proxies do not support arithmetic manipulation; thus, relative-address based control flow attacks, such as ASLR de-randomization attacks [START_REF] Shacham | On the effectiveness of address-space randomization[END_REF] would not be possible with pointer proxies. Moreover, pointer proxies are much more difficult to forge, since their assignment is not in anyway related to other pointer proxies, whereas pointer values often reveal much information through relative address distances to other code objects, facilitating relative address inspired attacks. Since pointer proxies are unique to a given function, return address copy attacks, such as the return-into-libc [START_REF] Tran | On the expressiveness of return-into-libc attacks[END_REF] and backward-edge active-set attacks [START_REF] Theodorides | Breaking active-set backward-edge CFI[END_REF], become more challenging, as the pointer proxies of other functions (which are assigned at load-time) must be leaked and then translated to the local function's proxies (which have no correlation even if the current function calls the intended target).

Contributions of This Paper

In this paper, we introduce ProxyCFI, a novel control flow integrity technology that thwarts recent advanced control flow attacks while incurring low performance overhead. Specifically, this paper makes the following contributions:

-We present ProxyCFI that provides an efficient and practical protection against advanced code reuse attacks, with a threat model notably more capable than that of traditional CFI techniques which must protect a shadow stack [START_REF] Prasad | A binary rewriting defense against stack based buffer overflow attacks[END_REF] or pointer encryption technologies which must protect encryption keys [START_REF] Cowan | Pointguard tm: protecting pointers from buffer overflow vulnerabilities[END_REF]. -We detail the implementation of ProxyCFI within the GNU GCC compiler toolchain.

-We demonstrate the efficiency of the approach running a wide range of CPUcentric and network-facing applications. In addition, we implement two compiletime optimizations, which ultimately reduce the slowdown of this technology to only 4% on average. In addition, our security analysis shows that the technology stops real-world advanced control flow attacks and demonstrates 100% coverage for the RIPE x86-64 control flow attack suite [40].

Protecting Control Flow with ProxyCFI

In this section, we detail our threat model and the broad ProxyCFI concept, then present how to build and verify programs (including shared libraries) with pointer proxies.

Threat Model

In this work, we assume a very powerful attacker who wants to redirect control flow to a code sequence that deviates from the programmer-specified CFG. In accomplishing their control flow attack, the attacker has read and write access to any data location, including globals, stack and heap variables, as well as data storage locations holding pointer proxies. The code segment of the program is assumed to be non-writable. Given this powerful attacker, ProxyCFI works to prevent the attacker from hijacking control from the programmer-specified CFG. In addition, ProxyCFI also gives protection against non-gadget code reuse attacks (e.g., COOP where the attack does not leave the CFG of the program, but instead enlists the code in a CFG mimicry attack [START_REF] Schuster | Counterfeit object-oriented programming: On the difficulty of preventing code reuse attacks in C++ applications[END_REF]).

Pointer Proxies

To stop control flow attacks, we replace all code pointers with pointer proxies. A pointer proxy is a random identifier (64-bits in our evaluated implementation), where pointer proxy P represents an edge from a particular code exit point to a code entry point. Wherever a code pointer would reside in the program (e.g. in a jump table or on the stack as a return address), it is replaced by its corresponding pointer proxy value P . Figure 1 illustrates a small code snippet in which the code pointers have been replaced by pointer proxies. As seen in the example, where code pointers would have been stored (e.g., on the stack for a return address), they are replaced with pointer proxies (denoted by a $). At indirect jumps and returns, the pointer proxy is inspected, and then using a multi-way direct branch, the appropriate code entry point associated with the pointer proxy is jumped to. We call a multi-way direct branch, which matches a pointer proxy and then directly jumps to the associated code target, a sled. Direct jumps are not replaced with pointer proxies. Since our threat model assumes that code cannot be written, any direct jump is inherently write-protected, and thus no additional protections are required. Three multi-way branches can be seen in the example in Figure 1. The indirect call to bar() and baz() in function foo() is implemented with a multi-way branch that jumps to bar() if the proxy $7743d2ff is encountered and jumps to baz when the pointer proxy is $1f324a19. Additionally, both of the returns from functions bar() and baz() are implemented with a multi-way branch.

Advanced control flow attacks such as control low bending [START_REF] Carlini | Control-flow bending: On the effectiveness of control-flow integrity[END_REF] undermine CFI by using a code pointer copied from one function context to jump to addresses in some other function without violating CFI constraints. Pointer proxies are uniquely assigned to control flow edges (i.e., a function of source and destination), thus, the pointer proxies of function X are meaningless to function Y . This powerful feature, which does not impact the usability of pointer proxies, thwarts large number of advanced control flow attacks. This aspect is shown in Figure 1 in the returns of functions bar() and baz(). While both functions return to the same address (i.e., label done), they each use a distinctly different pointer proxy. As such, if each of the functions were to disclose each other's pointer proxy and return upon it, it would not match any target in the return's multi-way branch, and would result in a violation. To stop the potential forgery of pointer proxies, all pointer proxy values are defined per-function, and they are re-randomized at program load time by the verifier as detailed in Section 2.4.

Building Code with Pointer Proxies

Building code to work with pointer proxies requires replacing every place in the program that uses a code pointer with a pointer proxy.

Hardening indirection with pointer proxies: All indirect branches (e.g., switch jump tables, indirect calls, and returns), are replaced with a multi-way direct branch sleds. Of course, to know what targets must be tested for in a sled, we must fully anticipate all of the targets of each indirect branch. For locally sourced indirect jumps, such as a switch statement jump table, we can easily anticipate in the current compilation module all of the indirect jump targets. Indirect calls and returns require more analysis as the locations (and pointer proxy values) may come from another application module (e.g., a shared library). Consequently, the compilation framework must support whole-program CFG analysis (including the call graph). In our prototype implementation in the GNU GCC toolchain, we utilize a two-pass compilation strategy, to first build the whole program CFG and then to compile programs with fully enumerated multi-way direct branch sleds. Details of this compilation strategy are covered in Section 3.

At indirect calls, the type of the target function is noted, and when the whole program CFG is constructed, an indirect function call is assumed to possibly happen to only same-typed function and has had its address taken. Similarly, the return address sleds target the instruction after all actual and potential calls to the returning function, where a potential call directly targets the function or indirectly targets the function through a compatible function pointer. This approach works quite well until a program declares a void * indirect function call, which could potentially call any function in the program. Fortunately, our optimizations detailed in Section 3.2 perform well to reduce the overall impact of these generic indirect function calls. To ensure that there is a valid sled entry for code pointers used across modules, ProxyCFI performs whole program analysis including shared libraries to ensure indirect calls from a shared library into the executable have a corresponding sled entry to handle callback functions. A similar analysis is performed for callbacks passed into shared libraries.

When good code pointers go bad: ProxyCFI doesn't support dangerous code pointer operations such as code pointer arithmetic, which are characteristics of a buggy program [START_REF] Misra | Guidelines for the use of the c/c++ language in critical systems[END_REF]. For example, we could manufacture a code pointer to a private function in x86-64 GCC by simply adding the size of the preceding function (in bytes) to its code pointer. In our prototype GNU GCC C/C++ implementation of ProxyCFI, we issue a security warning for these operations at compile time and terminate the program if executed at runtime. While we were able to create these problems in test programs, none of our benchmark programs suffered from dangerous code pointer manipulations.

setjump() and longjmp() require special handling in the compiler because these functions implement a unique user-directed program control flow transition. Together, these functions implement a superset of function pointer behavior, such that a call to setjmp() can be the target of any other longjmp() in the program. Both function pointers and longjmp() share an indirect jump, but a longjmp should generate a multi-way direct branch including all of the pointer proxies assigned to the instruction immediately after each call to setjmp(). Thus, any tampering in the setjmp() control context cannot pull execution off the CFG.

Load-time Program Verifier

Load-time Program Verifier ensures no legal control flow results in a violation and no deviation from the CFG is missed. It maintains this by verifying that programs utilize only pointer proxies for indirect branches via multi-way direct branches that are fully enumerated by the programmer-specified CFG. If an unexpected pointer proxy is encountered, the program is terminated. The psuedocode for the ProxyCFI code verifier is shown in Algorithm 1. The verifier performs reachability analysis on the code object's CFG to validate that it is i) free of indirect control transfers and ii) all control transfers point to a valid instruction within the current code object or the entry point of another code object for calls. To this end, it performs a depth-first traversal of the CFG of the code object, inspecting all control transfer instructions. If indirect call/jump or return instructions are encountered in the code object, it immediately fails verification. For direct control transfer (i.e., direct call, direct jump, loop instructions), it analyzes the target address for any possible violations.

For direct jump instructions, the verifier checks that the target address points to a valid instruction within the current code object. For direct function calls, the verifier validates that the target is a valid code object entry point. Finally, for multi-way branch sleds replacing an indirect call/jump and return, the verifier ensures that all targets are valid according to the CFG. Once the verifier completes reachability analysis of the CFG without failure, the code is safe to load and execute.

Deterring CFG Mimicry Attacks

A mimicry attack [38] on the CFG is one that implements attacker-directed control without leaving the programmer-specified CFG. With the introduction of powerful control flow integrity mechanisms, such as CFI [START_REF] Abadi | Control-flow integrity[END_REF] these non-gadget code reuse-based attacks have quickly grown in number, including counterfeit OOP [START_REF] Schuster | Counterfeit object-oriented programming: On the difficulty of preventing code reuse attacks in C++ applications[END_REF], control flow bending [START_REF] Carlini | Control-flow bending: On the effectiveness of control-flow integrity[END_REF], and active-set backward-edge attacks [START_REF] Theodorides | Breaking active-set backward-edge CFI[END_REF]. ProxyCFI can provide protection against these attacks through per-function pointer proxy namespaces and load-time pointer proxy assignment.

Per-function pointer proxy namespaces: Traditional full-fledged code pointers represent a code location that is sharable with any other part of the program. It is this property that allows an adversary to copy a code pointer from one function and replay it in another, an approach that Counterfeit OOP [START_REF] Schuster | Counterfeit object-oriented programming: On the difficulty of preventing code reuse attacks in C++ applications[END_REF] utilizes to implement method-level code reuse that does not leave the CFG. Pointer proxies deter CFG mimicry attacks by defining unique pointer proxy namespaces for each function. Thus, if a function copies the pointer proxy from another function, for example, by searching for pointer proxies up the stack, any attempt to use it will always result in a violation when the multi-way branch sled executes. In Figure 1 although bar() and baz() both return to the same location, they each have their own proxy namespace which have different proxy-to-edge mappings (i.e., $ae23afcc and $bc41c823).

Load-time assignment of pointer proxies: Pointer proxies are re-randomized at load time to further deter mimicry attacks. This prevents offline analysis of code to generate a translation table from pointer proxies to source and target code addresses. Enforcing a non-readable code section and load-time assignment of proxies significantly complicates CFG mimicry attacks.

Shared Libraries with Pointer Proxies

Shared libraries are an attractive target for control flow attacks as they are used among multiple applications. Attacks that target libc, for example, can be reused on any application that links to it. The classic attack is return-into-libc [START_REF] Tran | On the expressiveness of return-into-libc attacks[END_REF], wherein the adversary overwrites the return address so that the program returns to an exploitable libc function such as system(). In addition, most shared libraries contain large enough codebases that leaves an attacker with wide selection of gadgets for all classes of code reuse attacks, such as ROP [START_REF] Dai | Practical return-oriented programming[END_REF], JOP [START_REF] Bletsch | Jump-oriented programming: a new class of code-reuse attack[END_REF], LOP [START_REF] Lan | Looporiented programming: a new code reuse attack to bypass modern defenses[END_REF] and their variants [START_REF] Buchanan | When good instructions go bad: Generalizing return-oriented programming to risc[END_REF] [START_REF] Göktaş | Size does matter: Why using gadget-chain length to prevent code-reuse attacks is hard[END_REF].

Connections into and out of shared libraries must be managed by unshared data or code that is generated dynamically. Returns and indirect calls are natural solutions to entering and exiting shared libraries because they draw on unshared data in the stack and the global offset table, respectively. As such, shared libraries require special handling with ProxyCFI which works to remove indirection. One solution to securing shared libraries is to forbid them -Intel chose this with SGX [START_REF]Dynamic libraries[END_REF]. However, we want to retain their advantages: modularity, reduced page swapping, and simplified version management.

ProxyCFI compliant shared libraries use unshared code to manage control flow in and out because indirection must be replaced with multi-way branches. While calling a shared library function still goes through the procedure linkage table (PLT), the indirect call within the PLT is dynamically replaced with a pointer proxy sled. At load time, extra space in the caller's address space is mmap'ed for the code that channels control flow on return. Shared library functions have their returns statically replaced with a relative jump down to the unshared multi-way branches. Fig. 3: Shared Library Control Flow. ProxyCFI allocates linkage tables using pointer proxies in the caller's address space, which permit safe entry and exit from a compliant shared library.

Our approach to deploying shared libraries with ProxyCFI is illustrated in Figure 3. We split the process of returning from a shared library into two stages, which are associated with the selection linkage table (SLT) and the return linkage table (RLT), respectively. Two pointer proxies are used to return from a shared library, one for the SLT and one for the RLT. For each PLT entry to a shared library function there is an RLT entry that contains a multi-way branch leading back to each call site in the code object. If shared library function f oo() is called from multiple code objects, then each code object would have a separate RLT entry for f oo() in its own address space. While the RLT specifies how to return within a code object, the SLT specifies which code object to return to. To accomplish this, SLT entries contain a multi-way branch of absolute jumps directed at RLT entries. Since the size of SLT entries varies based on the code objects that use the shared library, a trampoline table facilitates static generation of the relative jumps by forwarding control onto the appropriate SLT entry.

Using load-time assignment, it is possible to assign proxies for the tendrils into a shared library in a way that creates pointer proxies when the library is first loaded. Moreover, our approach allows the pointer proxies used to enter and exit the shared library function to be unique to each address space that utilizes the shared library. This ensures that an attacker cannot gather pointer proxy information from their own address space and use it to attack a program using the same shared library.

ProxyCFI in GNU GCC

In this section, we detail the implementation of ProxyCFI in the GNU GCC C/C++ toolchain. We present the overall compilation flow, and then dive into the details of the optimizations implemented. In the first pass, the entire CFG of the program is discovered. In the second pass, all legal program entrypoints are assigned randomly selected pointer proxy identifiers, and all indirect jumps, indirect calls, and returns are replaced with fully enumerated multi-way direct branches. The linker resolves all jumps using compiler-generated global identifiers for all entry points. The profiler instruments the code to count the most frequent targets of multi-way branches, which is used for optimization. Finally, all code is passed through the pointer proxy verifier, assigned load-time random pointer proxies and loaded into execute-only pages before execution begins.

Compilation Flow

ProxyCFI instrumentation is done with a two-pass transformation on assembly generated mid-compilation by the existing GCC infrastructure. All sites of indirection are replaced with fully enumerated multi-way direct branches that validate CFG transitions with pointer proxies. Figure 4 describes the overall flow of ProxyCFI compilation.

-Pass 1. CFG Discovery: Assembly files are parsed for function labels, (direct or indirect) call sites, and return sites. Return edges are constructed by observing the target set for each direct and indirect call. Indirect call target sets include only functions that have had their addresses taken and have a matching type signature. Type information on function pointer calls are passed from the GCC frontend to the ProxyCFI compiler core. -Pass 2. Branch Enumeration: Since the CFG contains all transitions between functions, multi-way branch targets are fully enumerated before the second pass begins. For return sites, pointer proxies are chosen in the context of the called function and shared with the calling function's indirect call sled.

Pointer proxies are generated in this way to deter CFG mimicry attacks (see Section 2.5 for details).

After generating a binary, runtime analytics, which are generated by the profiler, are passed back to the branch enumeration phase, at which point the multi-way branch sleds are rewritten with optimizations. Load time invocation of the verifier rewrites all pointer proxies before executing the program.

ProxyCFI Optimizations

Indirect jump and return sleds can become very long, especially for frequently called functions. To address these potential concerns, we implemented two optimizations: profile-guided sled sorting, and function cloning.

Profile-guided sled sorting. The main source of performance degradation with ProxyCFI is the overhead incurred by the repeated comparisons used to implement multi-way direct branch sleds. The number of checks required is directly proportional to the number of legitimate targets for the corresponding indirect control transfer instruction. Yet, we observed that these sleds were highly biased to only a few of the branch targets. Our sled sorting optimization takes advantage of the biased distribution of multi-way branch targets by sorting the entries in descending order of profiled execution count. As shown in Section 4, this optimization significantly reduces the average depth a program must traverse into a sled before finding the pointer proxy target.

Function Cloning. While profile-guided sorting of the sleds significantly reduces performance degradation associated with multi-way branch sleds, the improvements are limited for functions with more uniformly distributed sled profiles. To combat this, we adapted function cloning [START_REF] Keith D Cooper | A methodology for procedure cloning[END_REF] -an optimization that creates specialized copies of functions -as a means to reduce overall sled lengths. For sleds with more uniform distributions, this optimization significantly reduces the performance overhead incurred by executing sleds. Figure 5 illustrates function cloning. A function with near uniform sled distribution is cloned (e.g., function f2 becomes identical functions f2 and f2 c1 ). Then, half of the call sites to the cloned function are redirected to the cloned function.

This optimization also significantly reduces the attacker's agency in selecting CFG edges to exploit for CFG mimicry attacks [START_REF] Carlini | Control-flow bending: On the effectiveness of control-flow integrity[END_REF] [20] [START_REF] Schuster | Counterfeit object-oriented programming: On the difficulty of preventing code reuse attacks in C++ applications[END_REF].

Evaluation

In this section, we examine the performance and security of ProxyCFI. First, the performance impact of ProxyCFI is assessed by examining the slowdown incurred for many CPU-centric and network-facing benchmarks, with and without ProxyCFI optimizations. To gauge the security benefits, we performed penetration testing with the RIPE control flow attack suite [40] and recent advanced control flow attacks on real-world applications.

Evaluation Framework

ProxyCFI build framework. Our ProxyCFI compiler framework was built on GCC version 6.1.0. In our evaluations, we used Ubuntu 16.04 on x86-64. Using x86-64 is essential in our implementation because our shared libraries rely heavily on relative jumps to preserve code page sharing, which is significantly more efficient in 64-bit x86. We customized GLIBC's loader to handle Proxy-CFI compliant shared libraries and mark code pages execute-only. Many modern processors have hardware support for execute-only memory. For example, recent Intel CPUs support unreadable code pages using the Memory Protection Keys (MPK) feature.1 In our prototype implementation, we used this feature to make the code section execute-only (i.e., disabled read/write access).

Benchmarks analyzed. We evaluated the performance and space overhead incurred by ProxyCFI using the SPEC CPU 2006 benchmarks. In addition, we evaluated the overhead on the network-facing application redis-server , running it with the standard redis-benchmark with 50 parallel clients and a 3-byte payload. To isolate the performance overhead incurred by ProxyCFI-hardened shared objects, we also ran microbenchmarks for varying shared library sled depths. To evaluate the security guarantees provided by ProxyCFI, we analyzed applications from all the major categories commonly targeted by control flow hijacking attacks including multimedia processing, Javascript engines, document rendering, network infrastructure and VM interpreters. Specifically, we analyzed the following commonly attacked applications (detailed in section 4.3): MuPDF is a light weight PDF XPS and EPUB parsing and rendering engine. MuPDF versions V1.3 and prior have a stack-based buffer overflow vulnerability (CVE-2014-2013) [8] that results in remote code execution via a maliciously crafted XPS document. bladeenc is a cross-platform MP3 encoder which is also used as a daemon for encoding in distributed MP3 encoders/CDDB servers like abcde. bladeenc has several vulnerabilities that lead to CFG mimicry attacks that could be exploited remotely (CVE-2017-14648) [START_REF] Bladeenc | Vulnerability statistics[END_REF]. dnsmasq is a DNS forwarder designed to provide DNS services to a small-scale networks, and it is included in most Linux distributions. Versions of dnsmasq prior to 2.78 have a stack-overflow vulnerability which enables a remote attacker to send a maliciously crafted DHCPv6 request to hijack control flow on the target system (CVE-2017-14493) [5]. Gravity is a dynamically typed concurrent scripting language written in C. The Gravity runtime contains a stack-based buffer overflow that leads to remote code execution (CVE-2017-1000437) [9].

Performance Analysis

We ran the SPEC CPU 2006 benchmarks performance analysis experiments on an Intel Xeon Gold 6126 Processor with 24 cores and 32GB RAM running Ubuntu 16.04 LTS Xenial Xerus Figure 6 shows the performance overhead incurred by ProxyCFI instrumentation. For compute-intensive applications, the näive implementation's performance overheads are non-trivial, since these programs have high average sled depth. Average sled depth is a measure of how many pointer proxy tests are required in a sled, on average, before a direct branch is taken. Ideally, we would like this value to be close to 1 to lower the performance overhead for ProxyCFI. For applications with heavy use of function calls such as perlbench, gobmk and sjeng, the performance degradation for the unoptimized implementation is more pronounced, having a average return sled depth of 27 for perlbench.

With optimizations, the average sled depth drops dramatically, as do the performance overheads. For example, perlbench benefits significantly from profileguided sled sorting optimization. h264ref also benefits significantly from optimizations, as it makes heavy use of generic function pointers with indirect functional call sleds having up to 855 entries, of which only two are frequently targeted. gcc, on the other hand, makes considerable use of both function calls (average sled depth of 32) and generic function pointer (with an average sled depth of 26 for indirect calls). The performance benefit of the function cloning optimization is more visible on gcc, as the probability distribution of taken branches falls off slower than the other applications. For network-facing applications, the performance overhead is insignificant due to their I/O-bound nature. The average performance overhead for redis-server is 0.25% and an average overhead of 0.93% for all of network-facing applications we evaluated.

Figure 7 shows the percentage increase in the binary size as a result of pointer proxy instrumentation, both with and without optimizations. On average the code size grows by 49% for our benchmarks with the worst case of 121% for h264ref, due to the large amount of instrumentation required for its generic function pointers. Finally, Figure 8 shows the impact of ProxyCFI verification and load-time proxy randomization on program load times. As shown in the graph, it has approximately linear relationship with code size, the longest being 1200ms, consistent with previous works that perform load-time randomization [39] [START_REF] Vishwath Mohan | Opaque control-flow integrity[END_REF]. Shared library performance. We measured the cost of our shared library support infrastructure by microbenchmarking entries and exits to shared libraries and comparing it against unprotected shared library calls. The average percent slowdown for a shared library calls using optimized ProxyCFI compilation is 1.48% and 2.31% respectively for the best and worst-case average sled hit depths observed in our benchmark experiments.

Security Analysis

To assess the security strength of ProxyCFI, we first examine its ability to stop control flow attacks in the RIPE attack suite, then we examine to what extent ProxyCFI can stop real-world control flow attacks including CFG mimicry attacks.

Penetration testing with RIPE: RIPE is a control flow attack testbed that generates attacks by permuting five dimensions of attack: location (e.g., stack, heap, ...), target (e.g., return address, function pointers, ...), overflow technique (e.g., direct/indirect), and function of abuse (e.g., memcpy, ...) [40]. Native RIPE targets 32-bit x86 code, thus, with the help of a recently implemented lowfat pointer extension [START_REF] Gregory | Stack bounds protection with low fat pointers[END_REF], we ported the RIPE test suite to x86-64. Our port supports the following five dimensions: location, target (including setjmp() and longjmp()), method, and overflow type. Permuting all RIPE dimensions totals up to 850 unique tests. With ProxyCFI protections, 100% of the RIPE attacks are stopped. In addition, ProxyCFI was able to detect the exact point at which attacks escape the CFG.

Real-world vulnerabilities. To evaluate the effectiveness of ProxyCFI against attacks on real-world applications, we included recent attacks reported on the National Vulnerability Database (NVD) in our evaluation.

With ProxyCFI, we were able to stop all of the following real-world attacks including CFG mimicry attacks.

In testing, we found that the declared violations enabled us to quickly identify the root cause of the vulnerability. We analyzed four attacks.

MuPDF has a stack-based buffer overflow vulnerability in the xps parse color() function which performs an unchecked strcpy() of a user supplied (via XPS input) array to a fixed size buffer [8]. The exploit uses this bug to overwrite the return address and jump to an ROP gadget. With ProxyCFI we were able to detect the stack pivot based on the corrupted pointer proxy.

Bladeenc's command line parser uses unchecked calls to strcpy() to copy parameters to a 256-byte buffer that are exploited for arbitrary code execution by using a carefully crafted command line arguments [START_REF] Bladeenc | Vulnerability statistics[END_REF]. The exploit corrupts a function pointer to jump to another function which is also in its legal target set to hijack control flow via a CFG mimicry attack. We were able to detect the exploit when trying to jump using a forged pointer proxy (which was interpreted as invalid pointer proxy from the source address).

Dnsmasq has a vulnerability caused by an unchecked use of memcpy() in the dhcp6 maybe relay() function to a 16-byte field of the variable state. This bug allows an attacker to perform inter-object overflow to perform ROP attack. Using ProxyCFI we were able to detect all of the exploits.

Gravity contains a stack-based buffer overflow in the function operator string add() which can be used to write past the end of a fixed-sized static buffer to achieve code execution. The exploit uses this vulnerability to overwrite a return address using a malicious Gravity script. For the ProxyCFI hardened version the attack was detected when the exploit tried to make an indirect jump based on forged pointer proxy.

Related Work

Memory safety. Memory corruption attacks have been often used to hijack control flow, either by injecting code or reusing existing code. Data execution prevention [1] [2] is sidestepped entirely as reuse attacks need not inject code. Comprehensive memory safety techniques such as Softbound [START_REF] Nagarakatte | Softbound: Highly compatible and complete spatial memory safety for C[END_REF] can completely eradicate memory exploitation, but they suffer from high overhead or compatibility issues, deeming them as yet impractical for widespread adoption.

Control flow integrity: A new wave of practical defenses emerged with a focus on validating that execution adheres to a static, programmer specified CFG. Control flow integrity (CFI) [START_REF] Abadi | Control-flow integrity[END_REF] was the first of these CFG defenses. The defense inserts checks before indirect branches to make sure that all indirect control transfers are within the statically discovered CFG. Various coarse-gained variants have relaxed CFI constraints to achieve practical solutions through both software and hardware approaches [41] [42] [6] [START_REF]Control flow guard (windows) -msdn -microsoft[END_REF].

CCFIR [41] uses a load-time randomized springboard section to redirect all indirect control flow transfers, which has been bypassed by a successive work [START_REF] Gktas | Out of control: Overcoming control-flow integrity[END_REF]. Intel CET [6] provides rudimentary hardware protection for forward edges through its indirect branch tracking. Microsoft CFG enforces a weak form of CFI by restricting indirect function calls to function entry points [START_REF]Control flow guard (windows) -msdn -microsoft[END_REF]. While these techniques are valuable against straightforward code reuse techniques, CFG mimicry attacks effectively bypass this CFI techniques. Unlike these coarse grained CFI techniques, ProxyCFI provides fine grained protection, and also affords protection against CFG mimicry attacks. CCFI [START_REF] Jose Mashtizadeh | Ccfi: cryptographically enforced control flow integrity[END_REF] is a fine-grained CFI technology that protects code pointers by storing hash based message authentication code (MAC) alongside code pointers and checking the MAC before indirect branches. While CCFI can protect against CFG mimicry attacks, its high performance overhead (52% for SPEC'06) will undoubtedly limit its applicability in production environments. Like CCFI, ProxyCFI provides fine-grained control flow protection, while incurring significantly lower overheads (only 5.9% average slowdown for SPEC'06).

Other control flow integrity works have proposed to completely remove instructions employed for control flow hijacking attacks. Return-less kernels [START_REF] Li | Defeating return-oriented rootkits with return-less kernels[END_REF] avoid use of ret instruction by replacing them with a lookup into a static return table which provides protection solely against return-based attacks. Control-data isolation (CDI) [START_REF] Arthur | Getting in control of your control flow with control-data isolation[END_REF] rewrites both forward and backward edges with exclusively direct branches. CDI would conceivably constrain execution to the programmerspecified CFG, if it were to verify that all binaries adhered to CDI compilation requirements. But since the approach still uses code pointers to identify program pointers, the approach is readily attackable with control flow attacks that do not leave the CFG, such as Counterfeit OOP [START_REF] Schuster | Counterfeit object-oriented programming: On the difficulty of preventing code reuse attacks in C++ applications[END_REF]. Moreover, ProxyCFI addresses CFG mimicry attacks by replacing code pointers with pointer proxies that utilize per-function namespaces, which are assigned at program load-time to an execute-only memory.

Code-Pointer Integrity (CPI) [START_REF] Kuznetsov | Code-pointer integrity[END_REF] provides memory safety for code pointers by storing them in a safe region. CPI requires allocation of a safe data region inaccessible to an attacker. ProxyCFI does not require any special data region protections.

Conclusion

While significant effort has been spent to shut down control flow attacks, their existence and value persists today, even 40 years after the first buffer overflow attack. With ProxyCFI, we take the novel approach of replacing all of a program's code pointers with the much less powerful pointer proxy. A pointer proxy is a random identifier representing a specific program entry point from the context of a specific function. A control transfer with a pointer proxy utilizes a multi-way direct branch which fully anticipates all of the potential jump targets. As such, ProxyCFI provides much resistance to advanced control flow attacks because it is difficult to forge/swap pointer proxies to mimic a legitimate CFG transition. Our implementation of ProxyCFI is built into the GNU GCC C/C++ compiler toolchain, such that all code pointers are replaced with pointer proxies including those contained within shared libraries. Analysis of our pointer proxy implementation reveals that they introduce minimal slowdown when pointer-proxy specific optimizations are applied, only an average 4% slowdown across a wide range of benchmarks. Moreover, security analysis of ProxyCFI shows that it stops all of the control flow attacks we tested, including 100% of the attacks in the RIPE x86-64 attack suite and a wide range of real-world attacks including CFG mimicry attacks.

Looking ahead we see a number of avenues for growing the capabilities of ProxyCFI. In particular, we would like to implement support for reassigning pointer proxy values at runtime, and we would like to explore the use of pointer proxies for a limited set of data pointers.

A Redis-benchmark Results Breakdown

Table 2 shows the results of running redis-server with the standard redis-benchmark using 50 parallel clients and a 3-byte payload.

Fig. 2 :

 2 Fig. 2: ProxyCFI Program Loader. This figure illustrates the process of loading a ProxyCFI compliant program for execution.

Figure 2

 2 Figure2shows how a binary or shared library is loaded and validated. The verifier ensures that only pointer proxies are used for control transitions. If a code object passes verification, the verifier generates load-time assigned pointer proxies, such that an attacker cannot anticipate any pointer proxy values even with an active read attack on the program.The psuedocode for the ProxyCFI code verifier is shown in Algorithm 1. The verifier performs reachability analysis on the code object's CFG to validate that it is i) free of indirect control transfers and ii) all control transfers point to a valid instruction within the current code object or the entry point of another code object for calls. To this end, it performs a depth-first traversal of the CFG of the code object, inspecting all control transfer instructions. If indirect call/jump or return instructions are encountered in the code object, it immediately fails verification. For direct control transfer (i.e., direct call, direct jump, loop instructions), it analyzes the target address for any possible violations.For direct jump instructions, the verifier checks that the target address points to a valid instruction within the current code object. For direct function calls, the verifier validates that the target is a valid code object entry point. Finally, for multi-way branch sleds replacing an indirect call/jump and return, the verifier ensures that all targets are valid according to the CFG. Once the verifier completes reachability analysis of the CFG without failure, the code is safe to load and execute.

Fig. 4 :

 4 Fig.4: Compilation Flow. The compilation occurs in two passes. In the first pass, the entire CFG of the program is discovered. In the second pass, all legal program entrypoints are assigned randomly selected pointer proxy identifiers, and all indirect jumps, indirect calls, and returns are replaced with fully enumerated multi-way direct branches. The linker resolves all jumps using compiler-generated global identifiers for all entry points. The profiler instruments the code to count the most frequent targets of multi-way branches, which is used for optimization. Finally, all code is passed through the pointer proxy verifier, assigned load-time random pointer proxies and loaded into execute-only pages before execution begins.

Fig. 5 :

 5 Fig. 5: Function Cloning. Function cloning cuts the number of legitimate edges by a factor of the number of clones. Legitimate edges 6 and 8 from f2 sled are no longer legitimate after cloning.

Fig. 6 :

 6 Fig. 6: Performance Overhead of ProxyCFI. Unoptimized shows the performance overhead without any optimization, while ProxyCFI (prof.) and ProxyCFI (prof. + clon.) show performance with profile-guided sled sorting (prof.) and function cloning (clon.) optimizations.

Fig. 7 :Fig. 8 :

 78 Fig. 7: Increase in Code Size. This graph shows the impact of ProxyCFI on code size. The blue bars (left) represent unoptimized ProxyCFI programs, while the green bar (right) represents optimized ProxyCFI programs.

Table 1 :

 1 Comparison of Code Pointers to Pointer Proxies. Pointer proxies preserve program control integrity by reducing their capabilities. This table lists the differences in capabilities between code pointers and pointer proxies. Ultimately, it is the powerful nature of code pointers that enable many control flow attacks.

		Code Pointers Pointer Proxies
	Arithmetic Allowed	Yes	No
	Totally Ordered	Yes	No
	Trivial Forgery Attacks	Yes	No
	Permit Relative Distance Attacks	Yes	No
	Replay Attacks on Returns and fptrs	Yes	Only from the same source address

  Algorithm 1 Load-time Program Verifier. The algorithm performs a reachability analysis of the CFG to identify any illegal jumps or uses of indirection.

	1: procedure Verify(obj)
	2:	for all f in obj do
	3:	ep ←f.entry point
	4:	while ep = ∅ do
	5:	e ← ep.pop()
	6:	if e.checked == T rue then
	7:	continue
	8:	else
	9:	br ←scan for next branch(e)
	10:	switch br do
	11:	case Indirect(br) or Invalid(br.target)
	12:	return F ail
	13:	case Direct Branch
	14:	ep.push({br.target, e.next})
	15:	case sled
	16:	inspect ({sled.proxies})
	17:	ep.push({sled.targets})
	18:	return Success

  38. David Wagner and Paolo Soto. Mimicry attacks on host-based intrusion detection systems. In Proceedings of the 9th ACM Conference on Computer and Communications Security, pages 255-264. ACM, 2002. 39. Richard Wartell, Vishwath Mohan, Kevin W Hamlen, and Zhiqiang Lin. Binary stirring: Self-randomizing instruction addresses of legacy x86 binary code. In Proceedings of the 2012 ACM conference on Computer and communications security, pages 157-168. ACM, 2012. 40. John Wilander, Nick Nikiforakis, Yves Younan, Mariam Kamkar, and Wouter Joosen. RIPE: Runtime intrusion prevention evaluator. In In Proceedings of the 27th Annual Computer Security Applications Conference, ACSAC. ACM, 2011. 41. Chao Zhang, Tao Wei, Zhaofeng Chen, Lei Duan, Laszlo Szekeres, Stephen McCamant, Dawn Song, and Wei Zou. Practical control flow integrity and randomization for binary executables. In Security and Privacy (SP), 2013 IEEE Symposium on, pages 559-573. IEEE, 2013. 42. Mingwei Zhang and R Sekar. Control flow integrity for cots binaries. In USENIX Security Symposium, pages 337-352, 2013.

Table 2 :

 2 Results of running redis-benchmark ProxyCFI compliant redis-server versus unhardened baseline

	Command	Baseline (request/sec) (request/sec) ProxyCFI

Execute-only memory is also supported on ARMv8 and above.

Acknowledgement

This work was supported by DARPA under Contract HR0011-18-C-0019. Any opinions, findings and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of DARPA.


Alexander Puchta
email: alexander.puchta@nexis-secure.com

Fabian Böhm

Günther Pernul

Contributing to Current Challenges in Identity and Access Management with Visual Analytics

Keywords: Identity and Access Management, Identity Management, Visual Analytics

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Identity and access management (IAM) has become a vital component of modern companies as it enables the management of identities and grants access to necessary resources. IAM also assures compliance with regulations like SOX [START_REF][END_REF] or Basel III [START_REF]Basel Comittee on Banking Supervisions: Basel III: Int. framework for liquidity risk measurement, standards and monitoring[END_REF]. To achieve this, IAM systems consist of manifold policies, processes and technical solutions [START_REF] Fuchs | Supporting compliant and secure user handling-a structured approach for in-house identity management[END_REF]. The core of IAM are identities like employees and their access rights to resources maintained within the system. Besides human identities, new technologies like the Internet of Things (IoT) require the integration of technical identities (e.g. sensors and machines) into IAM [START_REF] Mahalle | Identity management framework towards internet of things (IoT): Roadmap and key challenges[END_REF]. Thus, the number of elements maintained in the system is constantly rising. This will ultimately lead to an identity explosion where a vast amount of heterogeneous identities has to be managed in a single system. This results in numerous problems to be addressed in the next years to ensure IAM systems remain an effective part of companies' IT landscapes.

A solution for those problems needs an effective way to manage and analyze the huge quantity of information with often thousands of identities and hundreds of thousands of entitlements. To decide whether information about an identity is wrong or redundant access rights are assigned to it, the knowledge of domain experts with experience and deep understanding of an enterprise's individual IAM landscape is needed. In this work we investigate how this domain knowledge can be integrated into an IAM landscape by leveraging Visual Analytics (VA) as VA is one of the central methods to include domain experts' knowledge and utilize their feedback [START_REF] Federico | The role of explicit knowledge: A conceptual model of knowledge-assisted visual analytics[END_REF]. In order to reach this goal, this work investigates three research questions:

-RQ-1: What are current and upcoming key challenges within IAM to be solved by integrating domain knowledge? -RQ-2: How can VA be integrated into an existing IAM architecture and which steps are necessary? -RQ-3: What could an exemplary VA solution for IAM look like and which challenges could be solved?

By answering these research questions our work focuses on two main contributions. We provide a list of challenges for current and future IAM. This list is an outcome of a structured analysis taking both academic and practice viewpoints into consideration. We also demonstrate how VA can be applied helping to integrate domain knowledge in tasks to identify IAM anomalies and possible erroneous configurations (e.g. over-authorization or wrong identity attributes). Therefore, we develop a prototypical visualization designed in cooperation with experienced IAM practitioners. The remainder of this work is structured as follows. Section 2 introduces some background on IAM systems as well as related work regarding the integration of VA into IAM. Next, Section 3 follows a structured, two-fold approach to identify current challenges for IAM system as seen from academia and practice to answer RQ-1. An architecture to integrate VA into IAM (RQ-2 ) as well as a corresponding proof-of-concept visualization (RQ-3 ) are presented in Section 4. The benefits of this prototype regarding the identified challenges are highlighted with exemplary use cases in Section 5. Section 6 concludes our work and highlights possible future research directions as well as current limitations.

Background & Related Work

In this chapter we define key concepts of IAM and introduce related work regarding the integration of VA into IAM.

Background

IAM consists of two main fields which are managing identities and granting them access to resources. According to Pfitzmann and Hansen [START_REF] Pfitzmann | Anonymity, unobservability, pseudonymity, and identity management-a proposal for terminology[END_REF] an identity is a subset of attributes uniquely identifying a person. An identity is either real or exists as a digital identity like profiles in social media. Real and digital identities are often linked, and a real identity may own multiple digital personas. However, in the following we assume each entity to have exactly one digital identity as the scope of this work is limited to a single company's context. Currently, IAM regards employees, contractors or customers as identity because they all need to have access to certain resources [START_REF] Windley | Digital identity: Unmasking identity management architecture (IMA)[END_REF]. In addition to humans having digital identities, technical equipment like machines or sensors are entities which need access to resources, too. Thus, these technical identities also are relevant for maintaining them within an IAM [START_REF] Fremantle | Federated identity and access management for the internet of things[END_REF].

Digital identities in an IAM are managed from their creation to their deletion when not needed anymore. During this life cycle, access control is used to provide access to applications, data or other information [START_REF] Samarati | Access control: Policies, models, and mechanisms[END_REF]. Enterprises often employ role-based access control (RBAC) in order to grant access [START_REF] Sandhu | Role-based access control models[END_REF]. In RBAC, roles are utilized to bundle single access rights and consequently assigned to identities. On the contrary, attribute-based access control (ABAC) leverages identities' attributes and predefined access policies for dynamic access management [START_REF] Hu | Guide to attribute based access control (ABAC) definition and considerations[END_REF].

To maintain landscapes with thousands of identities, enterprises employ IAM systems which are able to support the identity life cycle and provide identities with the correct entitlements. Besides that, modern IAM systems offer a variety of other functionalities (e.g. Single Sign-on) which are not detailed any further in this work.

Related Work

There are some existing publications applying visual representations for IAM problems. The earliest integration of VA to the best of our knowledge is the "role graph model" by Nyanchama and Osborn [START_REF] Nyanchama | The role graph model and conflict of interest[END_REF]. It is based on RBAC and is used to optimize existing roles for a company. In addition to that, several authors propose a matrix-based approach to visualize users and their entitlements [START_REF] Colantonio | Visual role mining: A picture is worth a thousand roles[END_REF][START_REF] Meier | Managing the access grid -a process view to minimize insider misuse risks[END_REF]. Based on that, VA can be applied to identify suitable roles or outliers with extensive entitlement assignments. Recently, Morisset and Sanchez introduced a tool to visualize ABAC policies [START_REF] Morisset | Visabac: A tool for visualising ABAC policies[END_REF].

These approaches are focusing mostly on interactive visual techniques for Access Control. To the best of our knowledge there is no existing work taking Identity Management into consideration to build a more cohesive visual solution. Therefore, we try to fill this gap by identifying general IAM challenges where domain knowledge of experts is needed to solve them. After identifying those challenges, we build a prototypical visual approach to demonstrate how domain experts can be integrated.

IAM Challenges

This section defines current or future IAM challenges where domain knowledge of human experts may play a vital role. They can serve as a starting point to deduce requirements for any type of solution trying to tie experts and IAM systems closer together. In Section 4 we introduce a proof-of-concept visual solution to tackle some of the herein defined challenges.

For identifying the challenges, existing academic literature as well as practitioners experience within the field of IAM are taken into consideration. We are aware that there are far more challenges than the five proposed by us. However, based on the results of our structured analysis and the domain knowledge of practitioners, we chose the most relevant ones with respect to the necessity to integrate domain experts. An IAM challenge in the context of this work is a current or future problem with the need to be solved for IAM. Challenges already being tackled or focusing only on parts of an IAM system (e.g. access control) are not considered in this work. Neither do we consider problems where the inclusion of domain expert knowledge is not vital. To identify challenges, we follow a structured approach introduced in the Section 3.1.

Approach for Identifying Challenges

We derive current challenges following a structured approach depicted in Figure 1. We ensure to include both the scientific and the practitioners' view as IAM is an active research field as well as a highly relevant topic in enterprises. During the literature survey we analyze existing academic literature published in the last ten years regarding IAM and respective challenges or problems. This scientific viewpoint allows us to derive a first set of IAM challenges. However, IAM is highly business-driven and there are numerous practical approaches outside the academic world. Thus, we also include the perspective of practitioners.

The goal of this second analysis is twofold. We verify the academic IAM challenges but also identify further challenges not yet considered by scientific literature. Three different sources of information are leveraged in order to minimize subjectivity of different business opinions:

1. Analyst reports and surveys from the IAM industry 2. Interviews with IAM consultants with 3 to 15 years of experience 3. Interviews with companies applying IAM solutions In a last step, we integrate all inputs from the analysis into five IAM challenges. The list of identified challenges is not exhaustive for the IAM field of research. Our work is focusing only on current challenges that can strongly benefit from integrating experts' knowledge.

Literature Survey

In order to identify relevant literature, we follow a structured approach by defining keywords to review relevant IAM literature. As we are defining challenges for the entire IAM system we only take resources into consideration which are dealing either with "identity and access management" or specific problems and challenges within "identity management" or "access management". We transform these phrases into suitable search terms 2,3 and applied them to the dblp computer science bibliography 1 . Dblp is a service indexing relevant academic journals and proceedings of peer-reviewed conferences from computer science. Searching dblp results in a feasible number of results with a high suitability. Therefore, we can ensure to get only relevant academic publications. Dblp serves as a quality gate for our scientific analysis as it returns a manageable amount of entries compared to other engines like Google Scholar with nearly 10.000 results for the second search term. We manually filter the results based on title, abstract, and key sections to remove findings not mentioning any challenges or problems.

We apply a second, more unstructured search to identify additional relevant entries. In this step we include further academic databases (IEEE XPlore, ACM, Google Scholar) to find additional literature not listed within dblp. This results in a total of 19 academic publications mentioning or clearly defining relevant challenges for IAM. We group the identified problems and define the first four challenges (cf. C1 to C4 in Section 3.4).

Practitioner's View

We now conduct a business analysis to include the practitioners' point of view. Information received in this process step is often hard to generalize as it reflects subjective opinions. However, by including various sources of information we try to overcome this deficit. In the business analysis we look at reports from specialized IAM analysts namely KuppingerCole4 . This company is focused on IAM and technologies around that sector and thus has accumulated valuable knowledge in this area [START_REF] Kuppingercole | State of organizations -does their identity & access management meet their needs in the age of digital transformation?[END_REF][START_REF] Small | Kuppingercole report -advisory note -big data security, governance, stewardship[END_REF][START_REF] Tolbert | Kuppingercole report -advisory note -identity in iot[END_REF]. Additional input is generated by Gartner [START_REF] Diodati | Gartner -2019 planning guide for identity and access management[END_REF], Forrester [START_REF] Cser | Forrester -Top trends shaping IAM in 2018[END_REF] and IDG Research Services [20].

Furthermore, we conduct interviews with three different IAM consultants with several years of practical experience in the field of IAM projects. Besides that, four companies already applying IAM solutions are inquired regarding possible challenges. While the four previously defined challenges are verified throughout the interview, a fifth one (C5 ) arises as a current problem of IAM from a business viewpoint.

IAM Challenges

Within this section the identified IAM challenges are described in detail. A mapping of all relevant academic publication to the challenges is provided in Table 1. Table 2 maps the results of our analysis with practitioners to the challenges. Challenge 1 -Identification of all Relevant Identities (C1): For current and future IAM systems the identification of all relevant identities may sound like a simple task. However, especially in practical application it is not. One of the major reasons for this is the integration of various types of identities into IAM. Currently, mainly employee and contractor identities are maintained in an IAM system. A recent trend, customer IAM or shortly CIAM, strives to add customer identities into these systems as well [START_REF] Cser | Forrester -Top trends shaping IAM in 2018[END_REF]. Additionally, the Internet of Things requires integrating even more identities, mostly technical ones [START_REF] Nuss | Towards blockchain-based identity and access management for internet of things in enterprises[END_REF]. Furthermore, numerous IT systems are not even connected to IAM. Nevertheless, such systems also contain various identities with the need to be identified for IAM in order to prevent identities not being centrally manageable. These trends hinder IAM to establish a central view of all relevant identities. However, this view is vital for any further analysis to be done within IAM (e.g. identification of unnecessary accounts or entitlements).

Challenge 2 -Privacy within IAM (C2): As modern IAM systems offer a centralized view on nearly all employees, contractors and even costumers including their attributes the need for privacy arises. Especially business solution power users like IAM administrators can easily retrieve personal information from the identities. Based on our practical experience this could be a simple mail address but may also uncover more sensitive information like wage brackets or entitlement usage information. In order to protect this information in compliance with regulations, privacy mechanisms are needed to grant access to such information only when necessary and for authorized users. This challenge is mainly focused by scientific research and not by practitioners at the moment. However, as the European General Data Protection Regulation (GDPR) came into effect in 2018, it certainly will have an impact on the business sector of IAM. Please note that this challenge is limited to the application of privacy mechanisms on IAM systems and does not include the application of IAM systems for enhancing GDPR compliance within companies.

Challenge 3 -Heterogeneity of Various Identities (C3): As there are various identities within an IAM system, they are not identical. In fact, they differ quite a bit as identities consist of various attributes (e.g. first name, department). Considering C1, it gets clear that not all identities have the same kind of attributes. Technical and human identities are likely to have a completely different set of attributes. For example, technical devices do not have a first name, but instead have an attribute indicating their software version. This, on the one hand, rises a technical challenge to integrate this variability of identities into one underlying data set for IAM. In addition, IAM mechanisms like provisioning of entitlements still need to be working for all of these identities. On the other hand, it also hinders the analytic part of IAM as domain experts need to browse through an enormously large, heterogeneous database. By applying VA, domain experts could be supported as various attributes can be displayed in a more accessible way than in currently deployed table-based reports.

Challenge 4 -Data Quality & Data Management (C4): When it comes to attributes and other data existing in IAM, data quality and the underlying data management in IAM system needs to be considered. Attributes are often manually entered by different people; thus, wrong or inconsistent values are very likely to occur. For example, the current business location of an employee may be added by HR employees. If the employee moves to another department of an enterprise, the location also needs to be changed. Manual processes for attribute modifications exacerbate data quality issues as one can forget to adjust the location attribute. Therefore, IAM mechanisms like provisioning of entitlements based on the attribute location might fail. Additionally, wrong attribute values limit the possibilities of IAM analytics. Although an approach to improve attribute quality management was lately introduced [START_REF] Kunz | Attribute quality management for dynamic identity and access management[END_REF], algorithms can only detect anomalies but can neither confirm nor reject whether it is a real data error. To do so, domain experts are needed, and VA can be highly beneficial to support related decisions by integrating domain expert feedback.

Challenge 5 -Transformation from Role-based IAM to Attributebased IAM (C5): Challenge 5 was identified during the interviews with IAM consultants as it is not explicitly defined as an upcoming challenge in academic literature. It comprises the enterprise IAM transformation from a role-based approach to an attribute-based one. As mentioned before, enterprises mainly depend on an RBAC approach. However, this can lead to an increasing number of existing roles and requires increasing effort regarding role management [START_REF] Elliott | Role explosion: Acknowledging the problem[END_REF]. In order to overcome these limitations, ABAC can be applied [START_REF] Hu | Guide to attribute based access control (ABAC) definition and considerations[END_REF]. However, as this is a fundamental change of approach for IAM companies have to consider various factors (e.g. processes, technologies and policies [START_REF] Fuchs | Supporting compliant and secure user handling-a structured approach for in-house identity management[END_REF]). Changes needed for this transformation are therefore not limited to access control, but existing research is mainly focused on the transformation of the access control model [START_REF] Sandhu | The authorization leap from rights to attributes: Maturation or chaos?[END_REF][START_REF] Xu | Mining attribute-based access control policies from RBAC policies[END_REF]. To the best of our knowledge there is no overarching approach how an enterprise IAM can be transformed from a role-based approach to an attribute-based one.

Tables 1 and2 compare the results and show that C1, C3, and C4 are found in both worlds and can easily be identified as relevant IAM challenges. Privacy in IAM and therefore, C2, is mainly embraced by academic literature and not explicitly mentioned in the business sector. C5 is not described explicitly in academic literature but only mentioned very shortly by 3 articles. We identified this challenge by conducting interviews with IAM consultants and companies.

Applying Visual Analytics to IAM

Any of the previously identified challenges can benefit from including domain experts and their knowledge. VA has proven its capabilities to help integrate domain expert knowledge in complex and data-intensive cyber security tasks throughout the last years [START_REF] Wagner | A knowledge-assisted visual malware analysis system: Design, validation, and reflection of kamas[END_REF][START_REF] Crouser | Retrospective on a decade of research in visualization for cybersecurity[END_REF]. Additionally, decision makers can be supported with VA by making highly technical data sources more accessible. Therefore, we argue that leveraging concepts from VA to solve the identified challenges in IAM is a reasonable approach. As described in Section 2, there is some existing work that has shown the feasibility and utility of VA in the context of IAM. However, none of the challenges identified in Section 3 has been explicitly tackled with visual approaches yet. We try to fill this gap as we describe the architecture and design of our new visualization approach. The visualization design cannot support all the identified challenges as they are far too different in requirements. However, our approach shows how heterogeneous information about human and technical identities can be integrated into a single visual representation. The resulting view allows identifying existing identities (c.f. C1) and their structures (c.f. C3) as well as users can detect problems regarding data quality (c.f. C4).

The visual representation is designed and implemented in close cooperation with IAM practitioners which were also part of our interviews during the challenge identification. By including them in development, we ensure that the representation that is helpful for practical use. The participating experts are IAM consultants working for numerous clients and with years of experience in practical work with IAM projects. While the current visual tool is at a proof-of-concept stage, we are planning to continue our fruitful cooperation with these experts to develop a solution that can be used in their day-to-day work. Our cooperation also allowed for the development of the prototype based on the adaption of anonymized real-world identity data from a medium-sized company in the manufacturing sector with around 1.200 employees.

The underlying architecture for our prototypical application is depicted in Figure 2 and its main components -Data Sources, Data Preparation, and Data Visualization -are described in more detail throughout the following sections. This architectural design is based on the Information Visualization Pipeline [START_REF]Readings in information visualization: Using vision to think[END_REF] which is a widely accepted structural design concept for any interactive visualization approach. The applied architecture shows how identity-related information can be collected and integrated from different sources and how the information needs to be prepared for VA concepts supporting domain experts. The identification of different data sources and their integration into a single, displayable data set are a starting point for any visual representation of identity data. Therefore, the main part of our architectural design, the Data Preparation, demonstrates how visual representations in general can be integrated into an existing IAM structure. The operations executed during the Data Integration Engine and the Data Transformation step need only small adjustments for varying Data Sources. The last part of the architectural design, the Data Visualization, demonstrates how VA can contribute to the focused challenges by introducing an exemplary visualization of identity information. Interaction in this step is crucial as it ensures that experts can adjust the view for their personal needs and explore the data based on their own preferences to gain insight.

Data Sources

Our current proof-of-concept tool collects information about identities from three main data layers. Although the company representing the use case has a cen- tral IAM system with a role-based access control mechanism, not all information about the existing identities is fed into it. Only partial information from the Application Layer is integrated into IAM, while other applications, like the company's Active Directory (AD) to manage windows accounts, are not connected to it. Therefore, information from these systems needs to be collected separately. Technical identities representing IoT devices are currently not integrated into IAM but rather maintained separately (IoT-layer). The wide variety of different data sources storing information about the companies' identities and the missing integration of this information into IAM are the main reasons for the challenges we focus in this prototype. It becomes increasingly hard for any company to keep track of its identities when the information about them is so spread out. Additionally, the different information systems store the available data in different formats or data models. Furthermore, it is very important for any company to keep the quality of their identity information at a high level. Spread out data makes this very difficult, especially when data is maintained redundantly in different repositories.

Additional data sources can be plugged easily into our architecture via the Data Integration Engine. Our proof-of-concept system works with one source from each layer. This number of data sources is already enough to demonstrate how VA helps to leverage experts' domain knowledge in the context of the aforementioned challenges as is demonstrated in Section 5.

Data Preparation

The main purpose of this part of the architectural design is to integrate and normalize the data from the sources into a single data model and format. Additional fields are added and calculated in this step. The resulting data is structured as a single table containing all relevant and necessary information about the identities. This step is essential for further visual display as it defines the level of detail available to the users. The operations applied to the data in this step are dynamic and can be changed whenever different information is of interest or new data sources are plugged into the architecture.

Data Integration Engine (P1): This part of the architecture is responsible for collecting data relevant from the data source and integrating them into a single cohesive data set. Our proof-of-concept work extracts CSV data from all data sources. However, each CSV export contains a different set of attributes. To preserve the information about the source of a data set, we annotate the data with a flag depicting the source. Additionally, we add a field describing whether the identity is a human or a technical identity. In our conceptual setting, this identity type is mainly dependent on the data source. For example, identities extracted from IAM are automatically annotated to be "Human" as only employees or costumers are integrated into IAM. In the same way, identities extracted from the IoT layer are annotated to be "Technical" identities. The cohesive data set is built as a union of the three data sets depicted in Figure 2: ApplicationLayer ∪ IAM Layer ∪ IoT Layer.

Data Transformaion (P2):

After integrating all available data sources into a single, high-dimensional table, this data set is structured as needed for the visualization in this phase. This part of the architecture applies a variety of transformations. These include splitting a single field into multiple fields, replacing values in a specific field, calculating additional fields based on existing information. The result of this step is a cohesive data set containing all relevant and necessary information.

Data Visualization

This last part of the architecture is responsible for creating the interactive visual representation with the subset of the data selected by the domain expert. The interactions available to the users enable exploratory work with the visualization and the identification of inconsistencies, miss-configurations as well as structures and dependencies in the set of identities.

Data Filtering (P3):

The interactive filtering assures the efficiency of the following steps and guarantees the expressiveness of the resulting view for the user. The subsequent Data Mapping (P4) can be CPU-intensive for very large data sets and, therefore, the input for this step needs to be as small as possible. It only contains the fields (columns) the user wants to see. The interactive selection of fields relevant for the user and the early integration of this interaction into the architectural design ensures that only relevant data is passed to the subsequent components. Up to this point the proposed architecture is generalized and can be applied to various visualization approaches within IAM. However, the Data Mapping (P4) and the Interactive Visual Display (P5) are highly dependent on the visualization technique selected for a specific VA solution. Therefore, the following considerations are specific to our exemplary solution.

Data Mapping (P4): This phase in the architecture maps the filtered identity information into a dynamic hierarchical data structure which is necessary for the prototype to visualize the data correctly. We will not elaborate this data structure any further as it is specific for the proof-of-concept visualization and is prone to change for different visualization types. Interactive Visual Display (P5): Before we are able to build a visual representation for the data at hand, it is necessary to choose a suitable visualization technique. This technique needs to be capable of displaying the dimensions and structure of the underlying data properly. For our prototypical visualization the technique must be able to represent multi-dimensional and hierarchical data. While there is a number of techniques (e.g. tree diagrams, circle packing, sunburst diagrams, or treemaps) which fulfill this requirement [START_REF] Severino | The data visualisation catalogue[END_REF], each technique has its own advantages and disadvantages. It mainly comes down to the use case as well as the subjective preferences of the users which technique is most suitable. We used design sketches of the different suitable visualization techniques to interview IAM domain experts about their preferred visual representation. These interviews resulted in the sunburst diagram to be the most preferable technique to apply in the proof-of-concept application. However, any of the mentioned as well as a number of other techniques might be suitable, too.

The sunburst diagram displays a hierarchy using a series of concentric circles. Each ring itself corresponds to a level of the hierarchy. Therefore, underlying data structure is similar to a tree where the root node is depicted by the central ring and outermost circles represent the leaves of the tree-like structure. The sunburst's rings are sliced up and divided based on their hierarchical relationship to the parent slice. Therefore, the sunburst highlights structural, hierarchical relationships while being more scalable than other hierarchical visualization types. Figure 3 depicts the main view of our proof-of-concept application consisting of three main parts.

In (A) experts can drag-and-drop the boxes for the corresponding fields in the data set they want to be depicted in the sunburst diagram between two main lists. Each box represents an IAM employee attribute of the normalized data set. Exemplary fields which are contained in the proof-of-concept are the "Organisational Unit", "Data Source", or the number of entitlements of an identity. The upper list holds the currently active (i.e. displayed) fields and the lower one the inactive attributes. The first element in the list of active elements serves as the root element (innermost circle in the sunburst) when constructing the hierarchical data set. Accordingly, the second active attribute is displayed as the next outer circle. Logically, the last active element is included in the Sunburst diagram as the outermost circle.

The central part of the view is dedicated to the sunburst diagram (B). Each segment of the circles (attributes) depicts a single characteristic of an attribute in relative size to all existing identities. Hovering a segment brings up the number of identities depicted by this segment. The relative frequency with respect to the number of current root element (innermost circle) and the path to the hovered segment are displayed on top of the visual representation. Left-clicking a segment allows zooming in on this particular representation of an attribute. This improves the readability of specific hierarchy levels in very granular sunburst displays. When zoomed into a segment, clicking the white area in the middle of the sunburst diagram brings the zoom one hierarchy level upwards. Right-clicking a segment brings up a dialog. This dialog holds a table with identities in the rows and all attributes available for them in the columns. The identities displayed in the table are dependent on the clicked segment of the sunburst diagram as only the identities whose attributes fulfill the path to the segment are shown in the table. The table allows filtering and sorting of the currently displayed identities. In the dialog identities can also be reported for further analysis if necessary.

(C) holds the description of the sunburst as a dynamic list containing all currently visible circles (attributes) and the respective visible ring segments (attributes values). Clicking the magnifier for a list element zooms in into the segment representing this element. A click on the counter badge brings up the table with the identities included in corresponding node in the hierarchy. Within this table identities can be marked for further analysis by using a "Report"-button for each identity in the details table-view (e.g. after identification of an anomaly), thus, providing the possibility for integration of domain expert feedback into other applications. However, further functionality beyond this notification is out of scope for this work and needs to be implemented in a following version of the prototype.

Exemplary Use Cases

The current prototypical implementation3 of our visualization for IAM was developed in co-creation with experts as suggested by Staheli et al. [START_REF] Staheli | Visualization evaluation for cyber security[END_REF]. We regularly conducted semi-structured interviews with the participating practitioners to ensure that the implementation fits their needs and requirements. This section explicitly highlights how the visual display can support domain experts. We therefore go through several problems and inconsistencies based on one use case and identified by IAM experts while exploring the data. These had not been noticed before applying the visualization.

As the different problems only become evident in the sunburst diagram with different actively visualized attributes, we added predefined scenarios of the sunburst to our publicly available version of the prototype. Using the drop-down menu in the top right corner, we provide a video showcasing each of the following subsections. We would recommend to look at the corresponding video for each subsection in order to grasp the connection between the IAM problem and the sunburst visualization for identification of the inconsistency.

The exemplary use cases are based on the data set from a manufacturing company with 1.200 employees mentioned in Section 4. The company recently introduced an IAM system and connected the HR system as well as some minor applications. However, the Active Directory (AD) is currently not under IAM control because of its complexity as it was one of the company's first IT system growing for two decades. Therefore, some employees are missing an AD account while some AD accounts from former contractors and employees are still active. These orphan accounts are not identified via the IAM system, but they are still active and can be used for malicious activities (cf. Section 5.1).

Furthermore, the company made some investments in automating specific process tasks. Thus, two assembly machines and some automated users were integrated within the AD and were provisioned by an AD administrator. However, there was no communication with the IAM department and, therefore, no access management or integration into the IAM system took place. This results in technical identities with excessive entitlements. As the company is not experienced with such technical identities, the risk for failures (e.g. deletion of data) resulting from misconfiguration is high (cf. Section 5.2).

During configuration and assignment of a location to the technical identities some flaws regarding the existing location attribute values were detected. As entitlements shall be assigned automatically within the new IAM system based on a policy, the identification and correction of these values is highly relevant. Otherwise, identities with an incorrect value for their location attribute are not assigned enough entitlements (cf. Section 5.3).

Identities Not Managed within a Central IAM (C1, C4)

As stated before, some identities within the company are not integrated in the central IAM system. Identifying these is a hard task considering the spread-out information. Our approach integrates applications not connected to the IAM system. Taking a look at the "Data Source" attribute the sunburst shows in which layer the respective data originates. Identities in the "IAM Layer" segment of the diagram are collected directly from IAM. However, another 17 identities are not managed by the IAM system. Three of them are maintained in the "AD Layer" while 14 are gathered from the "IoT Layer". Taking a look at the details view of those 14 identities brings out that they are technical devices. Adding another circle for the "Identity Type" to the Sunburst allows an analyst to see that none of the identities within the "IAM Layer" are technical devices. So obviously the company has not integrated its technical identities into the central IAM system.

Identities with an Unusual Number of Entitlements (C3)

Another use case needing the attention of domain experts are identities with anomalous high number of entitlements. The Sunburst Diagram facilitates the identification of relevant entities and a decision how to proceed. Displaying the "Entitlements", "Identity Type", and the "Function" a small set of identities becomes visible having more than 76 entitlements. This seems conspicuous as most of the entities in the company have 0 to 25 roles assigned to them. Zooming into the segment with 76 to 100 entitlements a technical device attributed with function "Support" becomes visible and an identity from the company's customer "Brandmark" has an anomalous number of entitlements. These findings do not indicate an error per se, but it might be necessary to carry out further analyses. By browsing through the Sunburst domain experts are enabled to find various of similar cases. Any identity which might be over-authorized has to be examined, if all the entitlements are still needed (e.g. via recertification). If not, this indicates a serious security breach as identities having excessive permissions are legitimately allowed to access classified resources.

Poor Data Quality in IAM Data (C4)

The Sunburst diagram allows for identifying data quality flaws via several means. A first possibility is to compare similar attribute fields which originate from different data sources. Exemplary for this used when comparing "Location (AD)" and "Location (IAM and IoT)". Information about locations of identities is administered in both the application layer and the IAM layer. Usually the IAM layer which contains the HR should be the master system for attributes like the location. After analyzing the data, some quality issues included in this system become apparent. An example is visible by zooming to the value "Berlin" of the "Location (AD)" attribute. The IAM layer has in fact 3 different attributes for identities having this value in the AD system, namely the correct value "Berlin" but also "BER" and "10249 Berlin". Presumably, this value was recorded manually by the HR employees resulting in inconsistent data.

Conclusion

The complexity of modern IAM systems is constantly rising (e.g. increasing number of identities, further IAM mechanisms). Therefore, new challenges emerge. Within this work we showed that VA can be integrated into IAM in order to solve some of them. To achieve this, we initially identified five central challenges through a review of academic literature and analysis of the experience of practitioners (RQ-1 ). Thereby, we discovered two challenges especially connected to the identification and management of identities. Furthermore, we expect more challenges within the topics Privacy and Data Quality. Besides that, there will be the future challenge to transform role-based IAM into an attribute-based architecture for enterprises. We do not claim that our list of IAM challenges is exhaustive. However, we focused especially on problems where the integration of domain expert knowledge is vital. We detected some additional challenges but excluded them as they are not in the scope of the paper (e.g. inclusion of trust management in IAM, identity as a service, compliance with regulations).

Based on these challenges we identified VA as a possible solution as it enables enterprises to integrate domain expert knowledge and utilize their feedback to solve upcoming IAM challenges. We proposed an architecture how IAM by leveraging concepts from VA in order to answer our previously defined RQ-2. Additionally, we implemented proof-of-concept visualization according to our architecture and based on real world data (RQ-3 ). By applying VA, we have shown that problems tightly connected to the defined IAM challenges can be identified. However, the implementation should be regarded as a first example how the architecture can be implemented and as proof that VA can support enterprises to solve central IAM challenges. Other visualization techniques might be applied to solve another subset of our identified challenges.

After proposing an architecture for integration of VA and a first proof-ofconcept implementation we want to focus further on the process to choose a suitable visualization for the Interactive Visual Display component. Additionally, we want to introduce further VA implementations to solve the remaining IAM challenges. Afterwards, we can orchestrate the single implementations to an overarching coordinated view [START_REF] Heer | Interactive dynamics for visual analysis[END_REF].

Fig. 1 :

 1 Fig. 1: Approach for defining the key IAM challenges.

Fig. 2 :

 2 Fig. 2: Architecture for IAM Visual Analytics.

Fig. 3 :

 3 Fig. 3: Screenshot of the prototype available under http://bit.ly/iam-vis. Please note that the current version of the tool is only working in Google's Chrome Browser.

Table 1 :

 1 Results of literature survey on ten years of academic work.

	Source	Year	C1	C2	C3	C4	C5
	Hovav and Berger [15]	2009	x	x
	Mahalle et al. [27]	2010	x	x	x
	Bandyopadhyay and Sen [2] 2011	x	x	x
	Jensen [22]	2012		x	x	x
	Kanuparthi et al. [23]	2013	x	x		x
	Fremantle et al. [12]	2014	x		x
	Xiong et al. [46]	2014		x
	Hummer et al. [18]	2015	x		x	x
	Kunz et al. [24]	2015				x	x
	Hummer et al. [19]	2016	x		x	x	x
	Moghaddam et al. [29]	2017		x
	Servos and Osborn [38]	2017		x
	Asghar et al. [1]	2018		x
	Damon et al. [8]	2018	x		x
	Hummer et al. [17]	2018	x		x	x
	Indu et al. [21]	2018	x	x	x
	Nuss et al. [31]	2018	x		x
	Povilionis et al. [34]	2018		x		x
	Kunz et al. [25]	2019			x	x	x

Table 2 :

 2 Analysis results from practitioners' view.

	Source	Year C1	C2	C3	C4	C5
	IDG Research Services [20]	2017	x		x
	KuppingerCole and CXP Group [26] 2017	x
	Tolbert [43]	2017	x		x
	Diodati et al. [9]	2018	x		x
	Small [40]	2018	x		x	x
	Cser and Maxim [7]	2018	x	x	x
	Interviews (IAM consultants)	2019	x	x	x	x	x
	Interviews (Companies applying IAM) 2019	x		x	x	x

identity|access management challenge|problem

identity-and-access-management 1 https://dblp.uni-trier.de/

https://www.kuppingercole.com

The prototype is available under http://bit.ly/iam-vis. Please note that the current version of the tool is only working on Google's Chrome Browser.

Acknowledgment. This research was supported by the Federal Ministry of Education and Research, Germany, as part of the BMBF DINGfest project (https://dingfest.ur.de).